FWIW, the "crypto refresh" of the OpenPGP standard specifies the use of AEAD for authenticated encryption, replacing the SHA-1 "modification detection code". Even if the latter isn't broken, the former is more modern and more performant, and so retconning the use of SHA-1 for optics shouldn't be necessary once everyone moves to that :)
Even assuming that anything real comes out of the "crypto refresh" (it seems to be going the way of the last effort) it would still be irresponsible to promote the use of an entirely incompatible encryption mode for no real reason. The existing standard has been in use for over 20 years now. Even if there were some sort of security weakness discovered it would make more sense to try to resolve that issue in some sort of backwards compatible way. Since there is no weakness then the best course of action seems pretty clear and is really easy to do. The crypto refresh is currently attempting to add no less than three new authenticated encryption modes in addition to the existing one for a total of four. Each and every mode is entirely incompatible with the others. This strikes me as sort of nuts...
Only one of them, OCB, is mandatory to implement. The other two are optional, but there may be performance or compliance reasons to use one of them. E.g., people who care about FIPS compliance may want to use GCM.
In any case, since there are feature flags and algorithm preferences to signal support for these, all of this is in fact backwards compatible. There's little risk that someone will accidentally use an AEAD mode to encrypt a message for a recipient that doesn't support it, since the recipient needs to signal support for it in their public key.
And, offering performance and security benefits for those that care to upgrade their implementations and keys is still a worthy goal, IMHO.
That just makes things worse. The OpenPGP standard covers the offline, static encryption case. You have an encrypted file or message. If your implementation has implemented the encryption method then you can decrypt it. If it doesn't than you can't. Contrast this with an online, dynamic method like TLS where you can negotiate a method at the time of encryption and decryption.
>In any case, since there are feature flags and algorithm preferences to signal support for these, all of this is in fact backwards compatible.
The OpenPGP preferences are not applicable to symmetric encryption. In that case the implementation has to guess what method will be supported by the decrypting implementation. In most cases it would make sense to use the most widely implemented method. That is always going to be the one that has been used since forever.
The OpenPGP preferences are included in the public key at key generation time. They reflect the capabilities of that implementation. The public key then has a life of it's own. It is quite normal to use that key to encrypt material for other implementations. Having optional methods, again, makes things much worse here. This is not a theoretical problem. I have already been involved in a difficult usability issue caused by an implementation producing one of these new incompatible encryption modes. The file was created on the same implementation as the public key. So the implementation saw that the reciepient supported all the same methods that it did. But the actual implementation that did the decryption did not support that mode. This sort of interoperability problem, even if it only happens from time to time, seriously impacts usability. That is the ultimate issue. Why are we making things harder for the users of these systems for no real reason?
> The OpenPGP preferences are not applicable to symmetric encryption. In that case the implementation has to guess what method will be supported by the decrypting implementation. In most cases it would make sense to use the most widely implemented method. That is always going to be the one that has been used since forever.
I agree, if you don't know the capabilities of the implementation decrypting the message then it makes sense to be conservative, and wait until AEAD is widely implemented before using it.
> I have already been involved in a difficult usability issue caused by an implementation producing one of these new incompatible encryption modes.
I also think that generating AEAD encrypted OpenPGP messages today is irresponsible, since the crypto refresh is still a draft, not an RFC yet. Even if the decrypting implementation can read the message today, the draft could still change (although now that it's in Working Group Last Call it's unlikely), and then you'd have an even bigger problem.
But I think that's the fault of the implementation, not of the (proposed) standard. If we eventually want to have the security and performance benefits of AEAD, we have to specify it today (well, or yesterday, but that's a bit hard to change now ^.^).
>If we eventually want to have the security and performance benefits of AEAD,...
The thing is, there doesn't seem to be any security weaknesses with the existing AE method. I have looked hard. There also doesn't seem to be any need for the AD (associated data) part.
OCB seems to be the fastest out of all of them. If the proposal was just to add on OCB as an enhanced performance mode then I might be OK with that. Why make the people encrypting multi-TB files wait? I am mostly grumpy with the idea that we have to drop an existing well established standard for stuff like messaging and less extreme file sizes.
> The thing is, there doesn't seem to be any security weaknesses with the existing AE method. I have looked hard.
Even if nobody found any concrete security issues, there might be compliance reasons not to use SHA-1, as indicated by the OP. It's easier to switch to something new than to endlessly explain to auditors that actually in this particular case the use of SHA-1 is probably fine. Also note that there's no security proof for the MDC, making it harder to convince such auditors.
> There also doesn't seem to be any need for the AD (associated data) part.
I personally disagree: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145. The paper linked there explains why having AD would be useful. But I'll grant you that the crypto refresh doesn't make significant use of it yet, so it can't really be counted as an advantage for AEAD yet.
> OCB seems to be the fastest out of all of them. If the proposal was just to add on OCB as an enhanced performance mode then I might be OK with that. Why make the people encrypting multi-TB files wait? I am mostly grumpy with the idea that we have to drop an existing well established standard for stuff like messaging and less extreme file sizes.
I'm not sure I understand what the concrete difference would be between what you're proposing and what the crypto refresh does? It introduces a new mode and encourages its use, but doesn't disallow the use of the current mode. That being said, once OCB is widely deployed, why would you want to use CFB instead of OCB?
>Also note that there's no security proof for the MDC,...
I am not sure what aspect of the MDC you would want to prove. The security properties of such constructions are well understood at this point[1]. It is a simple scheme. It has been under scrutiny for 20+ years. It isn't really possible to prove a scheme secure in general. What happens in practice is that it turns out that an assumption is incorrect. The MDC requires few assumptions and is probably more secure than other more complex schemes.
>The paper linked there explains why having AD would be useful.
I don't find that very compelling. The scheme described talks about a false positive rate. Such a thing would not be acceptable in normal PGP usage. I am also not convinced that such a scheme is impossible without AD.
As already mentioned, I am concerned about the ethics of changing a long term standard for no good reason. The users do not deserve the wave of low level interoperability problems such a proposal would create. Usability is a serious issue for end to end encrypted messaging of all types and should be prioritized.
