I've always thought that #pgp was pretty good, but I just came across this seemingly reasonable article that is *very* critical of it: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
* pgp has weak security options and code complexity for backwards compatibility with the 90s
* because of that, pgp is really easy to misconfigue with poor security
* pgp doesn't provide forward secrecy
* pgp encourages you to have one master key that you never change, instead of rotating
> I've always thought that #pgp was pretty good, but…
(I'm slightly disappointed that, of all the many replies I got to the above toot, *none* of them were "I see what you did there")
@codesections It's a bit abandonware by now, and the domain name got lapsed/squatted, but the "Minilock" encryption system was designed to fill the niche left by PGP's slide into obsolescence and I'm a big fan.
Fair notice: I implemented Minilock twice for Python and Go, so I'm somewhat invested in the idea. But the design and threat model is, IMO, really well done and suitable for what PGP was most commonly used for: session-less confidentiality over arbitrary mediums.
@codesections In a way, miniLock's design is like a cheat-sheet of the ways that PGP is (now, with our modern level of knowledge) bad:
* Minimised metadata on sender/recipients
* Authenticated but repudiable
* Multi-recipient by default
* No outdated ciphersuites
* Arbitrary contents
* Easy to implement (given the underlying primitives: libnacl)
@cathal @codesections Uhhh I haven't heard of Minilock so far and it seems to be a great tool for certain use cases. I really like the minimalist approach on key management.
It doesn't provide forward secrecy though...
If you need features like key signatures or the Web of Trust, there is still no proper replacement of GnuPG. (e.g. the Archlinux package signing makes heavy use of it in a really elegant way IMHO)
@phel @codesections Forward secrecy is only relevant in session-based protocols: Minilock is sessionless, like PGP it's designed for single messages.
The lack of signatures is a minor disappointment but really they are a separate concern, and even introduced some big security gotchas in PGP (e.g. signing and encrypting with same key, for some types of key, could lead to a viable attack on the private key!). Maybe better to keep separate.
> Forward secrecy is only relevant in session-based protocols: Minilock is sessionless, like PGP it's designed for single messages.
I don't understand this. I thought the issue with forward secrecy was that an adversary could store the ciphertext and decrypt it later if they compromise the secret key in the future (either through accessing the key or advances in computing power). How is being sessionless relevant?
Or am I confused?
@codesections @cathal Yes, that's right... but Forward Secrecy today always employs some sort of key negotiation before transmitting messages. Then, only the new negotiated key is used and discarded after use.
For this key negotiation, a session is needed AFAIK. I don't know of any protocols employing Forward Secrecy but no session-bound key negotiation.
@phel @codesections Pretty much this: in order to negotiate a temporary key which is not attached to the message itself, and can therefore be "forgotten" to prevent later decryption even with the private key, you need some sort of communication channel and session.
The best systems even have "ratchets" to allow session keys to constantly advance themselves and delete old ones, like Axolotl and Olm do.
For a sessionless thing like PGP and Minilock, it's not rly possible.
@codesections Yes, PGP is a hot mess. It’s historically important. We owe Phil Z our gratitude for getting a secure communication tool into people’s hands. Also, the PGP manual is still worth reading to this day.
In addition to the other problems you listed, PGP is way to hard to use. Even the #infosec wonks I know don’t bother using PGP. There’s no way we can expect Joe and Sally Citizen to use it.
@codesections Are you on Keybase? Keybase is the first tool I’ve seen that gives us a shot of the PGP web of trust.
Now they’ve added some even more useful tools: e2e encrypted chat and an e2e encrypted file share. These turn out to be pretty handy.
> Are you on Keybase? Keybase is the first tool I’ve seen that gives us a shot of the PGP web of trust.
I am on Keybase—at least sort of. Somewhat ironically given the "pgp makes it hard to rotate keys" argument, I've rotated my master key and am using it with pgp but have not yet gotten around to updating keybase (which *also* is annoying to rotate keys with).
(I didn't have a breach or anything. I just realized I hadn't had ideal security practices with my old secret key)
As you pointed out, that's one of the big flaws in PGP's model—it actively discourages key rotation but good practice is to rotate keys periodically.
The article has many small issues. First of all “We use the term “PGP” to cover all of these things.” is omitting critical details.
First of all “PGP” is a trademark of Symantec (see https://www.symantec.com/about/legal/trademark-policies) used for their suite of encryption tools. These tools implement IETF standard: OpenPGP (RFC 4880). There is a second implementation that is free: GnuPG (aka. GPG).
Most of critical points there are targeted at GnuPG that indeed has enormous code complexity (I’ve read parts of it) and defaults. But defaults tend to get better and better so most of “My perfect GPG key pair” articles become quickly obsolete.
There are, as with other standards, alternative implementations such as Sequoia, written in Rust: https://sequoia-pgp.org/
There is no forward secrecy because it’s quite hard to implement it in a long asynchronous communication such as e-mails and files. Forward-secrecy works in IM.
OpenPGP has a notion of rotating keys built-in with subkeys and expiration dates. Additionally the design allows for the master key to be kept offline. The same thing is implemented in new, modern protocols, such as Google’s Roughtime: https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md#certificates
That said the tool has many sharp edges so it’s not quite fit for the masses, but there are people that want to improve the status quo. Check this out: https://twitter.com/Valodim/status/1161940700679811072
> First of all “PGP” is a trademark of Symantec
Yeah, I know. But I tend to agree with the view that that's no longer common usage, as expressed here:
> I used to only refer to PGP keys as “GPG keys” and I didn’t like using the term PGP at all because there’s a proprietary encryption product (that no one uses, and no one should use) that used to go by the name. But then, as I learned more, I realized that PGP is simply a more accurate term.
(quote continues below)
> GPG is short of GnuPG, a free software encryption program that complies with RFC-4880, which is the current technical spec that describes the OpenPGP message format. When I use the term PGP, as in, “Here is a copy of my PGP key,” it’s short for OpenPGP, and has nothing at all to do with the proprietary program. Many different projects comply with the OpenPGP spec, like Google’s End-to-End, …, and pgpdump, to name a few – and none of these share code with GPG.
> OpenPGP has a notion of rotating keys built-in with subkeys and expiration dates. Additionally the design allows for the master key to be kept offline.
Yeah, I've recently started keeping my master key exclusively offline. Though I lose some of those benefits by not actually having set the subkeys to expire…
Is there a reason you’re not using expiration? I’ve got mine set for a year and adjust the expiry once a year and it’s not a big problem.
For the record I attach a nice article about expiration (for wider audience): https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/
> Is there a reason you’re not using expiration [for your PGP subkeys]? I’ve got mine set for a year and adjust the expiry once a year and it’s not a big problem.
Mostly laziness, I guess? But I also don't understand how expiry would help.
Here's my setup: My master key is backed up on four USB drives kept offline. I use the key via a yubikey that contains signing/encryption/auth subkeys; those keys aren't saved anywhere else.
What threat model would expiration protect me against?
Let’s say you want to emulate forward-secrecy. You could issue new encryption key every year (or month) securely erasing the old one. Thus your old messages wouldn’t be recoverable even if you’re compelled to give your private keys to authorities. This scheme critically depends on expiry so that your communication partners encrypt to correct (active) key.
Another example: I used subkeys generated on hardware (on a Yubikey) so that the private parts are never visible for software. It turns out the generator was buggy: https://www.yubico.com/2017/10/infineon-rsa-key-generation-issue/ What did I do? Just generate a clean signing keys (this time in software or on good tokens) and rotate them. If my subkeys did not use expiry people could skip refreshing and still have my buggy subkeys marked as “valid”.
What do you mean by “those keys aren’t saved anywhere else.” Do you mean that the private keys are not on online computers or something else?
> What do you mean by “those keys aren’t saved anywhere else.” Do you mean that the private keys are not on online computers or something else?
I mean that the subkeys were generated in a temporary ramfs directory and then moved to the Yubikey. So, to my knowledge, the subkeys now exist *only* on the yubikey.
(I was following this guide:
The master key is backed up in four offline places, so I could generate new subkeys.
> Let’s say you want to emulate forward-secrecy. You could issue new encryption key every year (or month) securely erasing the old one. Thus your old messages wouldn’t be recoverable even if you’re compelled to give your private keys to authorities. This scheme critically depends on expiry so that your communication partners encrypt to correct (active) key.
Hmm, but (please correct me if I'm wrong!) wouldn't the authorities be able to read those messages if they had the master key?
No. Master key is only for adding/removing subkeys or user IDs or signing other people’s keys (Web of Trust). Only encryption subkey can decrypt stuff (there is an edge case where you can make the master key additionally act as encryption key but that’s rare).
If you created your encryption subkeys in ramfs and moved them to Yubikeys that means when you lose/break/accidentally lock the token you won’t be able to decrypt stuff.
Worse, if you’re not using expiry and lose the tokens (knocking on wood!) people can still send you stuff encrypted to your old encryption subkey. Even if you add new encryption subkey and revoke old, without expiry people can use old one if they don’t refresh.
Some people do it on purpose — destroying private encryption key means old messages are not recoverable.
Aha, thanks, I was confused. I misread this section of that guide:
> When a sub-key expires, it can either be renewed or replaced. …
Replacing keys, on the other hand, is less convenient but more secure: the new sub-keys will not be able to decrypt previous messages, authenticate with SSH, etc.… However, you will always be able to decrypt previous messages using the offline encrypted backup of the original keys.
I thought that meant "original *master* key", but it meant "subkey"
Given that, I should check that the offline backups I created had the subkeys—thought they didn't, but after looking back at the guide I followed, they *should* have. So I'll need to confirm.
But, assuming I *do* have those keys backed up, I'm still not entirely sure I understand what threat expiry would protect me against.
Consider this setup:
1) Yubikey with current subkeys
2) Offline backups with master key, current subkeys, and past/expired subkeys
Here's my view:
If an adversary obtains access to the offline backups (or compels their production) then expiry doesn't help.
If an adversary has physical access to the yubikey, they cannot access the contents without the yubikey PIN (which resists brute-forcing by wiping the key after 5 wrong entries). So expiry doesn't help.
If they have access to the yubikey *and* the PIN, but *not* the backups, then the expiry helps.
But it's hard to imagine how that could happen.
Am I missing something?
It protects you against issues you don’t know about now.
For example when Debian Weak Keys issue was discovered (see: https://certlogik.com/debian-weak-key-check/) there were many such weak keys in the wild.
What if your subkeys are weak now but no-one knows how? If you use expiry you’ve got an option of rotating subkeys and people will need to refresh your key to use it. If you don’t use expiry people can still work with your old, potentially compromised subkeys forever.
Expiration forces other people to refresh your key.
Ok, yeah, that makes sense. And seems like a good reason to set up expiration. I'll put that on my to-do list!
Thanks for all your replies—I've learned a lot in this conversation :D
Haha, no problem! Glad I could be of service.
By the way, one more thing :) you may want to put your binary (not armored) key on this location: https://codesections.com/.well-known/openpgpkey/hu/8w8uz8qhiusdbtyyttxygducnq18t14x
That’ll make Enigmail and some other OpenPGP clients automatically fetch your key when an e-mail is composed to your address. This is called Web Key Directory and used by an increasing number of OpenPGP-conscious software and sites such as kernel.org: https://www.kernel.org/category/signatures.html#using-the-web-key-directory and Linux distros (Debian, Arch, Gentoo...)
See more details here: https://spacekookie.de/blog/usable-gpg-with-wkd/
I don’t mind you, Micah or regular people using the term “PGP”. But the article criticizing things should be impeccable as some of these argument are purely related to one implementation and some relate to the spec.
It’s like an article “The Cars problem” but when you read it it’s only about VW Golf (I hope I’m not pulling the analogy too much).
> I don’t mind you … using the term “PGP”. But the article criticizing things should be impeccable as some of these argument are purely related to one implementation and some relate to the spec.
That's a fair point, and I agree the article should have drawn a sharper distinction
> It’s like an article “The Cars problem” but when you read it it’s only about VW Golf
Well, if ~90% of the cars on the road were VW Golfs, I'm not sure I'd really mind :D
(what a dystopia that would be!)
> Well, if ~90% of the cars on the road were VW Golfs, I’m not sure I'd really mind :D
Yep, that’s also good point although even Micah knows about recent movements to decentralize OpenPGP, such as Sequoia, https://keys.openpgp.org, Autocrypt and others.
I think the standard is vastly underutilized, for example I wrote a “social proofs” PoC, like Keybase but using OpenPGP only: https://github.com/wiktor-k/openpgp-proofs There are many, many more things one could do with it.
The problem tptacek (article author) has with PGP is that it’s advertised to regular users. They can, and will, misuse it. Ptacek’s recommendation? Signal, or even Whatsapp. It’s simple and it’s using state-of-the-art crypto. (Source: his comments on HN).
Still, Signal is not an IETF standard and the alternative implementations are discouraged: https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165
Keybase has a lot of nice features but ultimately it’s just a service. It may be partially open-source, partially closed and proprietary (see: https://github.com/keybase/client/issues/6374) but it’s not really comparable to OpenPGP.
OpenPGP is a standard that welcomes multiple implementations (see also: https://www.ietf.org/about/note-well/). Keybase, on the other hand, is just a service with unclear financing model.
For the record some features of Keybase, like social proofs, can be implemented in pure OpenPGP, with no trusted third-parties: https://github.com/wiktor-k/openpgp-proofs#openpgp-proofs
Lots of institutions send an email with a link to a website where they store the message, this way they can implement "burn after reading", destroy the message after some time if unread, and they can even ask for a second authentication factor in addition to the cookie in the URL they emailed you. And it's sent over TLS to your browser...
Yup, that's where we are...
>>> I've always thought that #pgp was pretty good, but…
>> (I'm slightly disappointed that, of all the many replies I got to the above toot, *none* of
them were "I see what you did there")
> Hmm, would you care to enlighten us?
(PGP stands for Pretty Good Privacy, and I was saying it was "pretty good". It wasn't all that funny to begin with, and much less so now that it's explained!)
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.