rfc9881v1.txt		rfc9881.txt
	skipping to change at line 114 ¶		skipping to change at line 114 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Identifiers		2. Identifiers
	The AlgorithmIdentifier type is defined in [RFC5912] as follows:		The AlgorithmIdentifier type is defined in [RFC5912] as follows:
	AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=		AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
	SEQUENCE {		SEQUENCE {
	algorithm ALGORITHM-TYPE.id({AlgorithmSet}),		algorithm ALGORITHM-TYPE.id({AlgorithmSet}),
	parameters ALGORITHM-TYPE.		parameters ALGORITHM-TYPE.
	Params({AlgorithmSet}{@algorithm}) OPTIONAL		&Params({AlgorithmSet}{@algorithm}) OPTIONAL
	}		}
	| NOTE: The above syntax is from [RFC5912] and is compatible with		| NOTE: The above syntax is from [RFC5912] and is compatible with
	| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1		| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
	| syntax.		| syntax.
	The fields in AlgorithmIdentifier have the following meanings:		The fields in AlgorithmIdentifier have the following meanings:
	* algorithm identifies the cryptographic algorithm with an object		* algorithm identifies the cryptographic algorithm with an object
	identifier (OID).		identifier (OID).
	skipping to change at line 159 ¶		skipping to change at line 159 ¶
	3. ML-DSA Signatures in PKIX		3. ML-DSA Signatures in PKIX
	ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-		ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-
	aborts framework [Fiat-Shamir]. The security is based upon the		aborts framework [Fiat-Shamir]. The security is based upon the
	hardness of lattice problems over module lattices [Dilithium]. ML-		hardness of lattice problems over module lattices [Dilithium]. ML-
	DSA provides three parameter sets for the NIST PQC security		DSA provides three parameter sets for the NIST PQC security
	categories 2, 3, and 5.		categories 2, 3, and 5.
	Signatures are used in a number of different ASN.1 structures. As		Signatures are used in a number of different ASN.1 structures. As
	shown in the ASN.1 representation from [RFC5280] below, in an X.509		shown in the ASN.1 equivalent to that in [RFC5280] below, in an X.509
	certificate, a signature is encoded with an algorithm identifier in		certificate, a signature is encoded with an algorithm identifier in
	the signatureAlgorithm attribute and a signatureValue attribute that		the signatureAlgorithm attribute and a signatureValue attribute that
	contains the actual signature.		contains the actual signature.
	Certificate ::= SIGNED{ TBSCertificate }		Certificate ::= SIGNED{ TBSCertificate }
	SIGNED{ToBeSigned} ::= SEQUENCE {		SIGNED{ToBeSigned} ::= SEQUENCE {
	toBeSigned ToBeSigned,		toBeSigned ToBeSigned,
	algorithmIdentifier SEQUENCE {		algorithmIdentifier SEQUENCE {
	algorithm SIGNATURE-ALGORITHM.		algorithm SIGNATURE-ALGORITHM.
	skipping to change at line 595 ¶		skipping to change at line 595 ¶
	efficiently recover the private key by trying a small set of		efficiently recover the private key by trying a small set of
	possibilities, rather than brute-force searching the whole keyspace.		possibilities, rather than brute-force searching the whole keyspace.
	The generation of random numbers of a sufficient level of quality for		The generation of random numbers of a sufficient level of quality for
	use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for		use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for
	some additional information.		some additional information.
	In the design of ML-DSA, care has been taken to make side-channel		In the design of ML-DSA, care has been taken to make side-channel
	resilience easier to achieve. For instance, ML-DSA does not depend		resilience easier to achieve. For instance, ML-DSA does not depend
	on Gaussian sampling. Implementations must still take great care not		on Gaussian sampling. Implementations must still take great care not
	to leak information via various side channels. While deliberate		to leak information via various side channels. While deliberate
	design decisions such as these can help to deliver a greater ease of		design decisions such as these can help to deliver a secure
	secure implementation -- particularly against side-channel attacks --		implementation with greater ease -- particularly against side-channel
	it does not necessarily provide resistance to more powerful attacks		attacks -- it does not necessarily provide resistance to more
	such as differential power analysis. Some amount of side-channel		powerful attacks such as differential power analysis. Some amount of
	leakage has been demonstrated in parts of the signing algorithm		side-channel leakage has been demonstrated in parts of the signing
	(specifically the bit-unpacking function), from which a demonstration		algorithm (specifically the bit-unpacking function), from which a
	of key recovery has been made over a large sample of signatures.		demonstration of key recovery has been made over a large sample of
	Masking countermeasures exist for ML-DSA, but comes with performance		signatures. Masking countermeasures exist for ML-DSA, but comes with
	overhead.		performance overhead.
	ML-DSA offers both deterministic and randomized signing. Signatures		ML-DSA offers both deterministic and randomized signing. Signatures
	generated with either mode are compatible and a verifier can't tell		generated with either mode are compatible and a verifier can't tell
	them apart. In the deterministic case, a signature only depends on		them apart. In the deterministic case, a signature only depends on
	the private key and the message to be signed. This makes the		the private key and the message to be signed. This makes the
	implementation easier to test and does not require a randomness		implementation easier to test and does not require a randomness
	source during signing. In the randomized case, signing mixes in a		source during signing. In the randomized case, signing mixes in a
	256-bit random string from an approved random bit generator (RBG).		256-bit random string from an approved random bit generator (RBG).
	When randomized, ML-DSA is easier to harden against fault and		When randomized, ML-DSA is easier to harden against fault and
	hardware side-channel attacks.		hardware side-channel attacks.
	A security property that is also associated with digital signatures		A security property that is also associated with digital signatures
	is non-repudiation. Non-repudiation refers to the assurance that the		is non-repudiation. Non-repudiation refers to the assurance that the
	owner of a signature key pair that was capable of generating an		owner of a signature keypair that was capable of generating an
	existing signature corresponding to certain data cannot convincingly		existing signature corresponding to certain data cannot convincingly
	deny having signed the data, unless its private key was compromised.		deny having signed the data, unless its private key was compromised.
	The digital signature scheme ML-DSA possesses three security		The digital signature scheme ML-DSA possesses three security
	properties beyond unforgeability, that are associated with non-		properties beyond unforgeability, that are associated with non-
	repudiation. These are exclusive ownership, message-bound		repudiation. These are exclusive ownership, message-bound
	signatures, and non-resignability. These properties are based		signatures, and non-resignability. These properties are based
	tightly on the assumed collision resistance of the hash function used		tightly on the assumed collision resistance of the hash function used
	(in this case SHAKE-256). A full discussion of these properties in		(in this case SHAKE-256). A full discussion of these properties in
	ML-DSA can be found at [CDFFJ21].		ML-DSA can be found at [CDFFJ21].
	skipping to change at line 680 ¶		skipping to change at line 680 ¶
	[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:		[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,		(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
	February 2021, <https://www.itu.int/rec/T-REC-X.690>.		February 2021, <https://www.itu.int/rec/T-REC-X.690>.
	10.2. Informative References		10.2. Informative References
	[CDFFJ21] Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C.		[CDFFJ21] Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C.
	Janson, "BUFFing signature schemes beyond unforgeability		Janson, "BUFFing signature schemes beyond unforgeability
	and the case of post-quantum signatures", 2021 IEEE		and the case of post-quantum signatures", Cryptology
	Symposium on Security and Privacy (SP), pp. 1696-1714,		ePrint Archive, Paper 2020/1525, October 2023,
	DOI 10.1109/SP40001.2021.00093, 2021,		<https://eprint.iacr.org/2020/1525.pdf>.
	<https://ieeexplore.ieee.org/document/9519420>.
	[Dilithium]		[Dilithium]
	Bai, S., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,		Bai, S., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,
	V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS-		V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS-
	Dilithium Algorithm Specifications and Supporting		Dilithium Algorithm Specifications and Supporting
	Documentation (Version 3.1)", 8 February 2021,		Documentation (Version 3.1)", 8 February 2021,
	<https://pq-crystals.org/dilithium/data/dilithium-		<https://pq-crystals.org/dilithium/data/dilithium-
	specification-round3-20210208.pdf>.		specification-round3-20210208.pdf>.
	[Fiat-Shamir]		[Fiat-Shamir]
	skipping to change at line 876 ¶		skipping to change at line 875 ¶
	PARAMS ARE absent		PARAMS ARE absent
	PUBLIC-KEYS { pk-ml-dsa-87 }		PUBLIC-KEYS { pk-ml-dsa-87 }
	SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }		SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }
	}		}
	END		END
	<CODE ENDS>		<CODE ENDS>
	Appendix B. Security Strengths		Appendix B. Security Strengths
	Instead of defining the strength of a quantum algorithm in a		Instead of defining the strength of a quantum algorithm using the
	traditional manner using the imprecise notion of bits of security,		common but imprecise notion of bits of security, NIST has instead
	NIST has instead elected to define security levels by picking a		elected to define security levels by picking a reference scheme,
	reference scheme, which NIST expects to offer notable levels of		which NIST expects to offer notable levels of resistance to both
	resistance to both quantum and classical attacks. To wit, an		quantum and classical attacks. To wit, an algorithm that achieves
	algorithm that achieves NIST PQC security level 1 must require		NIST PQC security level 1 must require computational resources to
	computational resources to break the relevant security property,		break the relevant security property, which are greater than those
	which are greater than those required for a brute-force key search on		required for a brute-force key search on AES-128. Levels 3 and 5 use
	AES-128. Levels 3 and 5 use AES-192 and AES-256 as references,		AES-192 and AES-256 as references, respectively. Levels 2 and 4 use
	respectively. Levels 2 and 4 use collision search for SHA-256 and		collision search for SHA-256 and SHA-384 as references.
	SHA-384 as references.
	The parameter sets defined for NIST security levels 2, 3, and 5 are		The parameter sets defined for NIST security levels 2, 3, and 5 are
	listed in Figure 1, along with the resulting signature size, public		listed in Figure 1, along with the resulting signature size, public
	key, and private key sizes in bytes. Note that these are the sizes		key, and private key sizes in bytes. Note that these are the sizes
	of the raw keys, not including ASN.1 encoding overhead from		of the raw keys, not including ASN.1 encoding overhead from
	OneAsymmetricKey and SubjectPublicKeyInfo wrappers. Private key		OneAsymmetricKey and SubjectPublicKeyInfo wrappers. Private key
	sizes are shown for both the seed format and expanded format.		sizes are shown for both the seed format and expanded format.
	+=======+=======+=====+==========+========+=========+===========+		+=======+=======+=====+==========+========+=========+===========+
	| Level | (k,l) | eta | Sig. (B) | Public | Private | Private |		| Level | (k,l) | eta | Sig. (B) | Public | Private | Private |
	skipping to change at line 3840 ¶		skipping to change at line 3838 ¶
	key.		key.
	3. The third ML-DSA-PrivateKey example also includes only		3. The third ML-DSA-PrivateKey example also includes only
	expandedKey. The private s_1 and s_2 vectors imply a t vector		expandedKey. The private s_1 and s_2 vectors imply a t vector
	whose private low bits do not match the t_0 vector portion of the		whose private low bits do not match the t_0 vector portion of the
	private key (its high bits t_1 are the primary content of the		private key (its high bits t_1 are the primary content of the
	public key).		public key).
	The second and third examples would not be detected by		The second and third examples would not be detected by
	implementations that do not regenerate the public key from the		implementations that do not regenerate the public key from the
	private key, or neglect to then check consistency of tr or t_0.		private key or, when they do, they neglect to check consistency of tr
			and t_0.
	The following is the first example:		The following is the first example:
	-----BEGIN PRIVATE KEY-----		-----BEGIN PRIVATE KEY-----
	MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR		MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR
	EhMUFRYXGBkaGxwdHh8EggoAUQyb/R3XN09Oiucd1YKBEGqTQS7Y+jV/dLu0Zh7L		EhMUFRYXGBkaGxwdHh8EggoAUQyb/R3XN09Oiucd1YKBEGqTQS7Y+jV/dLu0Zh7L
	GSHTp1/JO4jvDmqbhRvs7BmZm+gQaMhZ1t8RXGCMFQEXDrbAVcIvYlWSSXbYlaX1		GSHTp1/JO4jvDmqbhRvs7BmZm+gQaMhZ1t8RXGCMFQEXDrbAVcIvYlWSSXbYlaX1
	TSw4WWxAPM72+XPiKl+MfCuoNjNEcJCniyK7Qc/e2vvLLt7PkHDM5hLkKrCh8T65		TSw4WWxAPM72+XPiKl+MfCuoNjNEcJCniyK7Qc/e2vvLLt7PkHDM5hLkKrCh8T65
	3DwUkDGJwoHgsDHalISCEgijtDDSKEoEByDDRELgQC5EoHEBqSwDJmQSQSQYMiQA		3DwUkDGJwoHgsDHalISCEgijtDDSKEoEByDDRELgQC5EoHEBqSwDJmQSQSQYMiQA
	Ii5KlmALGZAiMyBShkUbCEyTGIQZAG1TgAwQpChQBgogBgwjETLSxEDSEgIENIYj		Ii5KlmALGZAiMyBShkUbCEyTGIQZAG1TgAwQpChQBgogBgwjETLSxEDSEgIENIYj
	skipping to change at line 4058 ¶		skipping to change at line 4057 ¶
	# M is the message, a bit-string		# M is the message, a bit-string
	# μ and ctx are byte-strings.		# μ and ctx are byte-strings.
	# ctx is the context string, which defaults to the empty string.		# ctx is the context string, which defaults to the empty string.
	μ = H(BytesToBits(H(pk, 64) || IntegerToBytes(0, 1) ||		μ = H(BytesToBits(H(pk, 64) || IntegerToBytes(0, 1) ||
	IntegerToBytes(|ctx|, 1) || ctx) || M, 64)		IntegerToBytes(|ctx|, 1) || ctx) || M, 64)
	# The functions `BytesToBits` and `IntegerToBytes` are defined		# The functions `BytesToBits` and `IntegerToBytes` are defined
	# in FIPS 204.		# in FIPS 204.
	return μ		return μ
	Figure 1: Computeμ Prehash Operation		Figure 1: Computeμ Pre-Hash Operation
	Sign operations:		Sign operations:
	Signμ(sk, μ):		Signμ(sk, μ):
	# Referred to as 'Externalμ-ML-DSA.Sign(sk, μ)'		# Referred to as 'Externalμ-ML-DSA.Sign(sk, μ)'
	# in the FIPS 204 FAQ.		# in the FIPS 204 FAQ.
	if |μ| != 64 then		if |μ| != 64 then
	return error # return an error indication if the input μ is not		return error # return an error indication if the input μ is not
	skipping to change at line 4083 ¶		skipping to change at line 4082 ¶
	# set rnd to all zeroes		# set rnd to all zeroes
	if rnd = NULL then		if rnd = NULL then
	return error # return an error indication if random bit		return error # return an error indication if random bit
	# generation failed		# generation failed
	end if		end if
	sigma = Signμ_internal(sk, μ, rnd, isExternalμ=true)		sigma = Signμ_internal(sk, μ, rnd, isExternalμ=true)
	return sigma		return sigma
	ML-DSA.Signμ_internal(sk, M', rnd, isExternalμ=false):		ML-DSA.Signμ_internal(sk, M', rnd, isExternalμ=false):
	# μ can be passed as an argument instead of M'		# μ is passed to the function via the argument M'.
	# defaulting is Externalμ to false means that		# Defaulting Externalμ to false means that
	# this modified version of Sign_internal can be used		# this modified version of Sign_internal can be used
	# in place of the original without interfering with		# in place of the original without interfering with
	# the functioning of pure ML-DSA mode.		# functioning of pure ML-DSA mode.
	# ... identical to FIPS 204 Algorithm 7, but with Line 6 replaced
	# with		# ... identical to FIPS 204 Algorithm 7, but with Line 6
			# replaced with
	6: if (isExternalμ):		6: if (isExternalμ):
	μ = M'		μ = M'
	else:		else:
	μ = H(BytesToBits(tr) || M', 64)		μ = H(BytesToBits(tr) || M', 64)
	Figure 2: The Operations for Signing μ		Figure 2: The Operations for Signing μ
	There is no need to specify an External μ Verify() routine because		There is no need to specify an External μ Verify() routine because
	this is identical to the original ML-DSA.Verify(). This makes		this is identical to the original ML-DSA.Verify(). This makes
	External μ mode simply an internal optimization of the signer, and		External μ mode simply an internal optimization of the signer, and
End of changes. 10 change blocks.
	38 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.48.