On Wed, Mar 06, 2024 at 09:43:00AM +0100, Werner Koch wrote:
> On Tue, 5 Mar 2024 11:15, Bruce Walzer said:
>
> > 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
>
[...]
> OCB mode is only used if all recipient's key have the flag that they
> support this mode.
Yes, and I agree that the preference system here is helpful. But I
have a list of 22 instances where it did not work. Those are up to
this point entirely from GnuPGP emitting new block cipher modes and
are mostly between different versions of GnuPG. Things could easily
get worse going forward.
> This is not different from the preferences for a certain cipher
> algorithm. For example AES in the old days. The migration from
> CAST5 to AES worked without any noticeable problems because after we
> implemented AES, we announced that in the keys and the peers started
> to use AES iff all recipients claimed that they support this flags.
The difference here is that most users have a general idea of what
these algorithms are and what it means when support for decytption is
not available. Few people know about cipher block modes. The messages
that they get won't even refer to cipher block modes, instead it will
be some sort of obscure internal error. For example, GnuPG says this:
gpg: [don't know]: partial length for invalid packet type 20
> Same thing for for compression algorithms. At some point we were
> talked round to implement bzip2.
How many implementations specify bzip2 as the most desired
compression mode by default? Back in the day, most OpenPGP users were
on the same mailing lists. That is no longer true. This is a good
thing. The OpenPGP standard and GnuPGP in particular are widely and
routinely used.
[...]
> Now, when you move to another software with less capabilities, you
> need to announce that to your peers by sending an updated key with
> the new set of preferences. Sure there is a problem with low end
> mobile device software which you use with the same key - in this
> case you need to drop the preferences which are not supported by
> your mobile device software.
Mailvelope for example, provides no way to modify preferences. Most
implementations do not. So, practically, this will be done with the
GnuPGP editor. That editor is not very accessible for most users. The
user would have to export then import to GnuPGP. Then somehow
determine the capabilities of all their implementations (and all the
versions of those implementations they are using). Then they would find
a common subset and edit it into the new key. Then they would export
the key back to all the implementations, keyservers and non-server
using correspondents. Certainly possible but it is a lot to ask.
These are the sorts of things that allow others to claim that the
OpenPGP ecosystem is complex and unusable.
Anyway, this is not about my greatest fear. That fear is that the
cryto refresh will someday be released as the official RFC-4880. If
any significant implementation follows this exclusively, then there
will be an actual "schism". If everyone emits new modes by default
then the two islands of compatibility will not be able to
interoperate. To the extent that the preferences were helpful, it
would be by using the existing block cipher mode to bridge the gap. I
would be OK with this but I doubt that most would. It would make the
introduction of the new modes seem pointless. What happens then?
Making this personal, I sometimes write PGP advocacy articles. How
should I attempt to sell this new change? Faster encryption and
different error handling, great. But that doesn't seem enough to
justify obscure, possibly time delayed, interoperability problems even
if they are rare.
Bruce
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
