5 ms·

FWIW, the "crypto refresh" of the OpenPGP standard specifies the use of AEAD for authenticated encryption, replacing the SHA-1 "modification detection code". Ev

by twiss 4y ago

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 :)

upofadown 4y ago
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...
- twiss 4y ago
  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.
  - upofadown 4y ago
    >The other two are optional,... 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?
    - twiss 4y ago
      > 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 ^.^).
- deleted 4y ago
  [deleted]

by twiss 4y ago

upofadown 4y ago

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...

twiss 4y ago
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.
- upofadown 4y ago
  >The other two are optional,... 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?
  - twiss 4y ago
    > 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 ^.^).
deleted 4y ago
[deleted]