search

facebook / opaque-ke

An implementation of the OPAQUE password-authenticated key exchange protocol
Apache License 2.0
291 stars 41 forks source link

Curve25519 test vectors #319

Closed daxpedda closed 1 year ago

daxpedda commented 1 year ago

I was trying the test vectors supplied in https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/404 but very quickly ran into a roadblock.

@kevinlewi would appreciate it if you take a look.

kevinlewi commented 1 year ago

@daxpedda Got the tests working (but am running into issues with pushing and updating this PR). See https://github.com/facebook/opaque-ke/commit/72c473632bcd3b8b85d192bd895aa41daf6f1d85, if you can copy the changes over to this PR here that would be great!

daxpedda commented 1 year ago

Amazing!

So there are two points still open:

kevinlewi commented 1 year ago
daxpedda commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

daxpedda commented 1 year ago

Alright, everything works now! Thank you @kevinlewi for the amazing work in https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/404.

kevinlewi commented 1 year ago

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 commented 1 year ago

Thanks, adjusted.

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

kevinlewi commented 1 year ago

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 https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/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 commented 1 year ago

Alright, this is good to go now!

kevinlewi commented 1 year ago

This is in sync with https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/404/commits/a55d914a5207c6490de54c14cf6be59bf7f8bfd3, but after https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/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.