| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
OK, I’m trying to learn something from this exchange. But, I am now confused by the text in the IETF draft. In particular, the two cited sentences: ML-KEM's IND-CCA security satisfies this requirement such that the public key/secret key pair can be used long-term or re-used without compromising the security of the keys. and However, it is still recommended that implementations avoid re-use of any keys (including ML-KEM keys) to ensure perfect forward secrecy. seem to be almost directly contradictory, or at least are making a distinction that is too subtle for me to understand. Can one (or both) of you (Dan and Jay) explain why the first sentence seems to clearly say such long-term use is okay, but the second sentence seems to clearly say that it is not recommended, anyway? Mark From: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> Hi Jay, You’re highlighting the wrong part. Note how it says, “the public key/secret key pair can be treated as a long-term key or reused” and the IND-CCA property applies? That is exactly what I’m doing in the No Sig authentication exchange. So, you were incorrect when you said my proposal is “unsafe” because I’m reusing an ML-KEM encapsulation key. Dan. P.S. this is not TLS. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius From: "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> Hi Dan, Thanks for initiating this mail thread proactively. See it in the following paragraph, especially on the highlight part. Let me know your thought on this. The whole TLS -ML-KEM draft can be downloaded via the link at the end of this mail. 5. Security Considerations 5.1. IND-CCA The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA), which means that shared secret values should be indistinguishable from random strings even given the ability to have other arbitrary ciphertexts decapsulated . IND-CCA corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused. ML-KEM satisfies IND-CCA security in the random oracle model [KYBERV ]. TLS 1.3 does not prohibit key re-use; some implementations may use the same ephemeral public key for more than one key establishment at the cost of limited forward secrecy. Care must be taken to ensure that keys are only re-used if the algorithms from which they are derived are designed to be secure under key-reuse. ML-KEM's IND-CCA security satisfies this requirement such that the public key/secret key pair can be used long-term or re-used without compromising the security of the keys. However, it is still recommended that implementations avoid re-use of any keys (including ML-KEM keys) to ensure perfect forward secrecy. Implementations MUST NOT reuse randomness in the generation of ML-KEM ciphertexts . draft-ietf-tls-mlkem-05 - ML-KEM Post-Quantum Key Agreement for TLS 1.3 Thanks Best Regards Jay Yang (杨志杰) Original From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> Date: 2025年12月09日 01:51 Subject: [STDS-802-11-TGBT] Insecurity of "no sig " exchange in 11-25/1592r6 Hi Jay, Can you elaborate on your statement that it is “unsafe” to do what I’m doing in the No Signature Authentication exchange in 11-25/1592r6? What is unsafe and why is it unsafe? You said I should go talk to the IETF but that is not an appropriate response. If you have an issue with the security of a proposal you need to explain what the issue is. Making a claim and then saying other people need to go on wild chases tracking down people in other SDOs over vague and unattributed statements is not right. If you can’t explain the issue then retract the statement. So? What’s the issue? Dan. -- “the object of life is not to be on the side of the majority, but to Escape finding oneself in the ranks of the insane.” – Marcus Aurelius To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 |