RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Held for Document Update (1)

RFC 8031, "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement", December 2016

Source of RFC: ipsecme (sec)

Errata ID: 6931
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Christian Tschudin
Date Reported: 2020-11-17
Held for Document Update by: Paul Wouters
Date Held: 2023-07-28

Section Global says:


Notes:

A discrepancy came to my attention when testing the Yubikey 5 hardware and comparing it with the NaCl library and RFC8031. While the NaCl library works as expected, it is disturbing to see that the Yubikey can only be made to produce the desired (above and corrected) shared secret if you let it compute X25519(fixed_i,pub_r). That is, the secret must be presented to the Yubikey in big-endian format which could be "inspired" by the (not very detailed) Smartcard spec 3.4.1 that refers to ANSI X9.62 where curve parameters, prefixed with 0x04, are encoded in big-endian order - clearly the ANSI encoding is not useful here as we only need one parameter u. I wonder whether RFC8031 should spell out that input parameters (d_X and pub_X) SHOULD be presented in encoded form (and thus little-endian), hence putting manufacturers in charge of documenting any deviation.

Status: Rejected (1)

RFC 8031, "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement", December 2016

Source of RFC: ipsecme (sec)

Errata ID: 6339
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Christian Tschudin
Date Reported: 2020-11-17
Rejected by: Paul Wouters
Date Rejected: 2023-07-28

Section Appendix A says:

The public keys are generated from this using the formula in
Section 2:

pub_i = X25519(d_i, G) =
             48 d5 dd d4 06 12 57 ba 16 6f a3 f9 bb db 74 f1
             a4 e8 1c 08 93 84 fa 77 f7 90 70 9f 0d fb c7 66

pub_r = X25519(d_r, G) =
             0b e7 c1 f5 aa d8 7d 7e 44 86 62 67 32 98 a4 43
             47 8b 85 97 45 17 9e af 56 4c 79 c0 ef 6e ee 25

And this is the value of the Key Exchange Data field in the Key
Exchange payload described in Section 3.1.  The shared value is
calculated as in Section 2:

SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) =
             c7 49 50 60 7a 12 32 7f-32 04 d9 4b 68 25 bf b0
             68 b7 f8 31 9a 9e 37 08-ed 3d 43 ce 81 30 c9 50

It should say:

The public keys are generated from this using the formula in
Section 2:

pub_i = X25519(d_i, G) =
             a7 07 b3 bc 0f 37 56 fc 0a cf 33 55 85 c5 f7 7b
             9f 29 ff a4 24 70 14 af 84 70 5b eb 50 46 26 29

pub_r = X25519(d_r, G) =
             0e 57 7e 11 5d 6c 08 59 b8 51 36 d2 1b 1c fd 74
             67 9f 91 14 61 1d 79 c6 81 ba d0 8a 7e 1f 0a 04

And this is the value of the Key Exchange Data field in the Key
Exchange payload described in Section 3.1.  The shared value is
calculated as in Section 2:

SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) =
             d6 8d 8c ea fd 2c d3 ce 25 34 43 33 c8 9e 35 54
             9e 0f c6 1a 98 87 39 34 b1 8a 18 70 f0 3a 17 0c

Notes:

The test vector values given both for the public keys and for the shared secret are wrong. It turns out that they were derived from the unchanged random input, instead of d_X. An explanation could be that a first text version did not include the fixing of the random bits and that after inserting the respective paragraph (introducing fixed_X and d_X), it was forgotten to update pub_X and SHARED_SECRET.

Paul Wouters: endian issue mentioned in notes split into separate errata
--VERIFIER NOTES--
Paul Wouters (AD): As per Tobias Brunner:

The original test vector works for us (verified with multiple X25519
implementations). I think most of the confusion comes from the
different formatting of the values when compared to the test vectors in
RFC 7749 (in particular d_i/r).

In the latter, the values are given as long hex strings. It states:

"The inputs are generally given as 64 or 112 hexadecimal digits that
need to be decoded as 32 or 56 binary bytes before processing."

So these values are byte strings, i.e. each two hex digits simply
represent a byte. For the random_i/r, pub_i/r and SHARED_SECRET values
in RFC 8031 this has been made a bit clearer by separating the
individual bytes.

But then there are the d_i and d_r values. These are given as long hex
strings, however, unlike those in RFC 7749, they are not byte strings
but actually the numbers in base 16 after decoding the binary values
fixed_i/r as little-endian. Note that RFC 7749 also gives the decoded
numeric values of some of the inputs, but does so in base 10 thus
avoiding this confusion.

So in RFC 8031 it would have been clearer if these values were either
prefixed with 0x:

d_i = 0x549D5F4A460900E6D9F63F53586AD1DD8CEAF925739B78B676B4558630B41F70
d_r = 0x4856A039B8F178E9A1550722DCEF01559ECDBA30E0D0ADDD600D295352645408

or also given in base 10:

d_i = 38272331938479145686941743521879072306
324697418955568337792079861743202082672
d_r = 32719579781175365148694953981896303820
370069993938279311538545124444601603080

Report New Errata



Advanced Search