[sleepless]

Nice writeup.

It is a serious problem that the ecosystem is held back by wasting resources on personal disputes with immediate consequences for end users.

Hate on OpenPGP all you want, it still is an important technology with unrealized potential and growth.

[femiagbabiaka]

It’s not actually clear from reading through this document or others, or the linked email threads, etc. that there is a personal dispute at play, or what that might be. I’m also not sure who the target of this document is, or who wrote it. It’s also not clear what the forcing function behind the strong recommendations at the end is — will the author fork GnuPG in the event a resolution can’t be reached?

[freedomben]

It doesn't sound like a personal dispute to me, it sounds technical. One camp (Open) wants to move faster and break backward compatibility, the other (Libre) wants to move slower and maintain backwards compatibility

[throw0101b]

> One camp (Open) wants to move faster and break backward compatibility, the other (Libre) wants to move slower and maintain backwards compatibility

There is no breaking of backward compatibility. The crypto-refresh draft and the LibrePGP draft are equally backward-compatible.

See 'A Critique on “A Critique on the OpenPGP Updates”':

* https://blog.pgpkeys.eu/critique-critique

Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format.

The Proton folks are choosing to support both v5 and v6:

* https://github.com/ProtonMail/go-crypto/pull/182

As is the Thunderbird/RNP team:

* https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855...

[daveguy]

It seems like maintaining backwards compatibility would be important for something that otherwise irreversibly encrypts your data.

[woodruffw]

The correct way to maintain backwards compatibility in those contexts is to decrypt and re-encrypt, not support broken ciphers or weak modes of encryption indefinitely. The latter is security theater.

[asveikau]

A read-only operation should not cause an insane amount of writes. This is perilous for a great many reasons, one of which is the risk of data corruption should something go wrong.

[woodruffw]

You're thinking about this the wrong way: if your data needs to be secure, then it's already perilous to keep it around with with weak or broken encryption. Security models where data is too important to risk encryption upgrades but not important enough to encrypt correctly are internally incoherent.

(This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes or why performing cryptographic upgrades is somehow uniquely, unacceptably risky from a data corruption perspective.)

[asveikau]

No, I think you're thinking about it the the wrong way: write failures are common. The failure mode for a bad disk is often that reads will succeed and writes will lose data. Something that silently writes like this is increasing the risk of data loss.

It probably depends a lot on the application, but I think it's often much better to have something that will warn the user about security risks and let them decide what to do with that risk. If you do design something with these silent writes, you absolutely need to think hard about failure cases and test them, and not handwave them away. Having the most "secure" data be corrupted is ultimately an unacceptable outcome.

That's not even getting into the other problems, such as ... is it ok for the user to take a performance hit of writing X GB when all they want to do is read a file?

[b112]

No.

There is 100% value in being able to decrypt a 20 year old email. It doesn't matter if it is a broken cypher.

A 20 year old email has very little actionable in it, but can have value in other ways.

It is absolutely vital that a project like this, supports some means for a modern machine/stack to access older data.

[tptacek]

This is silly. Nothing that happens with the standard or its implementation is going to prevent you from decrypting a 20 year old email. It shouldn't need saying, but one reason for that is that PGP's cryptography is schoolbook cryptography.

[b112]

This is silly

Upstream spoke of deprecated support for older emails. My response is aimed there.

And there is loads of software that will not compile on modern hardware. End users don't often have that ability to re-write, or even to easily validate a random bit of code on github.

A project like this, needs to maintain backwards operability. For decades.

[panarky]

I read the article and couldn't find any hint that previously encrypted data would be undecryptable by either branch of the fork.

Is there a real risk of this that I missed, or are you just free-associating off the term "backwards compatibility"?

[daveguy]

The article specifically refers to backward compatibility with RFC4880, RFC5581, and RFC6687. These specifications include encryption techniques. So no. I was not just "free associating". Please do not assume the worst, because it could be that you just haven't understood the implications of the article.

[Nextgrid]

On the other hand, as long as earlier versions or their sources remain available, it doesn't sound like a major problem to me. The sources would effectively be documentation for the previous format and can be reimplemented if needed.

[nvy]

I think the common refrain against PGP is that it shouldn't be important, because it suffers from a myriad of technical and sociological shortcomings.

The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire.

[0xDEAFBEAD]

>The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire.

Can you explain why?

People elsewhere in this thread are saying that PGP sucks because it tries to do too many things at once, but it seems to me that the one big advantage of a tool which does everything at once is that you only need to solve authenticity one time for everything you do.

For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?

[nvy]

>Can you explain why?

Well, the key servers are useless because they are susceptible to that poisoning attack from a few years ago, and they happily send you fraudulent or revoked keys.

And the web of trust doesn't scale. The trust ratings mean different things to different people, the propagation of revocation certs and signatures is slow, and rotating keys is onerous.

>For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?

How often do you check the fingerprints of that key? Do you verify out of band when the developer rotates their key? (Haha just kidding, PGP users essentially never rotate keys)

If you care enough to encrypt your emails, then what is the virtue of verifying less frequently that you're talking to the correct persons?

Why wouldn't you want separate keys for all those things?

Why would you want an adversary to be able to compromise a single key and have the ability to forge commits, emails, and whatever else?

[0xDEAFBEAD]

>How often do you check the fingerprints of that key? Do you verify out of band when the developer rotates their key?

I'm almost certain PGP best practice is to have a single master key, kept on an airgapped device, that's used to sign subkeys for various purposes like email, commit signing, etc. So I only have to verify out of band once, unless the airgapped device gets compromised or the master key encryption is broken.

[nvy]

What percentage of PGP users actually have an airgapped device and actually go through all that rigamarole?

More importantly, how do you know that your counterparty is one of that (extremely small) minority?

[0xDEAFBEAD]

PGP users are a minority to begin with. I wouldn't be surprised if a lot of them do this. I think I got that rec from a PGP beginner guide I found the other month.

Don't forget about PGP smart cards either. You could keep the master key you use to sign subkeys on a smart card. A smart card should be harder to hack than your phone.

Qubes has built-in "split GPG" support that allows you to e.g. sign something using your private key while keeping it in a different VM. See https://www.qubes-os.org/doc/split-gpg/

I know PGP isn't for everyone, I just like the idea of keeping high-security options available for those who want them.

>More importantly, how do you know that your counterparty is one of that (extremely small) minority?

You could ask them :-)