It seems to me that there are at least 3 decisions to make when
considering the implementation a new block cipher mode:
1. If your implementation will receive the block mode. Receiving a
block mode does not cause an interoperability problem. If anything,
this improves interoperability.
2. If your implementation will generate the block mode. This can
possibly cause incompatibility.
3. If your implementation will cause other implementations to generate
the block mode. This can also possibly cause incompatibility.
So if you were interested in seeing a new block mode in OpenPGP, there
is no reason not to do #1. The controversial parts are #2 and #3. If
you were interested, in say, having the OCB block mode in OpenPGP then
you would have the greatest chance of success by implementing the most
popular version of the available 2 proposals. Correct me if I am
wrong, but that would be the LibrePGP (4880bis) version.
So just to be clear, I am not complaining that GnuPG implemented the
LibrePGP version of OCB. I am complaining that GnuPGP did #2 and #3
before implementation was close to universal and did not clearly spell
out the implications to the users.
Speaking of documentation, the implementations that support LibrePGP
OCB could be promoting the the non-controversial aspects of the new
mode. That could help with adoption. Dunno, something like:
Now with super ultra performance! Just add the "--performance"
option and get up to 400% faster encryption!
... where "--performance" would turn off compression, enable the OCB
block cipher mode and do whatever else will speed things up. The user,
of course, would be made aware the the resulting files might not be
decryptable everywhere.
Arch Linux is just dropping #3 with their patch. Their version of
GnuPGP still supports the OCB mode and can generate it. So they are
not really taking a political stance. The history of Linux
distribution patches for stuff like this is not good (the Debian patch
against Openssl for example). It would be better if Linux
distributions were not tempted to issue such patches. There really
should be a better way of doing this. Otherwise the users will
encounter different behaviour on different Linux distributions.
Bruce
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
