Interoperability with OpenPGP crypto-refresh

[Bruce Walzer]

On Thu, Feb 02, 2023 at 06:12:57AM +0100, Christoph Anton Mitterer wrote:
> On Wed, 2023-02-01 at 22:19 -0600, Bruce Walzer wrote:
> > On Wed, Feb 01, 2023 at 07:42:38PM +0100, Kai Engert via Gnupg-devel
> > wrote:
> > [...]
> > > Does that mean, if Thunderbird wants to remain compatible with all
> > > major
> > > implementations, then Thunderbird must stay at the functional level
> > > of RFC
> > > 4880, and must not use any functionality from newer specifications,
> > > neither
> > > from the upcoming IETF crypto-refresh, nor items that were added in
> > > RFC
> > > 4880bis on top of RFC 4880?
> > 
> > That sounds like a reasonable approach to me.
> 
> Sounds rather like the worst approach to me. Staying at the level that
> is in principle already insufficient in several places.
> 
> 
> > Sometimes consensus can not be reached. Then changes are not really
> > possible or practical. What exactly would the downside for
> > Thunderbird be here?
> 
> Not getting any new algorithms?

But why would this be a issue that needs to be addressed now? What
advantages would the new algorithms provide to the users of
Thunderbird? Would those advantages make up for the incompatibility
problems caused by the introduction of new incompatible algorithms?

For long term standards, procrastination is almost always a virtue...

> 
> The WG seems to have done quite a good job, and crypto-refresh provides
> many things that are wanted.
> It has AEAD algos,

OCB has the advantage that it is faster and thus better for huge
files. The other proposed modes don't seem to have any particular
advantage. Thunderbird is a messaging application where the messages
are limited to lengths of 10s of MB. So performance is not an
issue. So it would make the most sense to stick to the existing
standardized authenticated encyption mode as specified in RFC4880 to
provide the best level of compatibility for the users. So the AEAD
modes are not really useful here.

> it has Ed25519 and Ed448,...

The advantage of curves over RSA for the users of Thundebird is the
shorter key length. The length of Ed448 is significantly longer than
Ed25519. So why standarize both? The super long keys of post quantum
cryptography would make this all insignificant so it would make sense
to wait a while and see how the quantum stuff pans out.

SHA1 seems to be mostly
> gone (in the place where it was mandatory).

How does making SHA1 gone provide any value to the users of
Thunderbird? The only attack I am aware of that relates is
Sha-mbles. It is wildly impractical the the point that most users
would not care. It can be resolved simply by upgrading existing keys
in a way that does not cause the user to lose their PGP identity. No
changes to the existing standard are required.

> 
> Is there any *real* problem about it containing GCM?! Its chapter 9.6.
> makes OCB mandatory - EAX and GCM are optional.
> If one doesn't like to implement GCM because of it's fragility - don't
> implement it.

Unless someone sends one of the users a message encrypted with EAX or
GCM. Then you have to implement it. This might happen where a user
uses an implementation that supports EAX/GCM to generate a key with
EAX/GCM in the preferences but then uses a different implementation that
does not support EAX/GCM. This is normal PGP usage as identities refer
to people, not devices. Having EAX/GCM be optional actually makes
things worse.

I have personally encountered this problem in the wild, and no new
modes have even been standardized yet.

[...]

> It also still comes only with S2K as KDF, despite there being
> considerably better alternatives (I mean Argon2 would be the natural
> candidate, but probably all finalists from the PHC would be a much
> better choice than S2K).

Argon2 seems a fairly poor choice here. It is fairly memory hungry
which could cause the users to encounter interoperability problems. An
Argon2 implementation will just blow up with an out of memory
error. There is a fairly common argument out there that Argon2 is not
optimal for situations where the time required to derive the key is
limited to less than a secone. GPG uses 0.1 seconds as a target for
example. Something cache hard might be a better choice.

Currently single core processor performance seems to be at a plateau,
so this is, again, not a crisis for any Thunderbird user.


Bruce