Re: [openpgp] First remarks on the last I-D (Was: I-D Action: draft-ietf-openpgp-crypto-refresh-06.txt)

[Daniel Huigens <[e-mail]>]

Hi Werner,

> 1. The new AEAD scheme.
>
>    It seems that this new scheme was introduced for the benefit of
>    allowing GCM as yet another encryption mode.  GCM is a counter mode
>    and as can be seen by the large changes required, hard to get right.
>    We do have GCM now in CMS now because Microsoft decided to go this
>    way.  However, OpenPGP has taken its own decisions based on technical
>    soundness and not based on larger vendor, government or committee
>    decision.

FWIW, while it's true that GCM was the main reason, I personally think
that binding the key to a specific mode is nice regardless. It protects
against crossgrade attacks, in the sense that breaking one algorithm
doesn't break the others.

That being said, I do agree that having only OCB, for example, would
make things simpler. But, with OpenPGP.js maintainer hat on, having GCM
is nice since it's in Web Crypto, meaning it's natively implemented in
browsers. (That being said, we should add OCB there as well, but that
might be a long process.)

>    The WG once decided to go with EAX and OCB.  EAX was only added to
>    avoid possible patent problems.  However, in the 4.5 years since the
>    introduction of EAX the patent things has expired was invalidated and
>    before the new mode will will be a MUST algorithm in a future OpenPGP
>    RFC (not in 4880bis), there will definitely be no more problem at all
>    with OCB.  I bet that by then an updated FIPS-140 will even allow
>    OCB.

At IETF 112, Quynh Dang said that "NIST has no plans to approve OCB" [1],
unfortunately. I'm not sure whether that has changed in the meantime or
what the reasoning was, but that's what we went by. (Personally I don't
actually care about FIPS compliance that much but I know some people do.)

>    Thus my suggestion: Drop all that new AEAD ideas and use what has
>    been deployed and agreed upon in this very WG a long time ago.
>    Further, turn OCB into MUST and EAX into MAY (for backward
>    compatibility to deployed implementations).

This last part has been done, actually, see [2] :)

> 2. The removal of the Brainpool curved, as already explicitly listed in
>    early RFC-4880bis drafts, is not acceptable.  It may even raise
>    suspicions that a TLA was somehow involved to keep NIST curves but
>    not Brainpool.  Note I won't share such an opinion, but with crypto
>    algos we also need to look at such political things.
>
>    Thus please immediately issue -07 with Brainpool re-added.

Again purely with implementer hat on, I have some issues with Brainpool.
The NIST curves are natively implemented in Web Crypto, and we have an
asm.js implementation of Curve25519 which is fast and algorithmically
constant-time. By contrast, for Brainpool we use a pure javascript
implementation of those curves, which is slow and not constant-time.
Of course, those things could be fixed as well, but now that we have
the CFRG curves, I don't really see the need, tbh.

Best,
Daniel


[1]: https://datatracker.ietf.org/doc/minutes-112-openpgp/#autoid-6
[2]: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-06#page-101