Mailing List Archive

On Mon, 4 Mar 2024 12:03, Tobias Leupold said:

> So: Is it wise and/or necessary to disable that for new GnuPG generated keys,
> for the sake of interoperability? Or will the others catch up and implement

No, it is not because you are delaying the deployment of new and a much
faster algorithm mode.

Although OpenPGP provides a nice preference system to convey the
capabilities of your software it has the obvious problem that you need
to change the preferences when moving to another software. In fact gpg
has always asked you to update the preferences if it detected a
different set. Using the same key with different software is and will
always be problematic. I would also consider the security drawbacks of
doing so. The attack surface of an Android phone is far higher than of
your well maintained Unix or Windows desktop. Thus it may be useful to
reflect this by using different keys or at least subkeys.

All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js)
took great care to first deploy the software with support for the new
mode before actually creating keys with a preference for that mode [1].
Unfortunately a small group of people seem to sabotage this strategy by
rejecting the new mode despite that it has been implemented by their
crypto library. Well, or your version on Android is too old - which
would indicate a severe security problem anyway.

> it? Or is there a good reason not to do so? Should one keep using legacy RSA
> keys? Is it too early to switch to more modern ones?

RSA has nothing to do with this. You can safely switch to curve25519
(ed25519/cv25519) for new keys - they are supported even longer than OCB
mode (aka AEAD).


Salam-Shalom,

Werner



[1] OCB (AEAD) decryption implemented by GnuPG with versions:
2.3.0-beta (January 2018) - interop tested with RNP and OpenPGP.js
2.3.0 (April 2021)
2.2.21 (July 2021)

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Hi Werner,

thanks for the clarification!

> All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js)
> took great care to first deploy the software with support for the new
> mode before actually creating keys with a preference for that mode [1].
> Unfortunately a small group of people seem to sabotage this strategy by
> rejecting the new mode despite that it has been implemented by their
> crypto library. Well, or your version on Android is too old - which
> would indicate a severe security problem anyway.

This is not about (my) Android (version), I think this is more about
OpenKeychain (still) not having implemented this. For whatever reason.

However, I filed an issue for that:
https://github.com/open-keychain/open-keychain/issues/2900

IMO interoperability with GnuPG is crucial for this project. Most people using
that on their phones will come from Linux, or they will at least be GnuPG
users.

Let's hope for the best ...

> RSA has nothing to do with this. You can safely switch to curve25519
> (ed25519/cv25519) for new keys - they are supported even longer than OCB
> mode (aka AEAD).

Good to know!




_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, Mar 04, 2024 at 12:03:41PM +0100, Tobias Leupold via Gnupg-users wrote:
[...]
> After some research, I found
>
> https://github.com/open-keychain/open-keychain/issues/2886 ,
>
> describing this exact issue.

That would be the cipher block mode proliferation issue.

> As a possible fix, disabling the unsupported AEAD
> mechanism in the key itself was mentioned, the Arch folks write:
>
> https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism

Thank you for this. Up to now I did not know how to do this for GnuPG.

>
> They also claim that "many downstreams attempt to remove this new default by
> patching the GnuPG sources".

I don't know if this is true, but I would not be surprised. It turns
out that the current existing cipher block mode (OCFB-MDC, SEIP) is
cryptographically secure, even though there are lot of misleading
legends that insist that it is not. So as a user, I have no incentive
to use another block mode unless I want higher encryption performance
or different error handling. Few users actually want or need those
features. All users want interoperability. That, after all, is why the
OpenPGP standard exists. People with special needs normally use
dedicated encryption utilities with no interoperability with anything
else.

>
> I'm not that deep into cryptography. I'm not sure I completely grasp what AEAD
> and OCB mean.

Just different terms for the same new and incompatible cipher block
mode for the purposes of this discussion.

>
> So: Is it wise and/or necessary to disable that for new GnuPG generated keys,
> for the sake of interoperability?

Ah... That question leads to an awkward discussion these days. There
was a IETF standards process that led to the OCB mode now supported by
GnuPG and others. GnuPG (and others) implemented it before the new
standard was officially released (there seemed to be consensus). That
standards process then dropped the GnuPG OCB mode and created 3 new
modes. So currently, there are the two modes that the OpenPGP standard
currently specifies and four proposed modes for a total of 6 modes,
each completely incompatible with any other mode. So there is a
potential for a interoperability disaster here.

> Or will the others catch up and implement it?

Which mode(s) should they implement? There are at least two
factions. It seems unlikely that any faction will implement the other
faction's modes.

> Or is there a good reason not to do so?

At this point I personally believe that everyone should step back from
this potential war and stop generating new modes by default. As a user
I can happily wait until an actual consensus is reached. Heck, I can
happily wait past that. There is no hurry here.

The big usability problem now is that the implementations are not
making all this clear. GnuPG for instance doesn't even have an entry
in the FAQ about this problem. Most users will not be able to overcome
this sort of issue and will have to just give up.

Anyway, I wrote a whole rant about this:

* https://articles.59.ca/doku.php?id=pgpfan:schism

I have added your Openkeychain references to my list of problems
caused by new OpenPGP cipher block modes. Thanks.

* https://articles.59.ca/doku.php?id=pgpfan:noae_shame

Bruce

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

> Ah... That question leads to an awkward discussion these days. There
> was a IETF standards process that led to the OCB mode now supported by
> GnuPG and others. GnuPG (and others) implemented it before the new
> standard was officially released (there seemed to be consensus). That
> standards process then dropped the GnuPG OCB mode and created 3 new
> modes. So currently, there are the two modes that the OpenPGP standard
> currently specifies and four proposed modes for a total of 6 modes,
> each completely incompatible with any other mode. So there is a
> potential for a interoperability disaster here.

> At this point I personally believe that everyone should step back from
> this potential war and stop generating new modes by default. As a user
> I can happily wait until an actual consensus is reached. Heck, I can
> happily wait past that. There is no hurry here.

Oh my. So the answer to my question "Should one really disable AEAD for recent
GnuPG created PGP keys" (or OCB/AEAD or whatever) is maybe "yes" after all ...
I mean, it's hard enough for most people to use public key encryption at all.
Even if there are no interoperability issues.

Maybe, one should agree on the lowest common denominator here. I encrypt
passwords, sign software releases and sometimes (rarely), I encrypt an email.
A text email. Which is like 4 KB or such. So, for me, I see no performance
problem for my use-case.

> The big usability problem now is that the implementations are not
> making all this clear. GnuPG for instance doesn't even have an entry
> in the FAQ about this problem. Most users will not be able to overcome
> this sort of issue and will have to just give up.

... like most of them do anyway, when it comes to public key cryptography.

> Anyway, I wrote a whole rant about this:
>
> * https://articles.59.ca/doku.php?id=pgpfan:schism
>
> I have added your Openkeychain references to my list of problems
> caused by new OpenPGP cipher block modes. Thanks.
>
> * https://articles.59.ca/doku.php?id=pgpfan:noae_shame

Thanks for this reference!

Cheers, Tobias



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Hey list,

OpenKeychain maintainer here. As Werner chose to omit some details here
that seem pertinent, I will add:

> No, it is not because you are delaying the deployment of new and a much
> faster algorithm mode.

The packet format referred to here is GnuPG-specific. In November 2023,
GnuPG forked the OpenPGP standard as "LibrePGP", in protest of the
upcoming OpenPGP revision. See https://librepgp.org/

LibrePGP specifies the packet format that GnuPG now emits by default.
However, this packet format will be different from the upcoming RFC
specifying the next OpenPGP revision.

You can find the LibrePGP mailing list here:
https://lists.gnupg.org/pipermail/librepgp-discuss/

> Unfortunately a small group of people seem to sabotage this strategy
> by rejecting the new mode despite that it has been implemented by
> their crypto library.

The "small group of people" that Werner is accusing of sabotage here is
the IETF OpenPGP working group, and implementations that choose to
implement the new OpenPGP RFC over LibrePGP. The background on this
whole ordeal is complicated to say the least, but it is well established
that the points of contention are rooted in personal conflict, and thus
by nature extremely difficult to work with.

> All the major implementers (Ribose RNP, GnuPG, BouncyCastle, OpenPGP.js)
> took great care to first deploy the software with support for the new
> mode before actually creating keys with a preference for that mode [1].
Ultimately, as a user you can currently choose between a format that
will not be part of the upcoming RFC, but is supported by GnuPG (and
many other implementations, including those mentioned above). Or a
format that will be standardized as an RFC, but is not supported by
GnuPG (but many other implementations, including all mentioned above).

Due to this situation, many distributors (at least: Thunderbird, Debian,
Arch, Fedora, NixOS, GPG Suite for macOS) have decided to hold back
emission of the LibrePGP packet format for now. OpenKeychain will also
follow suit here.

Cheers

- V

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Hey Bruce,

On 04.03.24 21:53, Bruce Walzer wrote:
> * https://articles.59.ca/doku.php?id=pgpfan:noae_shame

There is more if you search for it:

https://kagi.com/search?q=gpg+%22packet+type+20%22&r=no_region&sh=HeSUA3hoI5SeCuA2TTrNig

Cheers

- V

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi Vincent!

Thanks a lot for this insight!

When it comes to encryption, I would consider myself a "power user", but
still a user. I never heard of all this until now. What I, from the
perspective of an end-user, saw was: I generate a new key. And then:
"Pass no work on me phone anymore, OpenKeychain bad!" ;-)

This whole thing is awkward. As a normal user, you currently have no
chance to even know this.

So, is what they propose in the Arch wiki the way to go to stick to
non-embattled interoperable settings? (setpref AES256 AES192 AES SHA512
SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP)?

I see the rationale for a performant block cipher. But that's nothing I
need for my use-case; there's simply no advantage at all. Most probably
for most users. So if there's no broad consensus about this, such an
option should be hidden behind some "expert" flag, for people knowing
what they do, and who are willing to trade off interoperability for
performance. It should not be a default setting letting users like me
run into problems they can't grasp without deep research.

I don't want to join a "faction". I don't want to participate in a
religious war. I just want to use encryption ...

I'll file a Gentoo bug about this and see what the devs/maintainers say.

Cheers, Tobias

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, 5 Mar 2024 00:16, Vincent Breitmoser said:

> The packet format referred to here is GnuPG-specific. In November

Vincent, please stop spreading wrong facts.

That is not a GnuPG specific but an agreed upon format by the
participants of the OpenPGP WG and implemented by all major
implementations. This was done in the same way we handle that since
1997 - the implementers agreed upon some format, implemented it and
later described it some draft document. For example the current AEAD
mode (CFB+MDC) was agreed upon in the year 2000 and implemented by both
existing implementations (PGP and GnuPG). If took then 8 years before
it was codified in an RFC. Same thing for modern ECC curves -
implemented by everyone but no detailed specs out there. Modern AEAD
mode (OCB) was specified and cross-tested in 2018 but some people,
driving their own agenda, dropped that in fall 2021 and came up with
another format with no solid reason.

Bruce: I understand your claims and we have been very careful not to
break anything when implementing a modern mode. That mode is really
required because the old CFB+MDC is slow and policy makers don';t like
it because it is not on their list of modern algorithms. The problem
here is that group of newcomers with their niche implementations who
want to gain an advantage compared to the existing implementations.
Unfortunately supported by a few people like Vincent who patch out things
or don't use their existing stuff. OTOH, it is not a real problem
because they are, well, niche implementations, albeit with a loud voice.

> 2023, GnuPG forked the OpenPGP standard as "LibrePGP", in protest of

Right, Ribose and GnuPG came up with that site to explain what was
going wrong and to have a descriptive name for the actual OpenPGP
standard in current use.

All has been said and there is no need to continue spreading wrong facts
from your rebellion group aiming to discredit the most widely used
standard for mail and data encryption. Please go to your own list and
continue there. Here is no place to repeat that. My last word on this
on this ML.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On Mon, 4 Mar 2024 19:05, Tobias Leupold said:

> IMO interoperability with GnuPG is crucial for this project. Most
> people using that on their phones will come from Linux, or they will

Actually most users will come from Windows ;-)


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Sorry for asking another thing about this. For sure, I didn't want to set off
an avalanche, and I still don't want to. But from a user's perspective, this
is simply very confusing and also unsettling.

I think that somewhere, there should be some documentation, FAQ or whatever,
as a definitive source for the correct facts.

Because we have this statement:

> That is not a GnuPG specific but an agreed upon format by the participants
> of the OpenPGP WG and implemented by all major implementations.

Which does not match what others say (apart from Vincent's statement) ... e.g.
I also asked for what to do on Stack Exchange:

https://security.stackexchange.com/questions/275883/should-one-really-disable-aead-for-recent-gnupg-created-pgp-keys

The answer started with:

> While authenticated encryption (AEAD) is good - especially for something
> like OpenPGP, which is an old and over-complicated standard that has a
> concerning large attack surface for vulnerabilities or simple implementation
> errors - I definitely can't recommend enabling a non-standardized
> compatibility-breaking feature by default, and frankly feel that GnuPG made
> a major error in doing so

from somebody with an impressive reputation on the network, for whom I suppose
he knows what he's talking about.

So: Is this standardized, or is it not?

As said: I don't want to provoke a flame war. I'm just interested in objective
facts ...



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi!

On Tue, 5 Mar 2024 12:39, Tobias Leupold said:
> Sorry for asking another thing about this. For sure, I didn't want to set off
> an avalanche, and I still don't want to. But from a user's perspective, this
> is simply very confusing and also unsettling.

You are right. What I can do is to give my perspective of this which is
based on my experience re-implementing a free PGP version since 1997 and
while doing that taking part in the OpenPGP specification process which
started at the same time.

> https://security.stackexchange.com/questions/275883/should-one-really-disable-aead-for-recent-gnupg-created-pgp-keys
>
> The answer started with:
>
>> While authenticated encryption (AEAD) is good - especially for something
>> like OpenPGP, which is an old and over-complicated standard that has a
>> concerning large attack surface for vulnerabilities or simple implementation

This introduction is pretty unfair but unfortunately as common on the
net as the "PGP is way too complicate for anyone to use" claim. In
reality PGP (in the form of GnuPG and Thunderbird) is used daily by
million of people who consciously choose to protect their mails and
data. If you want to see an over-complicated standard, have a look at
S/MIME (aka CMS, X.509) which is implemented by all major mailers but
has not the good repudiation of *PGP. See also [1].

The above answer by CBHacking continues:

I definitely can't recommend enabling a non-standardized
compatibility-breaking feature by default, and frankly feel that
GnuPG made a major error in doing so.

That is factual wrong. RNP, the core of Thunderbird's OpenPGP
implementation, implemented this too. But instead of fixing all the
stuff which got lost during the migration from Enigmail to TB's new
OpenPGP code the TB maintainer now wants to remove support for OCB from
TB. IETF specifications are not a standard but a specification how
certain things are commonly implemented. The meanwhile most used public
key algorithm (Curve25519) is not specified in OpenPGP but nevertheless
less widely used and accepted.

From a security perspective, I'm not even sure that just adding an
OCB-based AEAD mode actually helps anything, in expectation; OpenPGP
messages can already be authenticated in a few different ways, so
arguably the likeliest source of security flaws is that the message

S/he is right that formats get more complex and that we already have
Authenticated Encryption (the core feature of AEAD) in OpenPGP but
exactly that old format is complex and hard to implement. OTOH, the new
OCB based Authenticated Encryption is a straightforward implementation
of a well reseached mode and the gold standard for all block cipher
modes. The old format in OpenPG was an ad-hoc implementation of
Authenticated Encryption on top of the legacy PGP-2 format. Thus in the
long run the new OCB mode will reduce the complexity.

The answer shows in bold:

Given that you work with non-GnuPG clients, and that this feature is
not part of the OpenPGP specification, and that OpenPGP already
includes message authentication and integrity, I recommend disabling
this feature for now.

With the same argument you could also stop using TLS 1.3 and instead
keep on using TLS 1.2 in eternity. In most cases 1.3 has no real world
advantages when done right. However, most sites allow for both 1.3 and
1.2 and only a few disallow 1.2 which leads to the same problems as we
see with the removal of support by some application and some Linux
distros.

Note that you'll have to re-encrypt the data for non-GPG clients after
disabling this non-standard feature.

Also most other things CBHacking wrote are okay, this one is simply
wrong. This is not a gpg only feature.

> from somebody with an impressive reputation on the network, for whom I
> suppose

Well, some anonmyous account on stackexchange. I can't tell.


Salam-Shalom,

Werner


[1] Let me quote Peter Gutman, a really well repudiated expert on all things
security, on S/MIME:
"As a result there's no pressure on the people involved in PKI
standardisation to create anything that meets any real-world
requirement, allowing them instead to spend their time building great
gothic cathedrals of infinite complexity whose sole purpose seems to
be to strike awe and terror into the masses."
I hope that *PGP stops evolving into this direction.

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

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

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

Sorry, this is not true. OCB mode is only used if all recipient's key
have the flag that they support this mode. 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. Same thing for for compression algorithms. At some
point we were talked round to implement bzip2. The WG agreed on a code
point for this and GnuPG implemented it. It is really rare that you
get messages which you can't decrypt due to the non-supported
compression algo. The preference system does it works.

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.

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

If your key claims that it supports this feature it is decryptable - or
you forgot to distribute the fact that you moved to a less capable
software.

Right, for symmetric only encryption the preferences don't work. But in
this case you need to negotiate parameters and passwords anyway.

> 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

Sure they can do that. However, I don't think that this is a good
decision. With the same argument we would still be using CAST5 or
Twofish or even Blowfish.

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

Agreed. Let the preferences work for you. And also nag Vincent et al
to stop crippling their software (rejecting OCB). After all
BouncyCastle supports ed25519 which is also not specified by an RFC or
anything else except the way gpg implemented the details of that curve.
Such public key algorithms can't even be managed by the preference
system.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

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