Comment by zaarn | Hacker News Reader

Comment by zaarn | Hacker News Reader

>Fun fact: Two different primary keys can have the same subkey. Anyone could even bind any of your subkeys to their primary key! They only need to sign the public key! Though, of course, they couldn’t actually use your key since they’d lack the secret key. It would just be really confusing, and could, perhaps in certain situations, even cause some OpenPGP clients to malfunction.

Can't wait for the next time someone clogs up the SKS system and tells us that GPG is terrible and the PGP ecosystem is essentially in a state of eternal trashfire, only to be told by the GPG wizards that everything is fine and working as intended, it will be fixed anyway by that one guy that volunteered on the mailing list to do it, they assure us.

Man, where would we be without the people that defend GPG? Possibly in a world with easy-to-use mail cryptography solutions but who wants that?

Otherwise this was a very interesting blogpost, I should probably upgrade my GPG keys at some point, considering they primar keys have been floating unencrypted into various public spaces.

> only to be told by the GPG wizards that everything is fine and working as intended, it will be fixed anyway by that one guy that volunteered on the mailing list to do it, they assure us.

Haha, actually this problem has been fixed for some time. Now subkeys need to be cross signed by primary key so yep you can share them but only with the key owner's private key.

For more details see: https://gnupg.org/faq/subkey-cross-certify.html

I don't think anyone complains about the format of PGP encrypted files or signatures. The protocol itself is just fine. All the exploits are in the key distribution or presentation layer.

e-fail is good example of a presentation failure. It has very little to do with PGP or GPG itself, but instead failures to adequately separate the output.

You have a few choices for key distribution.

1. A walled garden like keybase. 2. A distributed trust model like the web of trust. 3. A bunch of web servers with no proof the key has not been tampered with.

All of them have benefits and flaws.

Well, it's been established by PGP being deployed that the web of trust did not work well at all. So that option is out.

Web of Trust is still used in small, focused circles, for example kernel.org developers: https://www.kernel.org/doc/wot/

Yes but "small focused circles" is essentially the extent of where WoT works. It doesn't scale to larger or loose communities.

And that's fine. It is a great way to bootstrap a small circle of trust that can be used apart from any large centralized infrastructure.

It seems like everyone is trying to find a way to make a global trust network (keybase, LinkedIn, etc.), when all you need most of the time are small circles of trust (dev groups, activism organizations, etc.).

I think the decentralized nature of WoT is actually a better way of structuring things, since it makes mass surveillance much more difficult.

For small communities, yes. But I doubt it works even for just a large set of communities. Possibly a small set if you're careful. But WoT is too broken in reality.

4. DNS (sort of a walled garden, yes)

5. Adding a fingerprint to all e-mails you send out (people online you never met/meet only know you by your online behavior anyway) so cross-checking a few mailing list archives the user posted to in the last few years should be enough. This is most useful if you are subscribed and can be thus sure that the archive was not manipulated.

> 4. DNS (sort of a walled garden, yes)

IMHO, Web Key Directory is a better option here. It has all benefits of DNS but none of the drawbacks (DNS has plain text queries etc.)

Very nice.

Both DNS and WKD are real-time, and modifiable by an attacker. There's no trail of trust/history. It may be good for discovery, but trusting the key requires more.

I guess that it's better to have multiple independent ways to validate ownership of a key after you discover it. Cross-check various methods that require different levels of access, to see if something is fishy.

Anyway, I'm off to implement wkd. :)

The protocol is still pretty bad engineering, with plenty of ways to screw up.

I work in an industry which uses PGP unfortunately, and a bunch of implementations. It's very difficult to use modern, secure cryptography with PGP. There are so many different options and backwards compatibility hazards when dealing with whatever other PGP implementations exist. There are many bad options you can choose in PGP, and lots of software gets it wrong. Old ciphers like IDEA and CAST5 are used. Old school RSA padding. The MDC tags are still Sha1 I think.

Badness everywhere.

Matt Green wrote about some of this in 2014; I don't think much has changed. Section "The OpenPGP format and defaults suck" https://blog.cryptographyengineering.com/2014/08/13/whats-ma...

People keep saying Efail had "very little to do with PGP or GPG". That's not true, and is a little like saying a Win32 RCE has little to do with the OS and everything to do with the CALC.EXE it pops in its POC. The underlying vulnerability in Efail is PGP's malleability, and GnuPG's willingness to release unauthenticated plaintext to callers. All the active content email stuff is exploit details --- the ROP gadgets to Efail's underlying memory corruption bug, to extend the analogy.

I get the feeling, in all these discussions, that people with strong negative feelings about Efail never read the paper (accepted at Usenix Security, one of the top academic venues for vulnerability research, and Black Hat USA, the top industry venue), but instead just took the GnuPG team's word about it. That's a mistake.

Reply on news.ycombinator.com