
Why I've Retired My PGP Keys and What's Replaced It - yarapavan
http://nullprogram.com/blog/2017/03/12/
======
BugsJustFindMe
_I decided to take this opportunity to retire my PGP keys for good. Over time
I’ve come to view PGP as largely a failure — it never reached the critical
mass, the tooling has always been problematic, and it’s now a dead end._

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.

~~~
cmurf
Ignorance != dishonesty

~~~
BugsJustFindMe
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.

------
rakoo
From [https://github.com/skeeto/enchive](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 !

~~~
marcosdumay
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.

------
simias
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:

    
    
        openssl aes-256-cbc -a -salt -in <cleartext-file> -out <encrypted-file>
    

And in order to decrypt:

    
    
        openssl aes-256-cbc -d -a -in <encrypted-file> -out <cleartext-file>

~~~
rakoo
Beware, if you do that your encrypted file is not authenticated.

------
ryan-c
> 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/](http://nullprogram.com/blog/2012/06/24/)

~~~
orblivion
This seems to be the danger that Keybase.io is convincing people to put
themselves in as well huh.

~~~
StavrosK
Why do you say that? Keybase doesn't generate keys from passphrases.

~~~
orblivion
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...](https://blog.filippo.io/on-keybase-dot-io-and-encrypted-
private-key-sharing/) 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.

~~~
StavrosK
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.

~~~
orblivion
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.

~~~
StavrosK
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.

------
rasengan
_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.

~~~
VLM
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.

------
lucb1e
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.

~~~
VLM
"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.

------
josho
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?

~~~
mstade
I'd like to know this too, mostly because I don't know enough about S/MIME.

------
jonathonf
> 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](https://github.com/skeeto/enchive)

------
jedisct1
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](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/](https://jedisct1.github.io/minisign/)

But for email... I don't see PGP going away anytime soon.

------
INTPenis
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?

------
colemannugent
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.

------
problems
> 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.

~~~
simias
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.

~~~
problems
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.

------
sdrapkin
"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.

~~~
koenigdavidmj
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'.

------
jimmyswimmy
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.

------
1024core
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!"

------
rini17
> 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.

~~~
marcosdumay
> 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.

------
cuspycode
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.

------
netguy204
The author posted an FAQ that addresses many of these comments:
[https://github.com/skeeto/enchive#frequently-asked-
questions](https://github.com/skeeto/enchive#frequently-asked-questions)

------
tulsidas
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

~~~
TenOhms
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.

~~~
tulsidas
I don't follow... since the use case here is personal storage, then the sender
and the receiver are the same person

------
openfuture
I figured his reasoning would be something along this line of thinking:
[https://e-x-a.org/codecrypt](https://e-x-a.org/codecrypt)

