Why I've Retired My PGP Keys and What's Replaced It(nullprogram.com)
nullprogram.com
Why I've Retired My PGP Keys and What's Replaced It
http://nullprogram.com/blog/2017/03/12/
46 comments
> Author lists a few requirements, saying that PGP satisfies every requirement, and then says "I couldn’t find anything that fit the bill".
I read your comment before I read the article, and the above part specifically jumped out at me, and I thought "oh come on, that can't be an accurate representation of the article.
Then I read the article, and it is. Wow. He literally lists four reasons, saying PGP works for each one, and then says "I couldn't find anything that fit the bill".
Either this is sloppy writing or NIH-enabling cognitive dissonance of the highest degree.
I read your comment before I read the article, and the above part specifically jumped out at me, and I thought "oh come on, that can't be an accurate representation of the article.
Then I read the article, and it is. Wow. He literally lists four reasons, saying PGP works for each one, and then says "I couldn't find anything that fit the bill".
Either this is sloppy writing or NIH-enabling cognitive dissonance of the highest degree.
Ignorance != dishonesty
It's impossible for me to believe that a person who can hand roll a file encryption tool in C, who knows how to use LUKS and signed git tags, who knows about ChaCha20 and HMAC-SHA256, didn't understand the results of a google search for "linux encrypt files". Did he have a seizure right after hitting enter in the google search box, inadvertently close the browser window, and then wake up and forget having done the search?
Did he not search at all? Did he search only in his own bellybutton and find nothing but lint and a few old pennies? Or did his own cognitive dissonance just keep him from admitting to being trapped in a massive NIH black hole? Saying he found nothing is being dishonest because he either didn't bother looking in the first place or he ignored what he found.
Did he not search at all? Did he search only in his own bellybutton and find nothing but lint and a few old pennies? Or did his own cognitive dissonance just keep him from admitting to being trapped in a massive NIH black hole? Saying he found nothing is being dishonest because he either didn't bother looking in the first place or he ignored what he found.
From https://github.com/skeeto/enchive:
> The process for encrypting a file:
> 1. Generate an ephemeral 256-bit Curve25519 key pair.
> 2. Perform a Curve25519 Diffie-Hellman key exchange with the master key to produce a shared secret.
> 3. SHA-256 hash the shared secret to generate a 64-bit IV.
> 4. Add the format number to the first byte of the IV.
> 5. Initialize ChaCha20 with the shared secret as the key.
> 6. Write the 8-byte IV.
> 7. Write the 32-byte ephemeral public key.
> 8. Encrypt the file with ChaCha20 and write the ciphertext.
> 9. Write HMAC(key, plaintext).
A lot of steps involving low-level crypto, which means making an error is easy... ah, yes, there is one actually, right at the end
What the steps should look like:
> 1. Generate a box ephemeral key using crypto_box_keypair
> 2. Encrypt and authenticate with the ephemeral key as sender and the master key as receiver using crypto_box
> 3. There is no step 3
tptacek once said "If you're writing the letters A, E and S, you're doing it wrong". It doesn't mean you shouldn't use AES; it means you shouldn't use low-level cryptography and use high-level, hard-to-misuse libraries. Use NaCl !
> The process for encrypting a file:
> 1. Generate an ephemeral 256-bit Curve25519 key pair.
> 2. Perform a Curve25519 Diffie-Hellman key exchange with the master key to produce a shared secret.
> 3. SHA-256 hash the shared secret to generate a 64-bit IV.
> 4. Add the format number to the first byte of the IV.
> 5. Initialize ChaCha20 with the shared secret as the key.
> 6. Write the 8-byte IV.
> 7. Write the 32-byte ephemeral public key.
> 8. Encrypt the file with ChaCha20 and write the ciphertext.
> 9. Write HMAC(key, plaintext).
A lot of steps involving low-level crypto, which means making an error is easy... ah, yes, there is one actually, right at the end
What the steps should look like:
> 1. Generate a box ephemeral key using crypto_box_keypair
> 2. Encrypt and authenticate with the ephemeral key as sender and the master key as receiver using crypto_box
> 3. There is no step 3
tptacek once said "If you're writing the letters A, E and S, you're doing it wrong". It doesn't mean you shouldn't use AES; it means you shouldn't use low-level cryptography and use high-level, hard-to-misuse libraries. Use NaCl !
If you are creating a reusable tool, you do really not want to specify it in terms of high level operations that depend on a single library and may change from one version to another.
Just because those steps are explicit there, it does not mean the author isn't using crypto_box or something similar. The author seems to have just copied it into the code, and seems to have a good sense of what to copy.
You can criticize him for not reusing the standard interface, and I agree that if he wanted to use crypto_box, he should just have used it, but not for completely specifying his tool, and not for the actual operations.
Just because those steps are explicit there, it does not mean the author isn't using crypto_box or something similar. The author seems to have just copied it into the code, and seems to have a good sense of what to copy.
You can criticize him for not reusing the standard interface, and I agree that if he wanted to use crypto_box, he should just have used it, but not for completely specifying his tool, and not for the actual operations.
I'm not sure I understand, as far as I can tell his use case is purely for symmetrical encryption of files? Then why not simply use openssl or something similar with their favourite cipher?
Why do you need to generate a private key from a passphrase instead of simply deriving an encryption key directly?
I actually do that from time to time when using GnuPG is not practical:
Why do you need to generate a private key from a passphrase instead of simply deriving an encryption key directly?
I actually do that from time to time when using GnuPG is not practical:
openssl aes-256-cbc -a -salt -in <cleartext-file> -out <encrypted-file>
openssl aes-256-cbc -d -a -in <encrypted-file> -out <cleartext-file>> plus one more feature I’ve always wanted: the ability to generate a keypair from a passphrase
No. This is a bad feature. It turns your public key into a password hash, subject to cracking. This is a major footgun. Someone implemented this for bitcoin, called it a "brainwallet", and people lost large amounts of money due to not understanding the implications or how effective modern password cracking techniques are.
A more succinct breakdown on why this is foolish in this particular case:
> This means I can reliably access my archive keypair anywhere without doing something strange like uploading my private keys onto the internet.
Let us compare two cases:
1) Uploading private key to the internet, encrypted with a passphrase
2) Uploading public key to the internet, generated from a passphrase
In case 1, in addition to being encrypted, there is no reason to make it public, so it would likely be stored somewhere password protected. You can't attack it unless you have the file.
In case 2, the public key is, well public. You're basically handing it out to everyone to try to crack.
The result in case 2 is strictly worse security, for a very marginal increase in convenience.
Though, it seems the author simply published his encrypted private keys before: http://nullprogram.com/blog/2012/06/24/
No. This is a bad feature. It turns your public key into a password hash, subject to cracking. This is a major footgun. Someone implemented this for bitcoin, called it a "brainwallet", and people lost large amounts of money due to not understanding the implications or how effective modern password cracking techniques are.
A more succinct breakdown on why this is foolish in this particular case:
> This means I can reliably access my archive keypair anywhere without doing something strange like uploading my private keys onto the internet.
Let us compare two cases:
1) Uploading private key to the internet, encrypted with a passphrase
2) Uploading public key to the internet, generated from a passphrase
In case 1, in addition to being encrypted, there is no reason to make it public, so it would likely be stored somewhere password protected. You can't attack it unless you have the file.
In case 2, the public key is, well public. You're basically handing it out to everyone to try to crack.
The result in case 2 is strictly worse security, for a very marginal increase in convenience.
Though, it seems the author simply published his encrypted private keys before: http://nullprogram.com/blog/2012/06/24/
This seems to be the danger that Keybase.io is convincing people to put themselves in as well huh.
Why do you say that? Keybase doesn't generate keys from passphrases.
They have a feature wherein you store your password-protected private key onto their servers. By my reasoning (not being a cryptographer), if a passphrase isn't strong enough to protect your private data, it's not strong enough to protect my key, which in turn will no longer protect my private data. Let me know where I may be wrong on this.
Here's a counterpoint: https://blog.filippo.io/on-keybase-dot-io-and-encrypted-priv... I don't understand it. If it really doesn't matter, why wouldn't it just derive the private key from the passphrase? I don't appreciate cryptographers appealing to some sort of common sense in the face of something another cryptographer has created.
Here's a counterpoint: https://blog.filippo.io/on-keybase-dot-io-and-encrypted-priv... I don't understand it. If it really doesn't matter, why wouldn't it just derive the private key from the passphrase? I don't appreciate cryptographers appealing to some sort of common sense in the face of something another cryptographer has created.
In one case, you need just the passphrase. In the other case, you need the passphrase and to hack Keybase's servers, which is considerably harder.
It's not hard if you're keybase. GPG isn't known for being based on trusting anybody other than yourself.
Also note that the blogger (seemingly a security expert that people respect on here) I posted just went ahead and displayed their public key, to demonstrate that they're not afraid of Keybase or anybody else having it.
Also note that the blogger (seemingly a security expert that people respect on here) I posted just went ahead and displayed their public key, to demonstrate that they're not afraid of Keybase or anybody else having it.
The original discussion was about generating keys from passphrases, which is much, much easier to exploit than what Keybase is doing. The discussion about whether Keybase's usability is worth the security tradeoff is one I'll leave to someone else.
plus one more feature I’ve always wanted: the ability to generate a keypair from a passphrase. This means I can reliably access my archive keypair anywhere without doing something strange like uploading my private keys onto the inter
This is stupid. If your key is generated from a pass phrase I guarantee you it's exponentially easier to guess than if it wasn't generated by some simple pass phrase.
Convenience does not equal security.
Edit: oh. You rolled your own and this post is straight up spam.
This is stupid. If your key is generated from a pass phrase I guarantee you it's exponentially easier to guess than if it wasn't generated by some simple pass phrase.
Convenience does not equal security.
Edit: oh. You rolled your own and this post is straight up spam.
An interesting problem with long pass phrases is they become almost biometric in difficulty of changing.
So lets say 10 bits of entropy per English word and you memorize the first 400 words of your favorite translation of the book of Genesis to produce your ridiculously predictable 4000 or so bit key. OK. Nice job. Now your machine gets powned or some service gets powned or you lose a very important flash drive or whatever and now on a dime you have to perfectly memorize five hundred words of ... the book of Revelations perhaps. Really? It sounds simpler to rekey your biometrics by getting new fingerprints or holding a different picture of a retina in front of the retina scanner. Memorize five hundred words perfectly, OK. Memorize a different five hundred words on the fly after a stressful breech, that's just not funny. Can't I just use "Password1"?
Note that a theoretical rainbow table of the bible "could be" very long but a realistic and practical rainbow table could be very short. Very few people are going to begin or end a passphrase in the middle of a possibly important line. In fact most are going to begin and end on major boundaries of which there are not many, and you can exclude all the too short or too long phrases. I suspect there are very few 4000 bit key pass phrases in the bible. And other books are almost easier to predict via social media, most famous book by some author you're related to, or everyone on social media knows your favorite book from uni, etc.
Long pass phrases don't biologically scale over operational time where you might end up rekeying often.
So lets say 10 bits of entropy per English word and you memorize the first 400 words of your favorite translation of the book of Genesis to produce your ridiculously predictable 4000 or so bit key. OK. Nice job. Now your machine gets powned or some service gets powned or you lose a very important flash drive or whatever and now on a dime you have to perfectly memorize five hundred words of ... the book of Revelations perhaps. Really? It sounds simpler to rekey your biometrics by getting new fingerprints or holding a different picture of a retina in front of the retina scanner. Memorize five hundred words perfectly, OK. Memorize a different five hundred words on the fly after a stressful breech, that's just not funny. Can't I just use "Password1"?
Note that a theoretical rainbow table of the bible "could be" very long but a realistic and practical rainbow table could be very short. Very few people are going to begin or end a passphrase in the middle of a possibly important line. In fact most are going to begin and end on major boundaries of which there are not many, and you can exclude all the too short or too long phrases. I suspect there are very few 4000 bit key pass phrases in the bible. And other books are almost easier to predict via social media, most famous book by some author you're related to, or everyone on social media knows your favorite book from uni, etc.
Long pass phrases don't biologically scale over operational time where you might end up rekeying often.
> This is stupid. If your key is generated from a pass phrase I guarantee you it's exponentially easier to guess than if it wasn't generated by some simple pass phrase.
I don't think the author ever claims that a password-derived key is more secure than a random one? This is clearly a conveniance vs security tradeoff, and it doesn't seem like an unreasonable one.
I don't think the author ever claims that a password-derived key is more secure than a random one? This is clearly a conveniance vs security tradeoff, and it doesn't seem like an unreasonable one.
All comments so far seem to disagree with the author ("PGP remains the gold standard, and it's here to stay", "PGP is a failure because it has no critical mass, so author writes ~1300 lines of C code that will never reach critical mass, reinventing gpg-zip", "why re-invent the wheel").
But there are two different things here: encrypted communications and archiving files. The author wrote software for the latter and just gave up on the former.
I don't think it's particularly nice to just drop PGP email support (more and more of my peers are using it), but the other part is still interesting. It uses memory-hard key derivation, elliptic curve cryptography, and some other details that make this thing very good (for its job, at least). This is all fairly state of the art: it has been around for years, but very few systems actually use memory-hard key derivation or elliptic curve crypto. Having more tools use this stuff exposes it more and works encouragingly to others who are also in a position to choose algorithms for new/upgrading projects. And it provides another alternative for those who wish to encrypt files for archiving.
But there are two different things here: encrypted communications and archiving files. The author wrote software for the latter and just gave up on the former.
I don't think it's particularly nice to just drop PGP email support (more and more of my peers are using it), but the other part is still interesting. It uses memory-hard key derivation, elliptic curve cryptography, and some other details that make this thing very good (for its job, at least). This is all fairly state of the art: it has been around for years, but very few systems actually use memory-hard key derivation or elliptic curve crypto. Having more tools use this stuff exposes it more and works encouragingly to others who are also in a position to choose algorithms for new/upgrading projects. And it provides another alternative for those who wish to encrypt files for archiving.
"encrypted communications and archiving files"
Independent marketing plan, identical backend tech.
If the goal was security should have just used gpg or openssl with a very small shell script wrapper around it instead of rolling his own. On the other hand if the goal was writing crypto obviously it achieved that, even if the spec isn't optimal.
Independent marketing plan, identical backend tech.
If the goal was security should have just used gpg or openssl with a very small shell script wrapper around it instead of rolling his own. On the other hand if the goal was writing crypto obviously it achieved that, even if the spec isn't optimal.
What is the issue with S/MIME for secure email? It has broad client support (assuming you don't use web based clients). It is a pain to setup for end users, but that could be solved if we started to see increasing adoption.
Yes, it still leaks metadata, but it is a start isn't it?
Yes, it still leaks metadata, but it is a start isn't it?
I'd like to know this too, mostly because I don't know enough about S/MIME.
> I only need to find a replacement for archival encryption.
Author replacing PGP with his own archive/file encryption software: https://github.com/skeeto/enchive
Author replacing PGP with his own archive/file encryption software: https://github.com/skeeto/enchive
In order to communicate confidential information using email, PGP remains the gold standard, and it's here to stay.
Using a different tool will just be annoying, and at many workplaces, people just can't install whatever software they want.
Sure, PGP isn't perfect. Or rather "tools leveraging the PGP format". MacGPG is constantly broken after a new macOS update. Overall, all GUIs suck. Nobody's using the chain of trust mechanism (Keybase isn't great either but from a usability perspective, it's way better). And I have to go through my shell history every single time I need to do something with GPG using the command line.
But when it works and you can remember how to use it, it does the job.
From a crypto perspective, it is also totally fine, and GPG has had support for ECC for quite some time.
Besides email, if I have to quickly share things with my coworkers or transfer things between computers, I always use Piknik instead, because it's way more convenient to use: https://github.com/jedisct1/piknik
And Minisign for signing software, because it assumes that people can install software on their computer anyway: https://jedisct1.github.io/minisign/
But for email... I don't see PGP going away anytime soon.
Using a different tool will just be annoying, and at many workplaces, people just can't install whatever software they want.
Sure, PGP isn't perfect. Or rather "tools leveraging the PGP format". MacGPG is constantly broken after a new macOS update. Overall, all GUIs suck. Nobody's using the chain of trust mechanism (Keybase isn't great either but from a usability perspective, it's way better). And I have to go through my shell history every single time I need to do something with GPG using the command line.
But when it works and you can remember how to use it, it does the job.
From a crypto perspective, it is also totally fine, and GPG has had support for ECC for quite some time.
Besides email, if I have to quickly share things with my coworkers or transfer things between computers, I always use Piknik instead, because it's way more convenient to use: https://github.com/jedisct1/piknik
And Minisign for signing software, because it assumes that people can install software on their computer anyway: https://jedisct1.github.io/minisign/
But for email... I don't see PGP going away anytime soon.
So long story short the author made an encryption tool and is now using it rather than PGP.
But my first thought was, why re-invent the wheel? Why not keybase or one of the many wrappers for pgp?
But my first thought was, why re-invent the wheel? Why not keybase or one of the many wrappers for pgp?
It seems like every couple weeks someone complains that PGP is dead and then suggests that everyone switch to an alternative.
The problem is, what do we switch to? Few of us are confident enough to roll our own and even if we did, how would we communicate if everyone is on different protocols?
For now, PGP works. Not very well, but at least it's useable.
The problem is, what do we switch to? Few of us are confident enough to roll our own and even if we did, how would we communicate if everyone is on different protocols?
For now, PGP works. Not very well, but at least it's useable.
> I couldn’t find anything that fit the bill, so I did exactly what you’re not supposed to do and rolled my own: Enchive.
Someone correct me if I'm wrong, but I think the main thing you're "not supposed to do" is create or implement your own primitives.
If you have a decent understanding of the software engineering and cryptographic implications around them - especially if you're using a high level library like libsodium, implementing high quality algorithms into your own applications is fairly well supported.
Of course, before anyone puts much faith in it they probably want some reputation at stake at the very least, but the primitives you've gone with are some of the hardest to screw up with the least weird side effects around.
Someone correct me if I'm wrong, but I think the main thing you're "not supposed to do" is create or implement your own primitives.
If you have a decent understanding of the software engineering and cryptographic implications around them - especially if you're using a high level library like libsodium, implementing high quality algorithms into your own applications is fairly well supported.
Of course, before anyone puts much faith in it they probably want some reputation at stake at the very least, but the primitives you've gone with are some of the hardest to screw up with the least weird side effects around.
If you look at the code on github he doesn't appear to have implemented the algos from scratch, rather he reused public domain code. It's still very much possible to make a mistake while wiring it all together though, especially in C.
EDIT: actually the curve25519-donna code is from Google and appears to be BSD-like. The chacha and sha256 implementations are public domain however.
EDIT: actually the curve25519-donna code is from Google and appears to be BSD-like. The chacha and sha256 implementations are public domain however.
Yeah, what's exactly what I was saying. He's using existing high quality algorithm implementations and integrating them into his new tool. The only custom part is how exactly he uses them in his code.
While it's totally possible to screw that up, it's also not really the majorly discouraged part.
While it's totally possible to screw that up, it's also not really the majorly discouraged part.
It's not just primitives that you're not supposed to reimplement. Wiring primitives together to build a secure full-featured system is very error prone. That's exactly why libsodium is recommended so often - it does most of the wiring for you.
"The process for encrypting a file:
(3) SHA-256 hash the shared secret to generate a 64-bit IV."
"The process for decrypting a file: (4) Validate the IV against the shared secret hash and format version."
Does anyone else see a problem with the above? I do.
"The process for decrypting a file: (4) Validate the IV against the shared secret hash and format version."
Does anyone else see a problem with the above? I do.
1. Isn't an IV supposed to be random, and definitely not derived from the plaintext?
2. The above comments about how crypto libraries should provide generic operations that always use the best possible cipher, like 'hash this for me', not 'SHA-256 this for me'.
2. The above comments about how crypto libraries should provide generic operations that always use the best possible cipher, like 'hash this for me', not 'SHA-256 this for me'.
IV seems way too short. However I'm not very familiar with Chacha20, so not sure if this is an issue.
One of the author's reasons for writing a new encryption program was to be able to generate key pairs from a pass phrase. This seems convenient but at the same time must increase risk of compromise. Unless the pass phrases are incredibly long and weird they are going to have less entropy than a long binary key pair. The rules of language and the restricted set of words might well make his encryption fairly easily breakable.
Seems like a nice but very risky idea.
Seems like a nice but very risky idea.
[deleted]
I hate these click-baity titles. I have decided to just flag them willy-nilly. They remind me too much of "one weird trick" and "he did ... and the result? amazing!"
> Curve25519 is used for the asymmetric cryptography role, using the relatively new elliptic curve cryptography. It’s stronger cryptography and the keys are much smaller.
Anyone has ever proven ECC is stronger than RSA?
> ... doing something strange like uploading my private keys onto the internet.
Which was completely unnecessary and he even admits it goes against the manual. There are many options, such as storing the copies in several physical places. But convenience trumps everything, I guess.
Anyone has ever proven ECC is stronger than RSA?
> ... doing something strange like uploading my private keys onto the internet.
Which was completely unnecessary and he even admits it goes against the manual. There are many options, such as storing the copies in several physical places. But convenience trumps everything, I guess.
> Anyone has ever proven ECC is stronger than RSA?
Proof? No, AFAIK, nobody ever proved anything in crypto (except that stuff are broken). Up to now, ECC has survived cryptoanalysis much better than RSA, and curve 25519 has some very good properties that makes it easier to implement it correctly that RSA (or other ECC algos). But there are no proofs.
Proof? No, AFAIK, nobody ever proved anything in crypto (except that stuff are broken). Up to now, ECC has survived cryptoanalysis much better than RSA, and curve 25519 has some very good properties that makes it easier to implement it correctly that RSA (or other ECC algos). But there are no proofs.
The article says: "I don't want to worry about per-file passphrases. Everything should be encrypted with/to the same key."
To me the above looks like the only differentiating requirement, and in my mind the solution is trivial: just use the same high-entropy encryption key for everything, and the problem is solved.
To me the above looks like the only differentiating requirement, and in my mind the solution is trivial: just use the same high-entropy encryption key for everything, and the problem is solved.
[deleted]
The author posted an FAQ that addresses many of these comments: https://github.com/skeeto/enchive#frequently-asked-questions
I don't see why use an assymetric algorithm to encrypt files which is slower and needs to manage public/secret files instead of just using a symmetric algorithm like AES, and store the passphrase in the brain
Asymmetric encryption can't be reversed by the sender, assuming you use the recipients public key. When I was dealing with PCI and other frameworks, PGP encrypted data was given additional leeway for the sender in terms of how it could be stored or transmitted because in the context of the sender, the cipher text is gibberish.
I don't follow... since the use case here is personal storage, then the sender and the receiver are the same person
I figured his reasoning would be something along this line of thinking: https://e-x-a.org/codecrypt
PGP is a failure because it has no critical mass, so author writes ~1300 lines of C code that will never reach critical mass, reinventing gpg-zip. Something something irrelevant swipe at email? Something something irrelevant swipe at git?
Author lists a few requirements, saying that PGP satisfies every requirement, and then says "I couldn’t find anything that fit the bill". Bullshit. This is a serious full-blinders-on NIH project.
Don't get me wrong, if you want to have fun writing a thing that does some stuff, and then you want to blog about it, cool. Rock on. Fun times had by all.
But don't be dishonest about it. That's just not right.
The only thing it’s [PGP] been successful at is signing Linux packages
Google "linux encrypt file" and nearly every single hit will be about encrypting files with gpg. Sigh.