Add x25519 AKE test vectors #404
Conversation
|
lgtm. thank you for this effort! |
|
That's pretty amazing @chris-wood! 🎉 Gonna report back as soon as I figure out why I couldn't make them work in |
|
just to be clear, this effort is about |
draft-irtf-cfrg-opaque.md
Outdated
| - DeriveAuthKeyPair(seed): This function is implemented by returning the private | ||
| key `k` based on seed (of length `Nseed = 32` bytes), as described in {{Section 5 of Curve25519}}, | ||
| as well as the result of ScalarMult(k, B), where B is the base point of Curve25519. |
There was a problem hiding this comment.
Why does this differ from the other groups?
Because OPRF doesn't specify a ciphersuite for Curve25519?
There was a problem hiding this comment.
After consulting the spec again, I couldn't really find an answer to this. Doesn't removing the G.HashToScalar have any security implications at all?
And if not, why is it in place for the other ciphersuites?
There was a problem hiding this comment.
I'm not sure I understand the question. But to try and reiterate, there was no existing function in the OPRF document we could point to, which is why we just lean on standard key generation for curve25519 -- treat random bytes as the key (scalar).
There was a problem hiding this comment.
Ah, sorry, I can see how my question is confusing. So in opaque-ke we were using OPRF with a custom ciphersuite when chossing Curve25519, which was possible because the hash2curve specification does provide a ciphersuite for Curve25519.
So my question is: the other ciphersuites do use OPRF to derive a key pair in DeriveAuthKeyPair. So why do other ciphersuites need that but Curve25519 doesn't? I thought it was necessary for security reasons (that I have no clue about).
There was a problem hiding this comment.
Oh, I see! You're asking if it's necessary to map the input seed to a scalar using something like a random oracle? I don't think it's necessary, but I actually don't know the answer off the top of my head. I think this should probably be asked on the list (I can do that).
|
0253cbb updated the |
@armfazh it's about option (a) =) |
@daxpedda I added clamping and updated the vectors in the latest commit. @kevinlewi, @daxpedda: I'm going to promote this draft to a real PR now. I think it's ready to go. |
|
@bytemare can you please take another look? |
poc/opaque_core.sage
Outdated
| def create_cleartext_credentials(self, server_public_key, client_public_key, server_identity, client_identity): | ||
| def derive_auth_key_pair(self, seed): | ||
| if self.config.group.name == "x25519": | ||
| return seed, self.config.group.scalar_mult(seed, self.config.group.generator()) |
There was a problem hiding this comment.
@chris-wood Additionally, I believe we need to make sure that seed is clamped here, before using it. Otherwise, the private key that we generate will not be clamped (since it just equal to the seed).
poc/vectors/formatted.txt
Outdated
| KSF: Identity | ||
| KDF: HKDF-SHA512 | ||
| MAC: HMAC-SHA512 | ||
| Group: x25519 |
There was a problem hiding this comment.
This should say Group: curve25519
|
Spec changes:
Sage POC code changes:
|
More cleanup to go with x25519 vectors
This did introduce some editorial changes to accommodate the x25519 AKE, but I don't think they're unreasonable. The actual reference implementation needs to be cleaned up somewhat, but I think we can at least use this to test for interop for the time being. I'll work on cleaning up the code in a bit, so, starting as a draft now.
Closes #238
cc @daxpedda