Subject: Re: [Openpgp-dt] Curve448 and Brainpool

From: Daniel Huigens <[email-masked]>
Date: Mon, 20 Sep 2021 17:23:25 +0000

> I can't agree to that.  I once took care in 6637 that arbitrary curves
> could be used and not just a small set of publicly known curves.  The
> reason for that were the Brainpool curves which are required in Europe
> for restricted communication _and_ for qualified electronic signatures.

Do you have a citation for this? [1] doesn't mention any specific curves;
[2] mentions both Brainpool and the NIST curves. It doesn't mention
Curve25519 or Curve448, but the document is quite old; if they're fine
with the NIST curves I don't see why they wouldn't be fine with those.

> There are a lot of more curves on the table including those with
> classified parameters.  Any standard which has no provisions to allow
> there use will be doomed.

I'm not necessarily saying that the standard should have no possible way
of defining curves other than the NIST curves, Curve25519 and Curve448.
My main argument is that we probably won't need to, as I think Curve448
will remain sufficiently secure forever (barring post-quantum crypto).
That being said, of course if I end up being wrong then we should have
the ability to define additional curves. I just don't think we should
assume that we will, nor base our design of Curve448 around that
assumption.

I originally brought this up as an argument in favor of consistency
between Curve448 and Curve25519, rather than between Curve448 and
hypothetical future curves. (Though it seems others don't care much
about the former so I'm happy to drop this argument.) Brainpool should
anyway be consistent with the NIST curves, not Curve25519 or Curve448,
so even if we do end up specifying those it's a bit moot wrt Curve448.

> FWIW, I am in favor of keeping ed25519/curve25519 in OpenPGP as they
> are, that is not renaming them (because X25519 is different) and to have
> a more straightforward way to encode newer curves.

I agree that they should continue to work as they are, but re. renaming;
Curve25519 in OpenPGP is indeed different from X25519 (namely the
private key is reversed), but I personally think it would be clearer to
write in the spec that it is "X25519, but with the private key reversed",
now that X25519 is specified in RFC7748 (also since the crypto-refresh
document refers to that), rather than try to claim that we're doing a
custom "ECDH over Curve25519" thing (which is specified nowhere).
"X25519, but with the private key reversed" is after all how most new
implementations will implement it (as their underlying crypto libraries
will most likely give them X25519), so I think it would save some
confusion about how to implement it if we state this outright.

That being said, this would be a purely editorial change, so if people
think it would be clearer to keep it as Curve25519, to not imply that
it's identical to X25519 as it's normally used, I'm also fine with that.

> SOS is a way for a more clear definition for ECC stuff and can be used to
> replace the problematic MPI encoding which we kept in OpenPGP only for
> PGP2 backward compatibility.  I am also fine with any other method,
> including a prefix octet, for newer curves (e.g. 448) as long as parsing
> a keyblock or message is possible without knowing the curve.

I agree with this part. Personally I would be in favor of keeping the
prefix octet of Curve25519 (0x40) for Curve448, and/or using it for the
other artefacts/MPIs as well, but I'm also fine with the other options.

Best,
Daniel

[1]: https://data.europa.eu/eli/reg/2014/910
[2]: https://ec.europa.eu/cefdigital/wiki/download/attachments/82773108/eidas_-_crypto_requirements_for_the_eidas_interoperability_framework_v1.0.pdf
     (note: PDF downloads automatically)