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

["Markku-Juhani O. Saarinen" <[e-mail]>]

On Thu, Sep 8, 2022 at 8:32 AM Simon Guggi <[e-mail]>
wrote:

> Hi,
>
> 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.
>
>
> - I also support the byte array encoding for the private key proposed by
> the algorithm designers. It is an already defined encoding, so I think it
> makes sense to take that one.
> Also the public key is encoded as an array (but as a BIT STRING instead,
> because of rfc 5912), so I think to be at least somewhat consistent the
> private and public key should be
> encoded as an OCTET STRING and BIT STRING respectively.
>
>     - On that note I just wanted to add that I think it would make more
> sense that the public key is also encoded as an OCTET STRING, but I guess
> that can't happen because of backward-compatibility.
>
>
Hi Simon and all,

I guess it can be a BIT STRING, but it clearly must be of a specific
length. For verification purposes, the algorithm identifiers for
Dilithium2, Dilithium3, and Dilithium5 should be explicit. Determining that
from the public key length is a hack and could be a security issue. Just
noting that for completeness; the current "id-dilithiumTBD" is clearly
temporary. Anyway, a Dilithium-in-PKI I-D would need very clear
verification rules related to this issue.

Whatever format the public key is wrapped in, the "raw concatenated
sequence of bytes" (without any ASN.1 tags, as defined for algorithm
designers for public keys) is actually used inside the signature process
itself: the thing being signed is always prefixed by its hash: mu = H(
H(pk) | m ). One obviously can't sign or verify in an interoperable fashion
if one doesn't use that specific raw format for the hash prefix H(pk), also
denoted "tr" in the spec. It is encoded into the secret key just to tie the
public key with the secret key: Key import functions must check that the
"tr" hash matches.

Cheers,
- Markku

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



M:             [phone]

E:              [e-mail]
W:             www.pqshield.com

>
>
> On 06.09.22 12:56, Markku-Juhani O. Saarinen wrote:
>
> On Mon, Sep 5, 2022 at 7:47 PM Russ Housley <[e-mail]> wrote:
>
>> There has been some discussion of
>> https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/.
>> 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
> 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]
> W:             www.pqshield.com
>
>
>>
>> On behalf of the LAMPS WG Chairs,
>> Russ
>>
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
>>
>
> _______________________________________________
> Spasm mailing [e-mail]://www.ietf.org/mailman/listinfo/spasm
>
>
> --
> Simon Guggi
> SIC - Software Engineer
> Phone: [phone] - 5562
> SIC Homepage: https://jce.iaik.tugraz.at/
> IAIK Homepage: https://www.iaik.tugraz.at/
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>