Curve25519 test vectors

[daxpedda]

I was trying the test vectors supplied in cfrg/draft-irtf-cfrg-opaque#404 but very quickly ran into a roadblock.

@kevinlewi would appreciate it if you take a look.

[kevinlewi]

@daxpedda Got the tests working (but am running into issues with pushing and updating this PR). See 72c4736, if you can copy the changes over to this PR here that would be great!

[daxpedda]

Amazing!

So there are two points still open:

• Pre-clamping the private keys in the official test vectors. We could then change deserializing private keys to fail if they are not valid.
• Figure out if a random oracle is required, which is what we had in place before. See Add x25519 AKE test vectors cfrg/draft-irtf-cfrg-opaque#404 (comment).

[kevinlewi]

• The pre-clamping in the official test vectors should already be incorporated (see the latest commit in Add x25519 AKE test vectors cfrg/draft-irtf-cfrg-opaque#404).
• I don't think a random oracle is required. See the "Computing secret keys" section of https://cr.yp.to/ecdh.html, which I believe is an authoritative source for this kind of stuff.

[daxpedda]

• The pre-clamping in the official test vectors should already be incorporated (see the latest commit in Add x25519 AKE test vectors cfrg/draft-irtf-cfrg-opaque#404).

I just tested it, doesn't seem to be the case. I want to point out that the latest commit did something with the code but didn't actually update the test vectors, the updated test vectors in the commit are the same as in the commits before, they were just not updated in some of the files. Maybe some oversight happened there.

Just to make sure, maybe there is a misunderstanding here, what I mean is that the private keys in the test vectors should already be clamped, instead of having to clamp them during deserialization.

• I don't think a random oracle is required. See the "Computing secret keys" section of https://cr.yp.to/ecdh.html, which I believe is an authoritative source for this kind of stuff.

I see.

Out of curiosity, looking at the NIST curves, I couldn't find anything requiring such a random oracle as is currently used in OPAQUE: NIST FIPS 186-5.

Probably better to ask this in the IETF OPAQUE repo, but I couldn't really find an explanation why we need such a "heavy-handed" random oracle for P-256/P-384/P-521.

[kevinlewi]

I just tested it, doesn't seem to be the case. I want to point out that the latest commit did something with the code but didn't actually update the test vectors, the updated test vectors in the commit are the same as in the commits before, they were just not updated in some of the files. Maybe some oversight happened there.

Just to make sure, maybe there is a misunderstanding here, what I mean is that the private keys in the test vectors should already be clamped, instead of having to clamp them during deserialization.

Ah, oops! I found an issue with the official test vectors which I thought were clamping properly... but looks like there is still a bug. Sorry, will get that sorted out! But yes, we are on the same page with what needs to happen :)

[daxpedda]

Updated the test vectors.
Apparently randomized_pwd is missing on some, but otherwise looks good!

[daxpedda]

Alright, everything works now!
Thank you @kevinlewi for the amazing work in cfrg/draft-irtf-cfrg-opaque#404.

[kevinlewi]

FYI, I think the test vectors had some variable names changed, in case this causes errors:
server_keyshare -> server_public_keyshare
client_keyshare -> client_public_keyshare
randomized_pwd -> randomized_password

[daxpedda]

Thanks, adjusted.

client_keyshare was completely removed from the test vectors in the latest commit of cfrg/draft-irtf-cfrg-opaque#404, it was not replaced with client_public_keyshare, I assume this was by accident?

[kevinlewi]

client_keyshare was completely removed from the test vectors in the latest commit of cfrg/draft-irtf-cfrg-opaque#404, it was not replaced with client_public_keyshare, I assume this was by accident?

Ah, seems like client_keyshare / client_public_keyshare was mistakenly removed in cfrg/draft-irtf-cfrg-opaque#407 (which I incorporated after merging with the main branch). I will push another commit to add it back in, thanks for the catch!

[daxpedda]

Alright, this is good to go now!

[kevinlewi]

This is in sync with cfrg/draft-irtf-cfrg-opaque@a55d914, but after cfrg/draft-irtf-cfrg-opaque#411 there were a couple of more minor-ish edits to the test vectors which need to be incorporated. We can do so in a follow-up PR, as I'd like to merge this one first.