Why I've Retired My PGP Keys and What's Replaced It
nullprogram.com
nullprogram.com
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.
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.
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.
> 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 !
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.
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>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/
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.
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.
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.
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.
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.
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.
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.
Yes, it still leaks metadata, but it is a start isn't it?
Author replacing PGP with his own archive/file encryption software: https://github.com/skeeto/enchive
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.
But my first thought was, why re-invent the wheel? Why not keybase or one of the many wrappers for pgp?
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.
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.
EDIT: actually the curve25519-donna code is from Google and appears to be BSD-like. The chacha and sha256 implementations are public domain however.
While it's totally possible to screw that up, it's also not really the majorly discouraged part.
"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.
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'.
Seems like a nice but very risky idea.
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.
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.
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.