Re: [lamps] [EXTERNAL] Re: Call for adoption ofdraft-massimo-lamps-pq-sig-certificates

[John Gray <[e-mail]>]

I support adoption of the draft by LAMPS and will review updates and give feedback.

Cheers,

John Gray


From: Spasm <[e-mail]> On Behalf Of Markku-Juhani O. Saarinen
Sent: Tuesday, September 6, 2022 6:57 AM
To: Russ Housley <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Call for adoption ofdraft-massimo-lamps-pq-sig-certificates

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
On Mon, Sep 5, 2022 at 7:47 PM Russ Housley <[e-mail]<mailto:[e-mail]>> wrote:
There has been some discussion of https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/__;!!FJ-Y8qCqXTj2!fU1Mkm-hNjsP4bnarWKz6X7mS3_ji4d_VTFffsHE0Le9V8jHM8xbWyTaIkyvkpTAGZhC5JTm9vzwBPHCL3Z1wQ$>.  During the discussion at IETF 114, it was agreed that a separate document would be written for each NIST PQC algorithm.  As a result, this document will cover CRYSTALS-DILITHIUM.

Should the LAMPS WG adopt “Algorithms and Identifiers for Post-Quantum Algorithms in the Internet X.509 Public Key Infrastructure” in draft-massimo-lamps-pq-sig-certificates-00?

Please reply to this message by Monday, 19 September 2022 to voice your support or opposition to adoption.

Hi,

I'd support LAMPS adopting this. I assume that the new title will be something like "Algorithms and Identifiers for CRYSTALS-DILITHIUM in the Internet X.509 Public Key Infrastructure.”

Misc comments:

- The document should more clearly identify the version of Dilithium: 3.1. If there are more versions, those would have different identifiers. There has been compatibility-breaking changes after the version submitted as a Finalist to Round 3, which is still on the NIST website (we've had customers try to match our implementation with those v3.0 KATs, requiring explanations). The changes from 3.0 to 3.1 include a security fix (at Level 5), so compatibility with the latest version is important. See Vadim Lyubashevsky's explanation, February 8, 2021: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/BjfjRMIdnhM/m/W7kkVOFDBAAJ<https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/g/pqc-forum/c/BjfjRMIdnhM/m/W7kkVOFDBAAJ__;!!FJ-Y8qCqXTj2!fU1Mkm-hNjsP4bnarWKz6X7mS3_ji4d_VTFffsHE0Le9V8jHM8xbWyTaIkyvkpTAGZhC5JTm9vzwBPHT8x4EmQ$>  Note that there were several other internal changes in from 3.0. to 3.1 apart from the hash lengths.

- A note about the signing process would be helpful; Dilithium 3.1 computes a signature for mu = H2( H1(pk) | M ), where H1 is SHAKE-256 truncated to 32 bytes -- a hash of the public key, also denoted "tr" -- and H2 is SHAKE-256 truncated to 64 bytes. The number designation of SHAKE of course indicates security level, not the output length, as SHAKE is an XOF.

- I suggest the document also includes signature sizes for (detached) signatures: 2420, 3293, and 4595 bytes. Currently, only public and private key sizes are reported in Appendix B of the I-D.

- The secret key lengths in Appendix B match with v3.1 (v3.0 has 16 bytes longer private keys), but do not account for ASN.1 encoding of the SEQUENCE in Section 5 of the same I-D. Even section 5 itself does not seem to account for this as it reports "the size necessary to hold all private key elements." There is a de facto key transport encoding for secret keys, defined by the algorithm designers and used in KAT tests, that doesn't have ASN.1 encoding of individual components. It can be simply taken as an OCTET STRING, just like the public key in this I-D. The lengths in Appendix B match that encoding, not the completely new encoding in Section 5.

- Section 5 states "The randomized version can be invoked by leaving K as EMPTY." Private key formats are determined by application requirements and should not be used as "APIs" to affect functionality as suggested. Side-channel secure implementations will only use this type of plaintext ASN.1 encoding for backup/transport (never actively) and are likely to always perform randomized signing. Some other implementations (perhaps without trustworthy RNGs) may always perform deterministic signing; this does not break the interoperability of signatures. The explanation for the "tr" field in that private key format is not accurate (see above).

Cheers,
- markku


Dr. Markku-Juhani O. Saarinen
Staff Cryptography Architect
PQShield Ltd



M:             [phone]

E:              [e-mail]<mailto:[e-mail]>
W:             www.pqshield.com<https://urldefense.com/v3/__http:/www.pqshield.com/__;!!FJ-Y8qCqXTj2!fU1Mkm-hNjsP4bnarWKz6X7mS3_ji4d_VTFffsHE0Le9V8jHM8xbWyTaIkyvkpTAGZhC5JTm9vzwBPFLV_yjaQ$>


On behalf of the LAMPS WG Chairs,
Russ

_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!fU1Mkm-hNjsP4bnarWKz6X7mS3_ji4d_VTFffsHE0Le9V8jHM8xbWyTaIkyvkpTAGZhC5JTm9vzwBPHYlLogNg$>
Any email and files/attachments transmitted with it are confidential and 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.