Update draft-sfluhrer-cfrg-ml-kem-security-considerations.md

[kmilner]

This is a very quick description that I think might be worth fleshing out more, but I think it's worth mentioning.

Associate references:

• https://www.iacr.org/archive/pkc2019/114420193/114420193.pdf is I believe the original proposal of the attack.
• https://eprint.iacr.org/2022/952.pdf uses rowhammer to actually perform the attack in practice on frodokem, but it also applies to ML-KEM as discussed in appendix A.1

I'm not sure this warrants adding a name to the author list but Scott said to do so--happy to contribute more explanation or other editing to the document.

[kmilner]

I think the advice would be to be protective about how your keys are generated in a way that may be unintuitive if you're used to traditional cryptosystems. Examples

• An airgapped machine (or library) can generate 'valid' keypairs which allow an adversary to discover the private key later.
• A user process on the machine can potentially interfere with key generation in such a way that the keys still work but are later breakable (the rowhammer paper above)
• (assumption on my part, I don't know if there's literature on this) in an embedded environment power faults might be sufficient.

You could generally just mess with the entropy used in key generation to achieve a similar sort of 'booby-trapped' keys, though, so maybe it isn't worth calling out specifically.

[sfluhrer]

The text you have is better; I would add two notes (and if you disagree with either of them, say so)

• This is much less of a concern if you're using ML-KEM ephemerally (that is, using a public/private key pair only once)
• If this is a concern, you should use an ML-KEM which has been hardened against such attacks.

[sfluhrer]

Thinking about it, I believe you have a good point. I would propose this alternative text, which should more explicitly convey your concerns (and also when it is applicable, and also an actionable mitigation). If you agree with this modified text, we can make that as your change (either you or I). If you prefer your text, I'll go ahead and merge it.

Proposed alternative text:

ML-KEM has a potential weakness that did not apply to the classical DH or ECDH cryptosystems. Lattice public keys are a lattice and a secret hidden by an error term. If the error term added public key generation stage is made larger due to a fault attack, then the success of decapsulation can reveal enough of the secret that successive queries determine the private key. That is, a public key can be 'poisoned' such that a future adversary can recover the private key even though it will appear correct in normal usage. This applies only if an ML-KEM public key is used repeatedly.; it does not apply if ML-KEM is used ephemerally. If that is the case, you may want to use an ML-KEM implementation that is hardened against such fault attacks.