Quantum Safe Cryptography Key Information for CRYSTALS-DilithiumNXP SemiconductorsHigh Tech Campus 60AE Eindhoven5656NLcvvrede@gmail.comIBM Research GmbHSaeumerstrasse 4 Rueschlikon8803CHsid@zurich.ibm.comIBM Research GmbHSaeumerstrasse 4 Rueschlikon8803CHbhe@zurich.ibm.comIBM Research GmbHSaeumerstrasse 4 Rueschlikon8803CHtvi@zurich.ibm.comIBM Research GmbHSaeumerstrasse 4 Rueschlikon8803CHosb@zurich.ibm.comUtimaco IS GmbHGermanusstrasse 4 Aachen52080DEdieter.bong@utimaco.comNXP SemiconductorsHigh Tech Campus 60AE Eindhoven5656NLjoppe.bos@nxp.com
General
Internet Engineering Task ForcetemplateThis proposal defines key management approaches for the Quantum Safe Cryptographic (QSC) algorithm CRYSTALS-Dilithium
which has been selected for standardization by the NIST Post Quantum Cryptography (PQC) process.
This includes key identification, key serialization, and key compression. The purpose is to provide guidance such that
the adoption of quantum safe algorithms is not hampered with the fragmented evolution of necessary key management standards.
Early definition of key material standards will help expedite the adoption of new quantum safe algorithms and at the same time as improving interoperability between implementations and minimizing divergence across standards. IntroductionQSC algorithms being standardized in the NIST PQC Process have evolved through several rounds and iterations. Keys are neither easily identifiable nor compatible across rounds. It is also expected that algorithms will evolve after final candidates have been selected. The lack of binary compatibility between algorithm versions and variants means that it is important to clearly identify key material. Parallel to the NIST process, industry is evaluating the impact of adopting new PQC algorithms, in particular key management. Here it is important to define and standardize key serialization and encoding formats. Finally, we have seen that many platforms and protocols are very constrained when it comes to the amount of memory or space available for key objects. This makes it important to define and standardize key compression formats. This proposal addresses aspects of key identification, key serialization, and key compression for the future primary NIST PQC Digital Signature standard, CRYSTALS-Dilithium. For the other schemes, see draft-uni-qsckeys-kyber, draft-uni-qsckeys-falcon, draft-uni-qsckeys-sphincsplus and the previous Internet-Draft . This proposal will be updated when the final NIST standard for CRYSTALS-Dilithium becomes available.Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
RFC 2119
.
Algorithm IdentificationAlgorithm identification is important for several reasons:
Managing a smooth transition from early adoption algorithm versions to production versions where there is no compatibility.
Supporting different algorithm versions from different NIST rounds
Identifying different key serialization strategies
Identifying compressed and uncompressed keys
The current standardization of quantum safe algorithms does not address the definition of serialization structures for keys. As a result, it has become commonplace for the cryptographic community working on and with these algorithms to define their own approaches. This leads to proprietary and internal representations for key material. This has certain advantages in terms of ease of experimentation while focusing on finding the best-performing QSC algorithms. In terms of longer-term support where algorithm versions change this is a problem.
This proposal defines in section 2 a long-term structured key representation format useful to address the goals outlined above.Algorithm and Algorithm Parameter Object Identifier
Algorithm and algorithm parameter information shall have ASN.1 type AlgorithmIdentifier as given in
and shall be extended by an pqcAlgorithmParameterName type in the optional parameters field:
Overview of CRYSTALS-Dilithium and parameter OIDsCRYSTALS-Dilithium consists of six parameter sets. This memo attributes a name and a placeholder for an OID to the different parameter sets of CRYSTALS-Dilithium. The following table gives an overview of the possible OIDs in the algorithm field and possible parameters set names in the parameters field of the AlgorithmIdentifier type. Each name or OID represents a single parameter set of given security. Details can be found in the next section.Key Formats
The private key format defined is from PKCS#8
.
PKCS#8 PrivateKeyInfo is defined as:
Distributing a PQC private key requires a PKCS#8 PrivateKeyInfo with a joined PQC algorithm and algorithm parameter OID in the algorithm field of AlgorithmIdentifier and a PQC algorithm specific private key object in the privateKey field of PrivateKeyInfo. Both objects are defined in the specific algorithm sections of this document. For an overview see tables above and below.
Public Key Format based on
RFC5280 subjectPublicKeyInfo is defined in as:
Distributing a PQC public key requires a
subjectPublicKeyInfo with a joined PQC algorithm and algorithm parameter OID in the algorithm field of AlgorithmIdentifier and a PQC algorithm specific public key object in the subjectPublicKey field of subjectPublicKeyInfo. Both objects are defined in the specific algorithm sections of this document. For an overview see tables above and below.
Overview of Memo Definitions - PQC Key Formats
The privateKey field in the PrivateKeyInfo type
is an OCTET STRING whose contents are the value of the private key. The interpretation of the content differs from PQC algorithm to algorithm. The subjectPublicKey field in the subjectPublicKeyInfo type
is a BIT STRING whose contents are the value of the public key. Here also the interpretation of the content differs from PQC algorithm to algorithm.
CRYSTALS-DilithiumCRYSTALS-Dilithium is a digital signature scheme that is based on the hardness of lattice problems over module lattices.
Algorithm Parameter IdentifiersCRYSTALS-Dilithium uses OIDs to identify parameters sets.
|
| NIST Level Security | Level 2 |
|-------------------------|-------------------------------------|
| Parameters | Polynomial Ring Zq[x]/( x^n+1 ) |
| | Dimension/Degree n=256 |
| | Modulus q=8380417 |
| | Dropped bits from t: d=13 |
| | # of +-1's in c: tau=39 |
| | challenge entropy=192 |
| | gamma coefficient range: gamma1=2^17|
| | low-order rounding range: gamma2=(q-|
| | 1)/88 |
| | Private key Range eta=2 |
| | Dimensions of A: (k,l)=(4,4) |
| | Max # of 1's in the hint h: w=80 |
| | Repetitions=4.25 |
|=========================+=====================================|
| dilithium-4x4-aes-r3 |
|=========================+=====================================|
| Parameter OID | {..*.. dilithium-4x4-aes-r3} |
| | <.> |
| NIST Level Security | Level 2 |
|-------------------------|-------------------------------------|
| Parameters | Polynomial Ring Zq[x]/( x^n + 1 ) |
| | Dimension/Degree n=256 |
| | Modulus q=8380417 |
| | Dropped bits from t: d=13 |
| | # of +-1's in c: tau=39 |
| | challenge entropy=192 |
| | y coefficient range: gamma1=2^17 |
| | low-order rounding range:gamma2=(q- |
| | -1)/88 |
| | Private key Range eta=2 |
| | Dimensions of A: (k,l)=(4,4) |
| | Max # of 1's in the hint h: w=80 |
| | Repetitions=4.25 |
|=========================+=====================================|
| dilithium-6x5-r3 |
|=========================+=====================================|
| Parameter OID | {..*.. dilithium-6x5-r3} |
| | <.> |
| NIST Level Security | Level 3 |
|-------------------------|-------------------------------------|
| Parameters | Polynomial Ring Zq[x]/( x^n + 1 ) |
| | Dimension/Degree n=256 |
| | Modulus q=8380417 |
| | Dropped bits from t: d=13 |
| | # of +-1's in c: tau=49 |
| | challenge entropy=225 |
| | y coefficient range: gamma1=2^19 |
| | low-order rounding range:gamma2=(q- |
| | -1)/32 |
| | Private key Range eta=4 |
| | Dimensions of A: (k,l)=(6,5) |
| | Max # of 1's in the hint h: w=55 |
| | Repetitions=5.1 |
|=========================+=====================================|
| dilithium-6x5-aes-r3 |
|=========================+=====================================|
| Parameter OID | {..*.. dilithium-6x5-aes-r3} |
| | <.> |
| NIST Level Security | Level 3 |
|-------------------------|-------------------------------------|
| Parameters | Polynomial Ring Zq[x]/( x^n +1 ) |
| | Dimension/Degree n=256 |
| | Modulus q=8380417 |
| | Dropped bits from t: d=13 |
| | # of +-1's in c: tau=49 |
| | challenge entropy=225 |
| | y coefficient range: gamma1=2^19 |
| | low-order rounding range:gamma2=(q- |
| | -1)/32 |
| | Private key Range eta=4 |
| | Dimensions of A: (k,l)=(6,5) |
| | Max # of 1's in the hint h: w=55 |
| | Repetitions=5.1 |
|=========================+=====================================|
| dilithium-8x7-r3 |
|=========================+=====================================|
| Parameter OID | {..*.. dilithium-8x7-r3} |
| | <.> |
| NIST Level Security | Level 5 |
|-------------------------|-------------------------------------|
| Parameters | Polynomial Ring Zq[x]/( x^n + 1 ) |
| | Dimension/Degree n=256 |
| | Modulus q=8380417 |
| | Dropped bits from t: d=13 |
| | # of +-1's in c: tau=60 |
| | challenge entropy=257 |
| | y coefficient range: gamma1=2^19 |
| | low-order rounding range:gamma2=(q- |
| | -1)/32 |
| | Private key Range eta=2 |
| | Dimensions of A: (k,l)=(8,7) |
| | Max # of 1's in the hint h: w=75 |
| | Repetitions=3.85 |
|=========================+=====================================|
| dilithium-8x7-aes-r3 |
|=========================+=====================================|
| Parameter OID | {..*.. dilithium-8x7-aes-r3} |
| | <.> |
| NIST Level Security | Level 5 |
|-------------------------|-------------------------------------|
| Parameters | Polynomial Ring Zq[x]/( x^n + 1 ) |
| | Dimension/Degree n=256 |
| | Modulus q=8380417 |
| | Dropped bits from t: d=13 |
| | # of +-1's in c: tau=60 |
| | challenge entropy=257 |
| | y coefficient range: gamma1=2^19 |
| | low-order rounding range:gamma2=(q- |
| | -1)/32 |
| | Private key Range eta=2 |
| | Dimensions of A: (k,l)=(8,7) |
| | Max # of 1's in the hint h: w=75 |
| | Repetitions=3.85 |
|=========================+=====================================|
]]>
The AES variants listed above differ from the other variants in that they use AES, rather than SHAKE internally to expand the key parameters from an initial seed. While the parameters listed in the table are the same, the key-pairs will not be compatible with the 'aes' variants.Key DetailsPublic key. The public-key consists of two parameters:
rho: nonce
t1: a vector encoded in 320*k bytes
The size necessary to hold all public key elements accounts to 32+320*k bytes.Private key. The private key consists of 6 parameters:
rho: nonce
K: a key/seed/D
tr: PRF bytes
s1: vector (L)
s2: vector (K)
t0: k polynomials
If the private key is fully populated, it consists of 6 parameters. The size necessary to hold all private key elements accounts to 32+32+32+32*[(k+l)*ceiling(log(2*eta+1))+13*k] bytes.
The resulting public key and private key sizes can be found in the table below.Private Key Full EncodingEncoding a CRYSTALS-Dilithium private key with PKCS#8 must include the following two fields:
dilithium-(kxl)-r3 in the algorithm field of AlgorithmIdentifier
DilithiumPrivateKey in the privateKey field, which is an OCTET STRING.
CRYSTALS-Dilithium public keys are optionally distributed in the PublicKey field of the PrivateKeyInfo structure.ASN.1 Encoding for a CRYSTALS-Dilithium private key when fully populated:Private Key Partial Encoding Option 1In option 1 ofCRYSTALS-Dilithium partial encoding the rho (nonce) and the seed (key) are used to regenerate the full key.
Note: There are a number of alternative ways to encode a partially filled structure that include defining fields as optional and defining fields as 'EMPTY'. As an example partial RSA keys are encoded using EMPTY fields. It can be argued that defining fields as EMPTY significantly simplifies the implementation of parsing ASN.1 frames.
The ASN.1 format for the partially populated versions is the same as for the fully populated version.
The ASN.1 encoding for the first variant (rho and seed) is defined as follows:Private key Partial Encoding Option 2In option 2 of CRYSTALS-Dilithium partial encoding only zeta (nonce) is used to regenerate the full key.
The ASN.1 encoding for this is defined as follows:Public Key Full EncodingComponents are individual OCTET STRINGs, without unused bits, encoded with the exact size. There is no removal of leading zeroes.AcknowledgementsThis template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.This document is part of a plan to make xml2rfc indispensable.IANA ConsiderationsThis memo includes no request to IANA.Security ConsiderationsAny processing of the ASN.1 private key structures, such as base64 en/decoding shall be performed in "constant-time", meaning without secret-dependent control flow and table lookups.
The ASN.1 structures in this document are defined with fixed tag-lengths. The purpose is to prevent side-channel leakage of variable lengths during DER parsing. Any DER parsing of the private key ASN.1 key structures shall be performed with these fixed lengths.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileElliptic Curve Cryptography Subject Public Key InformationInformative ReferencesWriting I-Ds and RFCs using XMLThis memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.Guidelines for Writing RFC Text on Security ConsiderationsAll RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guidelines for Writing an IANA Considerations Section in RFCsThis RFC addresses key identification, key serialization, and key compression for the set of quantum safe algorithms currently under evaluation in the NIST PQC process. The aim of this RFC is to facilitate the management of key material as these algorithms evolve through standardization phases into production. Early definition of key material is expected to expedite the adoption of new quantum safe algorithms at the same time as improving interoperability and preventing diverging standards. Quantum Safe Cryptography Key InformationNXP SemiconductorsIBM Research GmbHIBM Research GmbHIBM Research GmbHIBM Research GmbHUtimaco IS GmbHNXP SemiconductorsThis proposal defines key management approaches for Quantum Safe Cryptographic (QSC) algorithms currently under evaluation in the NIST Post Quantum Cryptography (PQC) process. This includes key identification, key serialization, and key compression. The purpose is to provide guidance such that the adoption of quantum safe algorithms is not hampered with the fragmented evolution of necessary key management standards. Early definition of key material standards will help expedite the adoption of new quantum safe algorithms at the same time as improving interoperability between implementations and minimizing divergence across standards.Additional StuffThis becomes an Appendix.