-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kem: Scheme.DeriveKeyPair length check too strict #486
Comments
Actually, a |
RFC 9180 section 7.1.3 says: > For a given KEM, the ikm parameter given to DeriveKeyPair() > SHOULD have length at least Nsk, and SHOULD have at least Nsk > bytes of entropy. Thus, it is not a requirement for HPKE to pass a seed with a fixed size. Protocols such as MLS rely on this. Closes: cloudflare#486
In Section 7.4, MLS, DeriveKeyPair is called with
Looking at the definition of
There is a mismatch between
@emersion , I recommend you to reach the MLS authors to seek guidance, this could be a typo in the spec. |
Good idea. I've sent an email to the mailing list: https://mailarchive.ietf.org/arch/msg/mls/JdrJvjGnVjNHX1xE4kTcsmq_PRc/ |
The |
Also the
requirement is problematic for PQ KEMs, which have large secret keys, and is ignored. This requirement is very much written thinking only of elliptic curves. |
That makes sense to me. Do we want a full new interface in the |
Scheme.DeriveKeyPair
panics if the length of the seed is different fromScheme.SeedSize
. However, this is too strict: there are use-cases for passing a seed larger than the hash size, for instance MLS passes a 64-byte value toKEM_X448_HKDF_SHA512
(which hasSeedSize
of 56).RFC 9180 section 7.1.3 says:
Would you accept a patch which changes the
len(seed) == x.SeedSize()
check tolen(seed) >= x.SeedSize()
?The text was updated successfully, but these errors were encountered: