Feedback on revised SP 800-227
dustin...@nist.gov
Dear all,
NIST appreciates the feedback and useful discussion from the KEM workshop and in response to the SP 800-227 ipd. We’ve incorporated several updates to SP 800-227 based on feedback and are currently finalizing SP 800-227 for publication. We want to solicit additional feedback for some of the updates. Please review the list of changes and provide your feedback:
0. Section reorganization: The List of Acronyms and Glossary were moved to appendices, and the Requirements list was moved to the Introduction. All other section numbers have decreased (e.g., previous section 5 is now section 4). All references to sections below use the new numbers.
1. Ephemeral vs Static Keys: In response to some comments about ephemeral keys and to align with similar requirements in SP 800-56A/B, we’ve added some requirements for ephemeral and static KEM key-pairs in sections 4.1 and 4.2, namely:
- Additional ‘must’ statement in section 4.1: “A key pair owner must check the key-pair consistency if the key pair is generated by a third party or stored as a static key-pair.”
- Additional ‘shall’ statement in section 4.2: Ephemeral key pairs shall be used in only one key-establishment transaction and shall be destroyed as soon as possible after use.
- Additional ‘must’ statement in section 4.2: If an encapsulating party obtains the static encapsulation key of another party, it must have assurance of the other party's ownership of the key before or during the key-establishment transaction. This assurance can be obtained from a trusted party (e.g., a certificate authority) or a combination of proof of possession and verification of real-world identity.
2. Obtaining shorter keys: We have updated the key derivation section (4.3) with how to obtain shorter keys from a KEM output key. For example, this could apply to the use of FIPS 203 which outputs 256-bit keys at all security levels.
3. Proof of Possession: There was some discussion at our workshop and a written public comment about how the unique functionality of RSA allows for special procedures to achieve proof of possession that does not generally apply to KEMs. We have added a section (4.5) discussing ways to achieve proof of possession for KEM keypairs. See the attached document for the new text.
4. Key Combiner Notation: We reformatted the inputs to our hash function calls from concatenated to comma separated. It was noted that concatenation may not be appropriate, depending on the protocol or context. See attached document for updated text.
5. Authenticated Key Establishment: We added two examples to Section 5 (5.2.4 and 5.2.5) illustrating how to use KEMs to achieve authenticated key establishment (using only KEMs) and updated minor details of existing examples. See the attached document for the new examples.
6. Key confirmation shall update: A comment noted that one of our ‘shall’ requirements was overly restrictive in permitting higher level parameters to run at lower security levels (e.g., running ML-KEM 768 at 128 bits of security). The requirement in section 4.4.1 has been updated.
Please let us know what you all think of the changes, particularly in regard to “Ephemeral vs Static Keys” and “Proof of Possession” (points 1 and 3). The attachment contains draft text corresponding to the sections mentioned above.
Thank you all again for your attention and involvement.
-NIST 227 Team
Mike Ounsworth
---
Mike Ounsworth
Sent: Friday, August 15, 2025 2:25 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] [pqc-forum] Feedback on revised SP 800-227
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ec4c2a18-4299-48cb-9f18-9fab3898c2b6n%40list.nist.gov.
Hamilton Silberg
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ec4c2a18-4299-48cb-9f18-9fab3898c2b6n%40list.nist.gov.
John Mattsson
Hi,
Looks very good. Alignment with SP 800-56A/B is great.
Some quick comments/suggestions:
- The list in Section 4.3 has the numbering 1, 5, 6
- "The security strength of any derived shorter key is the minimum of the security strength of K and the length of the derived key."
Should this be "the minimum of the security strength of K, the security strength of the KDM, and the length of the derived key."?
- "Truncating K, or Parsing K into non-overlapping segments to derive shorter keys"
I think the document should state that this can only be done once. I.e., you cannot use both K[0:15] and K[8:23]. This is different from the KDM procedure, which can be used several times.
- The sentence: "Note that some desirable security properties might not be achieved by a protocol of this form and may require additional steps and ingredients." should probably be said about all the example protocols.
Cheers,
John
From:
'Mike Ounsworth' via pqc-forum <pqc-...@list.nist.gov>
Date: Friday, 15 August 2025 at 21:47
To: pqc-forum <pqc-...@list.nist.gov>, dustin...@nist.gov <dustin...@nist.gov>
Subject: Re: [EXTERNAL] [pqc-forum] Feedback on revised SP 800-227
Hi Dustin,
I think your KEM PoP section (new 4.5) is good. It nicely draws attention to the "RSA sign-with-an-encryption-key" hack that I think we're going to discover is buried in more places than people realize. This might be a weird position coming from me, but you might be placing too much emphasis on certificates; yes, the CA can vouch that it did a PoP check at issuance time, but that doesn't necessarily mean that the person at the other end of your pipe has the private key; certs are public data after all. I think your sentence about doing a KEM protocol that includes key confirmation is the core point here, and that there aren't really any good options for doing non-interactive KEM PoPs.
Out of curiosity since I think it is not included in the attached PDF, what is the citation [23]?
---
Mike Ounsworth
From: 'dustin...@nist.gov' via pqc-forum <pqc-...@list.nist.gov>
Sent: Friday, August 15, 2025 2:25 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] [pqc-forum] Feedback on revised SP 800-227
Dear all, NIST appreciates the feedback and useful discussion from the KEM workshop and in response to the SP 800-227 ipd. We’ve incorporated several updates to SP 800-227 based on feedback and are currently finalizing SP 800-227 for publication.
Dear all,
NIST appreciates the feedback and useful discussion from the KEM workshop and in response to the SP 800-227 ipd. We’ve incorporated several updates to SP 800-227 based on feedback and are currently finalizing SP 800-227 for publication. We want to solicit additional feedback for some of the updates. Please review the list of changes and provide your feedback:
1. 0. Section reorganization: The List of Acronyms and Glossary were moved to appendices, and the Requirements list was moved to the Introduction. All other section numbers have decreased (e.g., previous section 5 is now section 4). All references to sections below use the new numbers.
1.
2. 1. Ephemeral vs Static Keys: In response to some comments about ephemeral keys and to align with similar requirements in SP 800-56A/B, we’ve added some requirements for ephemeral and static KEM key-pairs in sections 4.1 and 4.2, namely:
· - Additional ‘must’ statement in section 4.1: “A key pair owner must check the key-pair consistency if the key pair is generated by a third party or stored as a static key-pair.”
· - Additional ‘shall’ statement in section 4.2: Ephemeral key pairs shall be used in only one key-establishment transaction and shall be destroyed as soon as possible after use.
· - Additional ‘must’ statement in section 4.2: If an encapsulating party obtains the static encapsulation key of another party, it must have assurance of the other party's ownership of the key before or during the key-establishment transaction. This assurance can be obtained from a trusted party (e.g., a certificate authority) or a combination of proof of possession and verification of real-world identity.
2.
3. 2. Obtaining shorter keys: We have updated the key derivation section (4.3) with how to obtain shorter keys from a KEM output key. For example, this could apply to the use of FIPS 203 which outputs 256-bit keys at all security levels.
3.
4. 3. Proof of Possession: There was some discussion at our workshop and a written public comment about how the unique functionality of RSA allows for special procedures to achieve proof of possession that does not generally apply to KEMs. We have added a section (4.5) discussing ways to achieve proof of possession for KEM keypairs. See the attached document for the new text.
4.
5. 4. Key Combiner Notation: We reformatted the inputs to our hash function calls from concatenated to comma separated. It was noted that concatenation may not be appropriate, depending on the protocol or context. See attached document for updated text.
5.
6. 5. Authenticated Key Establishment: We added two examples to Section 5 (5.2.4 and 5.2.5) illustrating how to use KEMs to achieve authenticated key establishment (using only KEMs) and updated minor details of existing examples. See the attached document for the new examples.
6.
7. 6. Key confirmation shall update: A comment noted that one of our ‘shall’ requirements was overly restrictive in permitting higher level parameters to run at lower security levels (e.g., running ML-KEM 768 at 128 bits of security). The requirement in section 4.4.1 has been updated.
Please let us know what you all think of the changes, particularly in regard to “Ephemeral vs Static Keys” and “Proof of Possession” (points 1 and 3). The attachment contains draft text corresponding to the sections mentioned above.
Thank you all again for your attention and involvement.
-NIST 227 Team
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
pqc-forum+...@list.nist.gov.
To view this discussion visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ec4c2a18-4299-48cb-9f18-9fab3898c2b6n%40list.nist.gov.
Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
pqc-forum+...@list.nist.gov.
Mike Ounsworth
Sent: Friday, August 15, 2025 3:39:09 PM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Mike Ounsworth <Mike.Ou...@entrust.com>; dustin...@nist.gov <pqc-...@list.nist.gov>
Subject: Re: [EXTERNAL] [pqc-forum] Feedback on revised SP 800-227
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/64e137e5-12be-436f-a2a5-61c57f15f604n%40list.nist.gov.
Mike Ounsworth
Sent: Friday, August 15, 2025 4:03:57 p.m.
To: Hamilton Silberg <hamilton...@nist.gov>; pqc-forum <pqc-...@list.nist.gov>
Cc: dustin...@nist.gov <pqc-...@list.nist.gov>
Deirdre Connolly
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ec4c2a18-4299-48cb-9f18-9fab3898c2b6n%40list.nist.gov.
Hamilton Silberg
The 800-133 revision to support hybrids is underway, we're hoping to have that out for public comment soon (in the next month or so).
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.
Deirdre Connolly
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.