Given how much of a huge pain it was to use PGP / gpg back in the days (for email encryption/signatures, to be precise), it's amazing how easy end-to-end encryption on Signal and Whatsapp is. And how it lacks that drama that somehow always surrounded GPG.<p>Is it really because trust on first use is good enough for most cases? Or is email somehow so much different than chat? Or was PGP the proof-of-concept, and current e2e encrypted platforms are the v1.0? Or all of the above? Did I miss anything important?
Ah, if only this was a thing a decade or two ago.<p>IMO, the way GPG was done killed what could have been a decent ecosystem. It's a combination of two factors:<p>1. Don't roll your own crypto.<p>2. The available code (gpg) is a colossal pain to use.<p>So for instance, how does something like KMail deal with gpg? There's no libgpg originally. There's just the gpg tool, so you've got to call it as a sub-process, and it really sucks:<p>1. You have to deal with process management, multiple filehandles, text parsing, non-trivial interactions, etc.<p>2. It's slow. You pay startup costs every single time. This is a huge problem on something interactive like a mail client, and it's dependent on things like the amount of keys in the gpg store.<p>3. gpg has very specific ideas about how it wants to be used, and not everything fits.<p>Say that you oh, want to do some stats on GPG keys. There's no libgpg to just read an .asc file and get the list of signatures from that, no. You have to call gpg, feed it the key, parse the result. For some things you might actually have to have gpg import the key first. Manage a fake home dir for GPG. Deal with the horrible performance as the keystore grows. A million keys at a gpg invocation per second is going to be around 2 weeks.<p>Unfortunately it's only now that gpg is effectively dead that the problem started to get fixed.<p>Also, at this point GPG is effectively a legacy technology anyway. Modern cryptographic thought considers GPG to be a terrible idea for a whole bunch of reasons that are deeply built into it, so the only solution for that is throwing it out.
Edit: The comment below is incorrect. I'm leaving it for transparency, but I misread where the padding is being applied.<p>I could be missing something here, but I think this is vulnerable to DO'1985, a/k/a Desmedt-Odlyzko:<p><a href="https://github.com/rpgp/rpgp/blob/8e67756ebce780c91b8c2ffc7db1f6230f8a9419/src/crypto/rsa.rs#L172-L178">https://github.com/rpgp/rpgp/blob/8e67756ebce780c91b8c2ffc7d...</a><p>In particular, in the presence of an insufficiently wide hash, the absence of padding here means that RSA signature validation is not secure under EUF-CMA. Matt Green has a great post on why and when EUF-CMA matters[1].<p>(This isn't necessarily this implementation's fault, since PGP seemingly (!) encourages the stripping of padding from signatures. But I can't find another source for whether this is actually encouraged by OpenPGP, or whether implementations just widely allow it.)<p>[1]: <a href="https://blog.cryptographyengineering.com/euf-cma-and-suf-cma/" rel="nofollow">https://blog.cryptographyengineering.com/euf-cma-and-suf-cma...</a>
GnuPG has by default started emitting keypairs with a preference for the LibrePGP version of the OCB block cipher mode. That mode is not compatible with what the other faction is doing and is not generally supported in any case. Arch[1] and other distributions have apparently patched this default out.<p>Is Rpgp emitting any new block cipher modes or generating keys that might cause such emission in the future? The risk here is a sort of incompatibility nightmare where decryption becomes a crap shoot.<p>My article on this mess:<p><a href="https://articles.59.ca/doku.php?id=pgpfan:schism" rel="nofollow">https://articles.59.ca/doku.php?id=pgpfan:schism</a><p>[1] <a href="https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism" rel="nofollow">https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_A...</a>
Rpgp is great (we're currently using it for a better git signer with smartcards) but I wonder why is it trending right now at HN? Maybe because it's currently #1 in the test suite? <a href="https://tests.sequoia-pgp.org/" rel="nofollow">https://tests.sequoia-pgp.org/</a>
This uses a flawed RSA implementation which is vulnerable to timing attacks:<p><a href="https://deps.rs/repo/github/rpgp/rpgp#vulnerabilities" rel="nofollow">https://deps.rs/repo/github/rpgp/rpgp#vulnerabilities</a><p>There is a reason why crypto primitives handling key material -- especially RSA and AES -- are not written in higher-level languages.