4
$\begingroup$

When implementing and testing my own EdDSA program I found out that the old RFC7748 gives wrong parameters for Ed448/Edwards448.

There is currently a new Draft were this is clarified:

https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ (page 109)

IMPORTANT NOTE: the supposed base point of Ed448 specified in [RFC7748] is incorrect, since it has order 2*n, and - in the notation below - that point is the point (Gx,-Gy)=-(Gx, Gy)+(0,-1). The birational map in that document is also incorrect.

Does this mean RFC8032 (EdDSA) needs to be reworked and all Ed448 implementations updated ASAP or do I still have to use the wrong parameters for EdDSA and wait for an EdDSAv2?

What advise would you give me?

Improve this question
$\endgroup$
2
  • 4
    $\begingroup$ There is also the possibility that most Ed448 implementations are correct and don't follow the incorrect RFC. $\endgroup$
    – CodesInChaos
    Commented Aug 20, 2022 at 17:02
  • 1
    $\begingroup$ A very optimistic point of view since all test vector sources reference RFC8032, which in turn uses the values of RFC7748. $\endgroup$
    – Habor
    Commented Aug 21, 2022 at 19:57

2 Answers 2

Reset to default
2
$\begingroup$

The note talks about the order of the base point of Ed448. There are 2 things that should be clarified at this point:

  1. The so called Ed448 should be edwards448 - it refers to the 448-bit curve (not the Ed448 signature scheme), and this is the terminology used in RFC-7748. It's equivalent to the Ed448-Goldilocks curve described in https://eprint.iacr.org/2015/625.

  2. The coordinate values for Ed448 used in EdDSA (in RFC-8032) are correct.

Now, the troubling part is the order is wrong. But it turns out, this doesn't affect current real-world implementations of these algorithms.

Why? For the 448-bit curves used in both the X448 key exchange and Ed448 digital signature, we're clearing 1 more lower-order bits than necessary - this doesn't decrease the security of them, because Pollard-rho descrete logarithm stays 224-bit difficult, while brutal force is still well beyond that level.

That is, we're doing $\times 4$ for a base point whose order has co-factor $\times 2$. Which is accidentally fine.

As for the incorrect bi-rational map, it won't affect implementations if implementations don't use it.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thank you. That clarifies a lot. I think I will implement a point conversion from/to Goldilocks (original) so I don't have to create another edwards 448 curve class. $\endgroup$
    – Habor
    Commented Aug 27, 2022 at 8:13
1
$\begingroup$

In RFC 7748, there are actually three 448-bit elliptic curves defined:

  1. "curve448", a Montgomery curve
  2. an unnamed twisted Edwards curve
  3. "edwards448", a twisted Edwards curve (different from the unnamed curve)

Outside of RFC 7748, I have seen the unnamed curve called "E448" (this is what it is called in the NIST draft of SP 800-186).

In Rene Struik's draft RFC, he is pointing out a problem with the parameters listed for the unnamed curve. RS calls the curve "Ed448", but, unfortunately, that name collides with a label used in RFC 8032 to denote an EdDSA variant.

RFC 8032 does not make use of the unnamed curve. The issues RS noted do not directly impact the variants of EdDSA described in RFC 8032.

In RFC 7748, the parameters listed for edwards448 (the curve used with EdDSA in RFC 8032) are correct. In particular, the generator (or base-point) provided does have prime order (there is python code in RFC 8032 that verifies this).

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.