Can anyone speak to the history of the examples here (or the content of the report itself)?
Thanks, Ben On Tue, Nov 17, 2020 at 10:46:21AM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC8031, > "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 > (IKEv2) Key Agreement". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6339 > > -------------------------------------- > Type: Technical > Reported by: Christian Tschudin <christian.tschu...@unibas.ch> > > Section: Appendix A > > Original Text > ------------- > 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 > > > Corrected Text > -------------- > 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. > > This 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. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8031 (draft-ietf-ipsecme-safecurves-05) > -------------------------------------- > Title : Curve25519 and Curve448 for the Internet Key Exchange > Protocol Version 2 (IKEv2) Key Agreement > Publication Date : December 2016 > Author(s) : Y. Nir, S. Josefsson > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
