Image of the glider from the Game of Life by John Conway
Skip to content

Your GnuPG Private Key

This post is inspired by a discussion in irc://irc.freenode.net/#gnupg about Keybase and a blog post by Filippo Valsorda.

I was curious just exactly how my private key is encrypted. Turns out, gpg(1) can tell you directly:

$ gpg --output /tmp/secret-key.gpg --export-secret-keys 0x22EEE0488086060F
$ gpg --list-packets /tmp/secret-key.gpg
:secret key packet:
	version 4, algo 17, created 1095486266, expires 0
	skey[0]: [1024 bits]
	skey[1]: [160 bits]
	skey[2]: [1023 bits]
	skey[3]: [1023 bits]
	iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt: ad8d24911a490591
	protect count: 65536 (96)
	protect IV:  01 1e 07 58 4a b6 68 a0
	encrypted stuff follows
	keyid: 22EEE0488086060F
(...snip...)

Notice the line "iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt: ad8d24911a490591". In there, you see "algo: 3" and "hash: 2". What do those identifiers reference? If you refer to RFC4880, you can learn what they are:

Symmetric Encryption Algorithms

  1. Plaintext or unencrypted data
  2. IDEA
  3. 3DES
  4. CAST5
  5. Blowfish
  6. Reserved
  7. Reserved
  8. AES-128
  9. AES-192
  10. AES-256
  11. Twofish

Cryptographic Hashing Algorithms

  1. MD5
  2. SHA-1
  3. RIPEMD-160
  4. Reserved
  5. Reserved
  6. Reserved
  7. Reserved
  8. SHA-256
  9. SHA-384
  10. SHA-512
  11. SHA-224

I emphasized the defaults, which are CAST5 and SHA-1. So, your key is encrypted with the SHA-1 of your passphrase, which is used as the key for CAST5 to encrypt your private key. Thus, the whole security of your encrypted private key rests on the entropy of your passphrase, provided that sane defaults are chosen for the encryption and hashing algorithms, which they are.

CAST5 has been well analyzed and it is not showing any practical or near practical weaknesses. It is a sane default to chose for a symmetric encryption algorithm. However, CAST5 uses 64-bit blocks for encrypting and decrypting data, which may have some theoretical weaknesses. AES uses 128-bit blocks, and thus has a larger security margin. Because AES-256 is available as a symmetric encryption algorithm, there really is no reason to not use it, aside from feeling more secure.

SHA-1 is showing near practical attacks on blind collisions, but for use with keying a block cipher from a passphrase, it's still exceptionally secure. What is needed to break SHA-1 in this regard, is a pre-image attack. A pre-image attack is where you have the hash, but you do not know the input that created it. This is not brute force. This is able to break the algorithm in such a way, that provided with any hash, you can reliably produce its input. SHA-1 has a wide security margin here, so there really is nothing practical to worry about. However, with SHA-512 available, there is also really no reason why not to use a SHA-2 algorithm. In fact, aside from the increase security margin, SHA-512 is designed to work well on 64-bit platforms, but struggle with 32-bit. So this gives us an increased security margin, albeit negligible, against using something like SHA-256.

So, how can we change these? Turns out to be quite simple. All you need to do is specify the secret key symmetric encryption algorithm and hashing algorithm, then change your password (retype it with the same password if you don't want to change it):

$ gpg --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --edit-key 0x22EEE0488086060F
Secret key is available.

pub  1024D/0x22EEE0488086060F  created: 2004-09-18  expires: never       usage: SCA 
                               trust: unknown       validity: unknown
sub  1792g/0x7345917EE7D41E4B  created: 2004-09-18  expires: never       usage: E   
sub  2048R/0xCE7911B7FC04088F  created: 2005-07-04  expires: never       usage: S   
(...snip...)

gpg> passwd
(...snip...)
gpg> save

Now if we export our key, and look at the OpenPGP packets, we should see the new updates:

$ gpg --output /tmp/secret-key.gpg --export-secret-keys 0x22EEE0488086060F
$ gpg --list-packets /tmp/secret-key.gpg
:secret key packet:
	version 4, algo 17, created 1095486266, expires 0
	skey[0]: [1024 bits]
	skey[1]: [160 bits]
	skey[2]: [1023 bits]
	skey[3]: [1023 bits]
	iter+salt S2K, algo: 9, SHA1 protection, hash: 10, salt: 9c3dbf2880791f2e
	protect count: 65536 (96)
	protect IV:  db f5 e8 1c 98 03 99 7c 77 33 4e cd d3 3c 1f 4f
	encrypted stuff follows
	keyid: 22EEE0488086060F
(...snip...)

Now I have "algo: 9" which is "AES256" and "hash: 10" which is "SHA512" protecting my private key. I've gained a little bit extra security margin at the cost of retyping my passphrase. Not bad. Now, I'd like to pose you a question:

If I were to publish my encrypted GnuPG private key, think I'm crazy?

Let's look at this for a second. We know that the key is protected with AES-256. AES remains secure, after 15 years of intense scrutiny and analysis, and is showing no signs of wear. It's the most used symmetric encryption algorithm that protects HTTPS, SSH, VPN, OTR, Tor, and even your GnuPG encrypted emails. It protects social security numbers, credit card transactions, usernames and passwords, patient health records, hard drives, and on, and on, and on. AES is secure.

So, breaking the encrypted key will be at least as hard as breaking AES, which seems to be a long shot. So, you would be better off attacking my passphrase. Knowing that it was used as the key for AES, and that it is hashed with SHA-512, we can write a brute force algorithm to generate passphrases, hash them with SHA-512, and attempt at decrypting the AES key. After all, we have the salt and the IV right there in plaintext in the packets. Turns out, there are already projects for this.

This should be a breeze. Unless, of course, you have sufficient entropy behind your passphrase. What is sufficient entropy? Well, take some time searching "entropy" on my blog. You'll quickly learn that I recommend at least 80-bits. 100-bits would give you a paranoid security margin, even with the password being hashing with a fast hashing algorithm like SHA-512.

So, if the private key is encrypted with AES-256, and the passphrase has sufficient entropy to withstand a sophisticated attack, and it is hashed with SHA-512, then I should have no concern posting my encrypted key into the open, right?

Without further ado, here is my encrypted GnuPG private key:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -----BEGIN PGP PRIVATE KEY BLOCK-----
Version: GnuPG v1

lQHpBEFLyzoRBACXCUta5CK+DCgnXn9wkqUumkcbenibGPBe3Y8IEY4BjkdbGdTN
tiGB+Tvo0hzn2qzy4mNPlOx/LWZWF2MdwF3WS77wwIskMb8W314zhE2RS0G318YY
X7zMGSF+7QiNXNsW/d0t1RonYOKIS96zKOtFQZrTr//V8+1rxEa4rvO5dwCgul0s
pt2BUDqwoy2Q/5UKgnmrzmsD/37/3g5zXykvTH2P6BlgTdfnVvpOLDT3CyWlAynz
u5hdmgYNT50I2w5TstY+uViYhAbMiyIT1HwBRcaQh8hUWkzDGyzJF7pS4pZeD0M9
u0P7Cejm2+ENdOX66ablWjP7GLJRcToGxnAZ6hgPpWLen8lHYaUK//g4JJx8UJ/n
wifeA/9xYWDi3ur/fFCKQZIPV9Ziw1oL58su948yWRn2WN7m74+bSldkXzkc4jRe
Q51FpGBHMswRIJKB6yG1FbfLum8ppGbvtz9NrMMZuirguTWetX8aJrjr0ddGjTsY
uZPfKoUiqDUXSFc3hmVgQQQ4MFdD3XYy6AQTyI1vstCS/Tdn7P4JAwqcPb8ogHkf
LmDb9egcmAOZfHczTs3TPB9Pg1SJqjvSz7nKDY87EVmeM46YBaCs1XScaOF4Gs+x
u0LNAxlfX3xOUIWRtCdBYXJvbiBUb3BvbmNlIDxhYXJvbi50b3BvbmNlQGdtYWls
LmNvbT6IWQQTEQIAGQUCQUvLOgQLBwMCAxUCAwMWAgECHgECF4AACgkQIu7gSICG
Bg/+cACeM0EeO7gE85/OSwMzxjvQAGB53jgAnik6qvFWyQtvp71KElbpZUsa0YNj
nQIoBEFLy0IQBwCjVGmY/PmOtRHtBIuANfg9zf8thGXZtFZWEgzHLGUgSfIjb0di
F24mwiVw2k3gzqBKuFBJ633F3AhwlTBnXS3tLWQgwSrm3BcCOOn+wJvwgUXa0iBn
gXhcq/7IL7HnKsYiG9EFMI8mAd10t7zdsA/dS2xUmFNexQvUdra/uRU+eeQbrXYe
iwfymw2RCZROl4/QXA9/a/aTyUhKgkj2vieo0jh394h7grPZxw0lgCclvTN/0jGq
dPkp56NMDb0eGlVzWeEiseD1JxXeYaSeToJP3zmx+nFoiBa+VVVeUhzYAwADBQb+
P373jEOwDu63py4FWdMPMYNWv1xFWLYI5hWaTKPSRwG/NZICRDF+QNztSmVOhW7Z
SFY/nTHq5yFp+QID63VMGv5Cunse9QXAoarecyV2hllwUq7l7wHujJhvvqyEgL9G
ah/drkZMGe8btYihz/M4g5i1P2DPr4CL/46eZxgjmjuVw7Nb0UsgUPgGizPCbnJ3
ye1ahxc1dOX80Guh0ZDRfR/ehZkk07wN2H6KRrxFCAmDaCR9KxwGYbpepND0t4HG
qCMji37lzYUrS4PV6yK0DGekqF98xgiIVBYFjF0jwQD+CQMKnD2/KIB5Hy5g4K9F
3JFIPxw+L+Gdc2MSYuJI3Y5kpZluUmYYYYFgOH64/J8egeYSSKWUIPqMhnwBWtbW
GQCNdztQyIIi6mB3YiDeK2AMnhRq+PwwwGG1iEYEGBECAAYFAkFLy0IACgkQIu7g
SICGBg+MhQCfZ7FNu4wMtdifkblGkN5Qqj+cYWYAoLiipdgnnhPTP2z7SgOsxiR4
YI4wnQPEBELI4BIBCADCobEk1f0sByuV4p2moEmZIXXEJhzTolO2mmBLBSmbjPMg
OBpAFTmWYXJxo8oZnNeeTOWN/hsHV9rmC/c/bZ7FGX4u/pN0l3qOSoSO6m6yvM/O
q4idyl17SfqDR9AUdEwJIA9zfSomzmzfO/q3rIAOPNkd71RQ4YMkHn8SfQLaojxl
+N5pPB29c6Cy+hltP6JRibAHgYCkxQGLK6ZLQ1LTwkDLNxCH8qfmHvg7M3qcXxl4
KOgtb8kNZ3PpAvek1GNL/eaF7nnd/u5uHuJM5V7czVHjpMbBfRGgLzR6Tu6v8qm7
nJzhSErxC7lK0hXLgGuHlk26bj9pzb+lfBk7GnkRAAYp/gkDCpw9vyiAeR8uYPUV
mINtxpejZeID6EaNZ8wTKNB1e3yt/As2Svkpcl1ivosbADhxCTFSJ4RtmEynFPCw
qgYbjuTBK+Fv2LSd7CYHJm4zZ/hfiCBgL4jI3ZY52qHFnBhgHtLwza/eLeaC0i4+
RWUAN9JEW1Ygpsh0ApRd1UvY8dGoLF24fy3C2jeh5Q3SVw2SnhUryLU7u6gTTLt4
yskT+/pzdNrb2n3dvLLUhQJ50SeTroa/swB/SXnjWtDSRGpvv3HAStHSENaZCIrV
e/u/WSNd99nklpYdPwh3UFO9OOayYErYiprEhLC7JjdVbqbu2aIfrw+nS/PS+tlm
wQTYH/DKA6wIeSZK4y9Byfrx3oq4DPk9pge7n3z3oz9pzd+xG2GMvExwKiCUlcF5
he5Peb4sTsJz0epMpwcBXFNYyVO++rZvBTABhgY5MQAcympoBAAcspo8AvBWx2xK
SaIyp5XDtT8jqey5Jjo3qmIQvdpo5oQub73JCMDSHi7KZ/IkgtggpgDqNh9bT5ZE
C7d3lprPFQJNQtFTO2K8NecRkgatn9Imomy1DidlnsCuZjqfamNVssWhm0uNu8SC
aJYBtC9kZXhBLAy0mFCMfJQ8ysDzlG3+Fu9wE9tCQvkh7y0ZKo9Ortqnwqp6S0I3
2xMBOg2EMHRP+ADF3q/i2wlgbH0MHsiX4oMxd0eIZV+rJIQSnO547UvvzAUBjXjZ
1l23wmg8FctYIE0UPsTo1QNArGO1sIOdv807UMolB9lq1pKAXkJP0GPRZLv9bLDj
kkKLEBELXCCQA0vDH+N/eGXRdJbWv5i0mOXmxK2JAZZw8rsJF3XZ22PABrC0NaCP
qHftcq20PPMCRZ/TfjQmwlot495KmLUJo2G6JasdcEilyPH2GVUwiqCM2/wOWk4U
xX+FmA40NYmU64hJBBgRAgAJBQJCyOASAhsCAAoJECLu4EiAhgYPt9kAn3r0Hhf9
aTFyowH3pgqIUiaMVQo5AKCFWzcU23YT0E2/LZNl6Yqzcs113Q==
=SHc5
- -----END PGP PRIVATE KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJWToHpAAoJEM55Ebf8BAiPk7kH+weVf8kVJRjSaSWE+Aft76iA
Nzj1cVUfpWoT/K139i3TMiZ6PpAQtCRyEakdxfeSfXiOz83pqmKSL5ADCdlRoxuB
HtkoLW6thETOs70mDrrsEQgBZgMYPMsiKG1W/M3xppRGZxUM7/UEXhjHYiThe1Qd
Dkwot+hu5EttQpu0kKFmPrviPpJOk0gJ5SQrhlROWCS+aT9TyhbswMRpSyurDZ2H
LppGk8EtBeWTsTf9AhemX1GFu4iJPwIDfZtiWOLGGjQn4ROqb/RWqLG254O//Gw6
jtDRGHIGyYk+2NQ6/gAKWI9Sxaz5kUxqKSzDU9WuDCE3peIB9HXM+ynFVKLgsXE=
=Rnfg
-----END PGP SIGNATURE-----

Now that this is posted, I should expect everyone to steal my GnuPG identity, parading around as me, forging signatures, correct? No, it's not happening. I trust the crypto. I trust the math. I trust the software.

Why? Why am I doing this? Well, a recent discussion popped up on IRC about Keybase. Some don't like the fact that they are encouraging you to upload your encrypted private key to the server. Some claim that it is "insecure". However, didn't we just logically and reasonably conclude that AES and SHA-2 are protecting my best interests? So, if it's insecure, then it can't be due to the crypto. It must be something else. Let's look at all the risk factors:

Keybase servers are compromised and you use the web interface
If the server is compromised, then the attackers can modify the code, providing malicious JavaScript to the browser, so when you successfully decrypt your private key, it can be sent and stored elsewhere under their control. There is nothing you can do here. You are screwed. This is a very valid concern.

Keybase servers are compromised and you use the command line interface
The attackers only have access to your encrypted private key. Provided you never use the web interface, all encryption and decryption as handled out-of-band. This means that regardless of the Keybase server compromise, the attackers will never actually get to forge signatures using your GnuPG private key.

Your local client is compromised
There is nothing I can do for you here. Keybase isn't to blame, and not even the gpg(1) client can protect you. You have bigger problems on your hands than the attackers gaining access to your unencrypted GnuPG private key.

I think a lot of GnuPG users are paranoid about their key getting leaked, because they are unsure of exactly how it is stored. Hopefully this post lays those fears to rest. If there are still concerns about the leak of encrypted private keys, then it's probably due to a fear of not fully understanding the strength of passwords and their entropy requirements. However, if you meet the necessary password entropy requirements, and your key is encrypted with CAST5/SHA-1 or AES-256/SHA-512, there is nothing wrong with keeping a backup of your GnuPG key on Github, AWS, Dropbox, or other "cloud" hosting solutions.

Trust the math. Trust the software.

By the way, if you do successfully recover my private key passphrase (and I know you won't), I would be interested in hearing from you. Send me a signed email with my private key, and I'll make it financially worth your while. 🙂

{ 5 } Comments

  1. stream | November 20, 2015 at 2:06 am | Permalink

    I agree that GPG should change the dafaults but practical safety margin would not change really, bigger number of iterations during key derivation would improve it but only for weaker passphrases.

    64 bit block algorithms only have problems when encryptiong big amount of data (32GB) so CAST5 is perfectly fine here, that being said AES is the standard algorithm for keys so it should be standard for everything.

    Pre-image attack does help in breaking the key bot not exactly like described in the post. If there would be a flaw in SHA that creates the same hashes for multiple inputs shorter or equal than passphrase size in bits, thus making the possible keyspace smaller, mulpiple passphrases would generate the same SHA hashes. Attacker would have to create rainbow table with all possible hashes excluding impossible ones thus reducing brute force attack complexity to less than maximum key lenght derived from given passphrase and do it in such a way that generation of said table does not add more complexity than gained.
    I would think that GPG would implement a key derivation function that is not directly relaying on hash function strength and in fact it does by default use multiple iterations of hash function and salt making creation of rainbow tables less practical.

    With publishing of your private key you do make a point but you also decrease your GPG key resistance to certain attacks. Now only thing protecting it is your passphrase when before making it public it was working like two factor auth. Something you have + something you know. This scheme proctects your key even if your passphrase gets compromised. Due to that keybase is less secure than GPG.

    About the concerns - as GPG does not rely on a server first two do not apply and the last one does apply only partially as two factor auth protects from many types of local attacks. Actually most of that type of attacks can be stopped just by using key stored in a file where systems relying only on passphrase would be completly compromised. For your passphrase to be compromised attacker does not have to compromise your local client, shoulder surfing is enough. This is why GPG keyservers do not store private keys.

    Due to Snowden documents we can be sure that entities like Keybase will be attacked in some form or another and using such systems is just adding vulnerability due to centralised point of failure for everyone using it.

    Keybase does add some ease of use but in my opinion still not enough for the general audience to use it. We would have to make it automagic so users would not think or sometimes even know about it (like SSH, TLS etc.) and that just shifts the problem to industry/providers/admins. Encryption would have to be implemented either on the client side (preferable) or server side and used in a opportunistic way.

    If you choose to add small amount of additional security by changing keyring algorithms why are you removing additional protection that two factor authentication gains?

    In my opinion Keybase does not gain much when it comes to users, removes too much security and adds single point of failure.

  2. Aaron Toponce | November 20, 2015 at 6:25 am | Permalink

    I agree that GPG should change the dafaults but practical safety margin would not change really, bigger number of iterations during key derivation would improve it but only for weaker passphrases.

    I already mentioned that the gains are theoretical gains when moving to AES and SHA-2. And I didn't add anything about key rotation, because the post was already technically bloated as it is. But, due to the large number of comments online, it seems I should have added it. Then again, it seems people are already aware of it too. Shrug.

    64 bit block algorithms only have problems when encryptiong big amount of data (32GB) so CAST5 is perfectly fine here, that being said AES is the standard algorithm for keys so it should be standard for everything.

    Agreed.

    Pre-image attack does help in breaking the key bot not exactly like described in the post. If there would be a flaw in SHA that creates the same hashes for multiple inputs shorter or equal than passphrase size in bits, thus making the possible keyspace smaller, mulpiple passphrases would generate the same SHA hashes.

    Cryptographic hashes already have this flaw by nature. Infinite inputs in the domain do map to a single output in the range. This is by design. Further, the attack of finding the passphrase that is used as the block cipher key in this post, is not a blind collision attack. A blind collision attack is finding the mathematical relationship between two inputs that produce the same output. That is not what is going on here. Instead, you are looking for the digest that is the block cipher key. You don't know the input. In reality, you don't even know the digest (it's not stored). Regardless, SHA-1 is not weak in this scenario.

    Attacker would have to create rainbow table with all possible hashes excluding impossible ones thus reducing brute force attack complexity to less than maximum key lenght derived from given passphrase and do it in such a way that generation of said table does not add more complexity than gained.

    Rainbow tables are a thing of the '80s and '90s. They were great for Unix crypt() and Microsoft LM and NTLM hashes, and some MySQL MD5 and SHA-1 hashes, but no one uses them in practice today. The reason is because salting passwords is ubiquitous now, and it's no different with GnuPG. The salt is right there in the post. So sure, you could build a rainbow table based on that salt, but you would be doing as much work as brute forcing the passphrase.

    I would think that GPG would implement a key derivation function that is not directly relaying on hash function strength and in fact it does by default use multiple iterations of hash function and salt making creation of rainbow tables less practical.

    Well, instead of key derivation functions like PBKDF2 or scrypt, there is already a discussion about including slow password hashing functions like bcrypt and argon2, and may be released in an upcoming OpenPGP specification. Regardless, as already mentioned, if you passphrase has sufficient entropy to withstand a sophisticated attack, then a fast hashing function won't reveal the passphrase anyway. Slow hashing functions are design to protect weak passwords from people who don't know any better. Sure, it doesn't hurt for those who do know better, but if they applied what they know, the fast hashing function isn't going to be practical either.

    Oh, and rainbow tables are an ineffective attack with GnuPG passphrases due to the salt, as already discussed.

    With publishing of your private key you do make a point but you also decrease your GPG key resistance to certain attacks. Now only thing protecting it is your passphrase when before making it public it was working like two factor auth. Something you have + something you know. This scheme proctects your key even if your passphrase gets compromised. Due to that keybase is less secure than GPG.

    This is not two-factor authentication at all. I'm not authenticating to my private key with something I know (my passphrase) and something I have (a TOTP token). There may be some hardware smartcard readers that have this functionality, as I am not familiar with them. But in software, you authenticate with your GnuPG only with your passphrase. This is single-factor auth.

    About the concerns - as GPG does not rely on a server first two do not apply and the last one does apply only partially as two factor auth protects from many types of local attacks. Actually most of that type of attacks can be stopped just by using key stored in a file where systems relying only on passphrase would be completly compromised. For your passphrase to be compromised attacker does not have to compromise your local client, shoulder surfing is enough. This is why GPG keyservers do not store private keys.

    I'm not sure what your point is. No where in the post do I mention that GnuPG relies on servers. I don't mention key servers at all, actually. The only server I mention is Keybase. So, I don't understand what you're saying here.

    Due to Snowden documents we can be sure that entities like Keybase will be attacked in some form or another and using such systems is just adding vulnerability due to centralised point of failure for everyone using it.

    Yes, and? I already discussed the realistic threat with a compromise of Keybase. All they have are encrypted private keys and known public keys. I already mentioned that breaking the encrypted block cipher to get at your plaintext key is impractical. So, the realistic attacks are serving malicious JavaScript through or browser or brute forcing your passphrase.

    But Keybase is small fish. Larger fish are your online identities- Google, Facebook, Twitter, Pinterest, etc. as well as your ISP. I am much more concerned about the compromise of these services than I am of Keybase. OpenPGP keys are cheap. My personal identity is not.

    Keybase does add some ease of use but in my opinion still not enough for the general audience to use it. We would have to make it automagic so users would not think or sometimes even know about it (like SSH, TLS etc.) and that just shifts the problem to industry/providers/admins. Encryption would have to be implemented either on the client side (preferable) or server side and used in a opportunistic way.

    After using OpenPGP for 11 years, I've come to the conclusion that it is not designed well enough for the general audience. It will remain a niche product for techno, crypto, and privacy nerds. If you want end-to-end encryption, that is easy to use, Free Software, and designed for the general audience, look at miniLock. OpenPGP certainly has its place, but it's not for your mom or dad, siblings, friends, neighbors, etc. It's too difficult to understand and far too much work to maintain.

    People don't use Keybase, because it's easy to use, although that is certainly a strong benefit. People use Keybase as an effective replacement of the Web of Trust. Honestly ask yourself how often you've used the PGP Web of Trust to decide whether or not to trust encrypted data from an associate from whom you do not know. I can count on one hand how many times I have since 2004, and I cryptographically sign all my emails with my GnuPG key, I attend key signing parties as often as possible, and I send encrypted data to coworkers and friends regularly with GnuPG. The fact of the matter is, the PGP Web of Trust is solid in concept, but horrid in practice.

    Keybase addresses this through online identities. Now, if I receive an encrypted email from an associate of who I am unfamiliar with, I can use Keybase to learn something of their established online identity. If this is someone I have already previously interacted with on Twitter, or have read their blog, I can use the signatures found at those locations to establish a baseline of trust. That's the pull. It's not ease of use. It's establishing trust through online identities and interactions.

    If you choose to add small amount of additional security by changing keyring algorithms why are you removing additional protection that two factor authentication gains?

    I don't know what the context is here. As already discussed, there is no two-factor authentication with GnuPG private keys in software.

    In my opinion Keybase does not gain much when it comes to users, removes too much security and adds single point of failure.

    You don't seem to be very familiar with Keybase then. Its goal is trust through established online identity, instead of face-to-face meetings with government-issued identification. It doesn't remove any security, as already discussed, and it's only replacing the Web of Trust. So what if it's a single point of failure? The software is Free Software hosted on Github (https://github.com/keybase). Feel free to pick it up, if it goes under.

  3. Jeff Parent | November 24, 2015 at 3:54 pm | Permalink

    One thing I noticed when uploading my private key to keybase was the cipher and hash algorithms changed when I pulled my private key from their server.

    iter+salt S2K, algo: 9, SHA1 protection, hash: 8

    When uploading you are asked for your key password which I'm assuming is when they decrypt your key and then re-encrypt and hash it again with your keybase password. Turns out they provided better than the defaults. SHA256 is not bad and they default to AES256 which is good so this was more just an FYI than anything scary.

  4. Glenn Rempe | January 17, 2016 at 6:40 pm | Permalink

    Please note that the procedures Aaron outlined to strengthen your key in this (very cool!) post will likely not work for you if you are using GnuPG 2.1.x (Modern) or higher.

    Werner has changed the behavior of the s2k-* options and it may no longer be possible to override the secret key encryption settings. I filed a bug against the man page which is apparently now incorrect here:

    https://bugs.gnupg.org/gnupg/issue2220

    Maybe this will save someone from going down the road of experimentation with passphrase strength in their key and getting no results like I did.

    Cheers!

  5. John Lane | January 28, 2017 at 9:41 am | Permalink

    Concur with Glenn. You can read my discussion on the mailing list here:

    https://lists.gnupg.org/pipermail/gnupg-users/2017-January/057506.html

    and also a summary on Stack Exchange here:

    http://security.stackexchange.com/a/149371/107494

    But, to summarise, Werner confirmed that it is not possible to configure
    the encryption of the secret key: "Right now the agent always uses AES
    and S2K paremeters which require on the running machine about 100ms for
    decryption."

Post a Comment

Your email is never published nor shared.