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 181 ¶		skipping to change at line 181 ¶
	parameters SIGNATURE-ALGORITHM.		parameters SIGNATURE-ALGORITHM.
	&Params({SignatureAlgorithms}		&Params({SignatureAlgorithms}
	{@algorithmIdentifier.algorithm})		{@algorithmIdentifier.algorithm})
	OPTIONAL		OPTIONAL
	},		},
	signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(		signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
	{SignatureAlgorithms}		{SignatureAlgorithms}
	{@algorithmIdentifier.algorithm}))		{@algorithmIdentifier.algorithm}))
	}		}
	Signatures are also used in the CRL list ASN.1 representation from		Signatures are also used in the CRL list ASN.1; the representation
	[RFC5280] below. In an X.509 CRL, a signature is encoded with an		below is equivalent to that in [RFC5280]. In an X.509 CRL, a
	algorithm identifier in the signatureAlgorithm attribute and a		signature is encoded with an algorithm identifier in the
	signatureValue attribute that contains the actual signature.		signatureAlgorithm attribute and a signatureValue attribute that
			contains the actual signature.
	CertificateList ::= SIGNED{ TBSCertList }		CertificateList ::= SIGNED{ TBSCertList }
	The following SIGNATURE-ALGORITHM ASN.1 classes are for ML-DSA-44,		The following SIGNATURE-ALGORITHM ASN.1 classes are for ML-DSA-44,
	ML-DSA-65, and ML-DSA-87:		ML-DSA-65, and ML-DSA-87:
	sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {		sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-ml-dsa-44		IDENTIFIER id-ml-dsa-44
	PARAMS ARE absent		PARAMS ARE absent
	PUBLIC-KEYS { pk-ml-dsa-44 }		PUBLIC-KEYS { pk-ml-dsa-44 }
	skipping to change at line 226 ¶		skipping to change at line 227 ¶
	The identifiers defined in Section 2 can be used as the		The identifiers defined in Section 2 can be used as the
	AlgorithmIdentifier in the signatureAlgorithm field in the sequence		AlgorithmIdentifier in the signatureAlgorithm field in the sequence
	Certificate/CertificateList and in the signature field in the		Certificate/CertificateList and in the signature field in the
	sequence TBSCertificate/TBSCertList in certificates and CRLs,		sequence TBSCertificate/TBSCertList in certificates and CRLs,
	respectively, [RFC5280]. The parameters of these signature		respectively, [RFC5280]. The parameters of these signature
	algorithms MUST be absent, as explained in Section 2. That is, the		algorithms MUST be absent, as explained in Section 2. That is, the
	AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-		AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
	ml-dsa-*, where * is 44, 65, or 87 -- see Section 2.		ml-dsa-*, where * is 44, 65, or 87 -- see Section 2.
	The signatureValue field contains the corresponding ML-DSA signature		The signatureValue field contains the corresponding ML-DSA signature
	computed upon the ASN.1 DER-encoded tbsCertificate/tbsCertList		computed upon the ASN.1 DER-encoded TBSCertificate/TBSCertList
	[RFC5280]. The optional context string (ctx) parameter as defined in		[RFC5280]. The optional context string (ctx) parameter as defined in
	Section 5.2 of [FIPS204] is left to its default value: the empty		Section 5.2 of [FIPS204] is left to its default value: the empty
	string.		string.
	Conforming Certification Authority (CA) implementations MUST specify		Conforming Certification Authority (CA) implementations MUST specify
	the algorithms explicitly by using the OIDs specified in Section 2		the algorithms explicitly by using the OIDs specified in Section 2
	when encoding ML-DSA signatures in certificates and CRLs. Conforming		when encoding ML-DSA signatures in certificates and CRLs. Conforming
	client implementations that process certificates and CRLs using ML-		client implementations that process certificates and CRLs using ML-
	DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA		DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA
	signature values are specified in Section 2.		signature values are specified in Section 2.
	skipping to change at line 481 ¶		skipping to change at line 482 ¶
	For the ASN.1 module in Appendix A, IANA has assigned the following		For the ASN.1 module in Appendix A, IANA has assigned the following
	object identifier (OID) in the "SMI Security for PKIX Module		object identifier (OID) in the "SMI Security for PKIX Module
	Identifier" registry (1.3.6.1.5.5.7.0):		Identifier" registry (1.3.6.1.5.5.7.0):
	+=========+=========================+===========+		+=========+=========================+===========+
	| Decimal | Description | Reference |		| Decimal | Description | Reference |
	+=========+=========================+===========+		+=========+=========================+===========+
	| 119 | id-mod-x509-ml-dsa-2025 | RFC 9881 |		| 119 | id-mod-x509-ml-dsa-2025 | RFC 9881 |
	+---------+-------------------------+-----------+		+---------+-------------------------+-----------+
	Table 1		Table 1: Registered ASN.1 Module
	8. Operational Considerations		8. Operational Considerations
	8.1. Private Key Format		8.1. Private Key Format
	An ML-DSA.KeyGen seed (xi) represents the RECOMMENDED format for		An ML-DSA.KeyGen seed (xi) represents the RECOMMENDED format for
	storing and transmitting ML-DSA private keys. This format is		storing and transmitting ML-DSA private keys. This format is
	explicitly permitted by [FIPS204] as an acceptable representation of		explicitly permitted by [FIPS204] as an acceptable representation of
	a keypair. In particular, generating the seed in one cryptographic		a keypair. In particular, generating the seed in one cryptographic
	module and then importing or exporting it into another cryptographic		module and then importing or exporting it into another cryptographic
	skipping to change at line 566 ¶		skipping to change at line 567 ¶
	prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204].		prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204].
	This means that in the unlikely discovery of a collision attack		This means that in the unlikely discovery of a collision attack
	against the SHA-3 family, an attacker would have to perform a public-		against the SHA-3 family, an attacker would have to perform a public-
	key-specific collision search in order to find message pairs such		key-specific collision search in order to find message pairs such
	that H(tr || m1) = H(tr || m2), because a direct hash collision H(m1)		that H(tr || m1) = H(tr || m2), because a direct hash collision H(m1)
	= H(m2) will not suffice. HashML-DSA removes this enhanced security		= H(m2) will not suffice. HashML-DSA removes this enhanced security
	property. In spite of its lack of targeted collision protection, the		property. In spite of its lack of targeted collision protection, the
	practical security risk of using HashML-DSA in X.509 signatures would		practical security risk of using HashML-DSA in X.509 signatures would
	be immaterial. This is because a hash of the issuing CA's public key		be immaterial. This is because a hash of the issuing CA's public key
	is already included in the Authority Key Identifier (AKI) extension,		is already included in the Authority Key Identifier (AKI) extension,
	which is signed as part of the tbsCertificate structure. Even when		which is signed as part of the TBSCertificate structure. Even when
	it is a SHA-1 hash, general second pre-images against the AKI hash of		it is a SHA-1 hash, general second pre-images against the AKI hash of
	existing issuing CAs would be impractical.		existing issuing CAs would be impractical.
	9. Security Considerations		9. Security Considerations
	The Security Considerations section of [RFC5280] applies to this		The Security Considerations section of [RFC5280] applies to this
	specification as well.		specification as well.
	The ML-DSA signature scheme is strongly unforgeable under chosen		The ML-DSA signature scheme is strongly unforgeable under chosen
	message attacks (SUF-CMA). For the purpose of estimating security		message attacks (SUF-CMA). For the purpose of estimating security
	skipping to change at line 595 ¶		skipping to change at line 596 ¶
	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 cannot 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 681 ¶
	[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/
	<https://ieeexplore.ieee.org/document/9519420>.		archive/2020/1525/20231023:114351>.
	[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 870 ¶		skipping to change at line 871 ¶
	PUBLIC-KEYS { pk-ml-dsa-65 }		PUBLIC-KEYS { pk-ml-dsa-65 }
	SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 }		SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 }
	}		}
	sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {		sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-ml-dsa-87		IDENTIFIER id-ml-dsa-87
	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 3826 ¶		skipping to change at line 3825 ¶
	| in production systems.		| in production systems.
	The following examples demonstrate inconsistent seed and expanded		The following examples demonstrate inconsistent seed and expanded
	private keys.		private keys.
	Three ML-DSA-44-PrivateKey examples of inconsistent seed and expanded		Three ML-DSA-44-PrivateKey examples of inconsistent seed and expanded
	private keys follow:		private keys follow:
	1. The first ML-DSA-PrivateKey example includes the both CHOICE ,		1. The first ML-DSA-PrivateKey example includes the both CHOICE ,
	i.e., both seed and expandedKey are included. The seed and		i.e., both seed and expandedKey are included. The seed and
	expanded values can be checked for inconsistencies.		expandedKey values can be checked for inconsistencies.
	2. The second ML-DSA-PrivateKey example includes only expandedKey.		2. The second ML-DSA-PrivateKey example includes only expandedKey.
	The public key fails to match the tr hash value in the private		The public key fails to match the tr hash value in the private
	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 4046 ¶		skipping to change at line 4046 ¶
	Implementations of ML-DSA using the External μ pre-hashing mode		Implementations of ML-DSA using the External μ pre-hashing mode
	requires the following algorithms, which are modified versions of the		requires the following algorithms, which are modified versions of the
	algorithms presented in [FIPS204]. The nomenclature used here has		algorithms presented in [FIPS204]. The nomenclature used here has
	been modified from the NIST FAQ [FIPS204-ExternalMuFAQ] for clarity.		been modified from the NIST FAQ [FIPS204-ExternalMuFAQ] for clarity.
	Pre-hash operation:		Pre-hash operation:
	Computeμ(pk, M, ctx):		Computeμ(pk, M, ctx):
	# Referred to as 'Externalμ-ML-DSA.Prehash(pk, M, ctx)'		# Referred to as 'ExternalMu-ML-DSA.Prehash(pk, M, ctx)'
	# in the FIPS 204 FAQ.		# in the FIPS 204 FAQ.
	# 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 'ExternalMu-ML-DSA.Sign(sk, mu)'
	# 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
	# 64 bytes.		# 64 bytes.
	end if		end if
	rnd = rand(32) # for the optional deterministic variant,		rnd = rand(32) # for the optional deterministic variant,
	# 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. 19 change blocks.
	51 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.48.