Private Key Format

[seanturner]

See mail thread.

[bwesterb]

For posterity: see #22 for past discussion.

[csosto-pk]

From djb

This text appears in draft-ietf-lamps-kyber-certificates-08:
Many protocols only rely on the IND-CCA security of a KEM. Some
(implicitly) require further binding properties, formalized in
[CDM23]. The private key format influences these binding properties.
Per [KEMMY24], ML-KEM is LEAK-BIND-K-PK-secure and LEAK-BIND-K-CT-
secure when using the expanded private key format, but not MAL-BIND-
K-CT nor MAL-BIND-K-PK. Using the 64-byte seed format provides a
step up in binding security, additionally providing MAL-BIND-K-CT
security, but still not MAL-BIND-K-PK. For more guidance, see
[I-D.sfluhrer-cfrg-ml-kem-security-considerations].
This says why the seed is preferred.

Does it? Seems to me that various recent messages are challenging this
as using the word "secure" in a way that hasn't been justified through
any actual attack scenarios---it's even contrary to well-established
practice regarding side channels. It's also puzzling to see the BIND
properties claimed to be important when the selected format isn't a
format that achieves all of those properties (e.g., 32-byte seeds).

From Viktor D.

FWIW, in the message that started this thread, I included a link to a tentative revision of the draft, in which that text was removed.
https://vdukhovni.github.io/ml-kem-certificates/#section-7
I don't believe the original text is justified or necessary in a PKCS#8 format specification. If there are protocols in which those concerns are relevant, the text would belong in the specifications of those protocols.

There is merit to these points. Should we refine or remove the claims about the security properties of SEED? I think Mike O. had suggested this text. What were the mains reasons for a seed other than those? Size and simplicity?

[bwesterb]

The main reason (for me) is that seed is simpler. With expanded private key you need to align on which checks to perform, and that seems to have already diverged between implementations. Size is another nice benefit.

We should continue to mention LEAK-BIND-x security, as that has been an actual security concern (eg. Signal). My current understanding is that there is no real-world attack exploiting missing MAL-BIND-x security. I don't want to jump the gun here and say it's definitely not important though. But we can tweak the language to make MAL-BIND-x seem less threatening.

[vdukhovni]

The main reason (for me) is that seed is simpler. With expanded private key you need to align on which checks to perform, and that seems to have already diverged between implementations. Size is another nice benefit.

We should continue to mention LEAK-BIND-x security, as that has been an actual security concern (eg. Signal). My current understanding is that there is no real-world attack exploiting missing MAL-BIND-x security. I don't want to jump the gun here and say it's definitely not important though. But we can tweak the language to make MAL-BIND-x seem less threatening.

I still believe that the least misleadingly threatening mention of the MAL-BIND-x issues is to not mention them at all. At least for ML-KEM, to the extent they need to be mentioned, they're well covered in the already referenced CFRG draft