rfc9474v2.txt		rfc9474.txt
	Internet Research Task Force (IRTF) F. Denis		Internet Research Task Force (IRTF) F. Denis
	Request for Comments: 9474 Fastly Inc.		Request for Comments: 9474 Fastly Inc.
	Category: Informational F. Jacobs		Category: Informational F. Jacobs
	ISSN: 2070-1721 Apple Inc.		ISSN: 2070-1721 Apple Inc.
	C. A. Wood		C. A. Wood
	Cloudflare		Cloudflare
	September 2023		October 2023
	RSA Blind Signatures		RSA Blind Signatures
	Abstract		Abstract
	This document specifies an RSA-based blind signature protocol. RSA		This document specifies an RSA-based blind signature protocol. RSA
	blind signatures were first introduced by Chaum for untraceable		blind signatures were first introduced by Chaum for untraceable
	payments. A signature that is output from this protocol can be		payments. A signature that is output from this protocol can be
	verified as an RSA-PSS signature.		verified as an RSA-PSS signature.
	skipping to change at line 137 ¶		skipping to change at line 137 ¶
	"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.
	3. Notation		3. Notation
	The following terms, which describe different protocol operations,		The following terms, which describe different protocol operations,
	are used throughout this document:		are used throughout this document:
	bytes_to_int and int_to_bytes: Convert a byte string to and from a		bytes_to_int and int_to_bytes:
	non-negative integer. bytes_to_int and int_to_bytes are		Convert a byte string to and from a non-negative
	implemented as OS2IP and I2OSP -- as described in [RFC8017] --		integer. bytes_to_int and int_to_bytes are implemented as OS2IP
	respectively. Note that these functions operate on byte strings		and I2OSP -- as described in [RFC8017] -- respectively. Note that
	in big-endian byte order.		these functions operate on byte strings in big-endian byte order.
	random_integer_uniform(M, N): Generate a random, uniformly		random_integer_uniform(M, N):
	distributed integer R between M inclusive and N exclusive, i.e., M		Generate a random, uniformly distributed integer R between M
	<= R < N.		inclusive and N exclusive, i.e., M <= R < N.
	bit_len(n): Compute the minimum number of bits needed to represent		bit_len(n):
	the positive integer n.		Compute the minimum number of bits needed to represent the
			positive integer n.
	inverse_mod(x, n): Compute the multiplicative inverse of x mod n or		inverse_mod(x, n):
	fail if x and n are not co-prime.		Compute the multiplicative inverse of x mod n or fail if x and n
			are not co-prime.
	is_coprime(x, n): Return true if x and n are co-prime, and false		is_coprime(x, n): Return true if x and n are co-prime, and false
	otherwise.		otherwise.
	len(s): The length of a byte string, in bytes.		len(s): The length of a byte string, in bytes.
	random(n): Generate n random bytes using a cryptographically secure		random(n):
	random number generator.		Generate n random bytes using a cryptographically secure random
			number generator.
	concat(x0, ..., xN): Concatenation of byte strings. For example,		concat(x0, ..., xN):
	concat(0x01, 0x0203, 0x040506) = 0x010203040506.		Concatenation of byte strings. For example, concat(0x01, 0x0203,
			0x040506) = 0x010203040506.
	slice(x, i, j): Return bytes in the byte string x starting from		slice(x, i, j): Return bytes in the byte string x starting from
	offset i and ending at offset j, inclusive. For example,		offset i and ending at offset j, inclusive. For example,
	slice(0x010203040506, 1, 5) = 0x0203040506.		slice(0x010203040506, 1, 5) = 0x0203040506.
	4. Blind Signature Protocol		4. Blind Signature Protocol
	The RSA Blind Signature Protocol is a two-party protocol between a		The RSA Blind Signature Protocol is a two-party protocol between a
	client and server where they interact to compute sig = Sign(sk,		client and server where they interact to compute sig = Sign(sk,
	input_msg), where input_msg = Prepare(msg) is a prepared version of		input_msg), where input_msg = Prepare(msg) is a prepared version of
	skipping to change at line 427 ¶		skipping to change at line 431 ¶
	5. RSABSSA Variants		5. RSABSSA Variants
	In this section, we define different named variants of RSABSSA. Each		In this section, we define different named variants of RSABSSA. Each
	variant specifies EMSA-PSS options Hash, MGF, and sLen as defined in		variant specifies EMSA-PSS options Hash, MGF, and sLen as defined in
	Section 9.1.1 of [RFC8017], as well as the type of message		Section 9.1.1 of [RFC8017], as well as the type of message
	preparation function applied (as described in Section 4.1). Each		preparation function applied (as described in Section 4.1). Each
	variant uses the mask generation function 1 (MGF1) defined in		variant uses the mask generation function 1 (MGF1) defined in
	Appendix B.2.1. of [RFC8017]. Future specifications can introduce		Appendix B.2.1. of [RFC8017]. Future specifications can introduce
	other variants as desired. The named variants are as follows:		other variants as desired. The named variants are as follows:
	RSABSSA-SHA384-PSS-Randomized: This named variant uses SHA-384 as		RSABSSA-SHA384-PSS-Randomized:
	the EMSA-PSS Hash option, MGF1 with SHA-384 as the EMSA-PSS MGF		This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
	option, and 48 as the sLen option (salt length); it also uses the		with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS
	randomized preparation function (PrepareRandomize).		sLen option (48-byte salt length); it also uses the randomized
			preparation function (PrepareRandomize).
	RSABSSA-SHA384-PSSZERO-Randomized: This named variant uses SHA-384		RSABSSA-SHA384-PSSZERO-Randomized:
	as the EMSA-PSS Hash option, MGF1 with SHA-384 as the EMSA-PSS MGF		This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
	option, and an empty PSS salt; it also uses the randomized		with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS
			sLen option (0-byte salt length); it also uses the randomized
	preparation function (PrepareRandomize).		preparation function (PrepareRandomize).
	RSABSSA-SHA384-PSS-Deterministic: This named variant uses SHA-384 as		RSABSSA-SHA384-PSS-Deterministic:
	the EMSA-PSS Hash option, MGF1 with SHA-384 as the EMSA-PSS MGF		This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
	option, and 48 as the sLen option (salt length); it also uses the		with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS
	identity preparation function (PrepareIdentity).		sLen option (48-byte salt length); it also uses the identity
			preparation function (PrepareIdentity).
	RSABSSA-SHA384-PSSZERO-Deterministic: This named variant uses		RSABSSA-SHA384-PSSZERO-Deterministic:
	SHA-384 as the EMSA-PSS Hash option, MGF1 with SHA-384 as the		This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
	EMSA-PSS MGF option, and an empty PSS salt; it also uses the		with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS
	identity preparation function (PrepareIdentity). This is the only		sLen option (0-byte salt length); it also uses the identity
	variant that produces deterministic signatures over the client's		preparation function (PrepareIdentity). This is the only variant
	input message msg.		that produces deterministic signatures over the client's input
			message msg.
	The RECOMMENDED variants are RSABSSA-SHA384-PSS-Randomized or		The RECOMMENDED variants are RSABSSA-SHA384-PSS-Randomized or
	RSABSSA-SHA384-PSSZERO-Randomized.		RSABSSA-SHA384-PSSZERO-Randomized.
	Not all named variants can be used interchangeably. In particular,		Not all named variants can be used interchangeably. In particular,
	applications that provide high-entropy input messages can safely use		applications that provide high-entropy input messages can safely use
	named variants without randomized message preparation, as the		named variants without randomized message preparation, as the
	additional message randomization does not offer security advantages.		additional message randomization does not offer security advantages.
	See [Lys22] and Section 7.3 for more information. For all other		See [Lys22] and Section 7.3 for more information. For all other
	applications, the variants that use the randomized preparation		applications, the variants that use the randomized preparation
	skipping to change at line 703 ¶		skipping to change at line 711 ¶
	9.2. Informative References		9.2. Informative References
	[ApplePrivateRelay]		[ApplePrivateRelay]
	"iCloud Private Relay Overview", December 2021,		"iCloud Private Relay Overview", December 2021,
	<https://www.apple.com/icloud/docs/		<https://www.apple.com/icloud/docs/
	iCloud_Private_Relay_Overview_Dec2021.pdf>.		iCloud_Private_Relay_Overview_Dec2021.pdf>.
	[Chaum83] Chaum, D., "Blind Signatures for Untraceable Payments",		[Chaum83] Chaum, D., "Blind Signatures for Untraceable Payments",
	Springer-Verlag, 1998,		Springer-Verlag, 1998,
	<http://sceweb.sce.uhcl.edu/yang/teaching/		<https://sceweb.sce.uhcl.edu/yang/teaching/
	csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF>.		csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF>.
	[DSS] "Digital Signature Standard (DSS)", National Institute of		[DSS] "Digital Signature Standard (DSS)", National Institute of
	Standards and Technology report,		Standards and Technology report,
	DOI 10.6028/nist.fips.186-5, February 2023,		DOI 10.6028/nist.fips.186-5, February 2023,
	<https://doi.org/10.6028/NIST.FIPS.186-5>.		<https://doi.org/10.6028/NIST.FIPS.186-5>.
	[FAULTS] Boneh, D., DeMillo, R. A., and R. J. Lipton, "On the		[FAULTS] Boneh, D., DeMillo, R. A., and R. J. Lipton, "On the
	Importance of Checking Cryptographic Protocols for		Importance of Checking Cryptographic Protocols for
	Faults", Advances in Cryptology - EUROCRYPT '97, pp.		Faults", Advances in Cryptology - EUROCRYPT '97, pp.
	skipping to change at line 754 ¶		skipping to change at line 762 ¶
	[PrettyGoodPhonePrivacy]		[PrettyGoodPhonePrivacy]
	Schmitt, P. and B. Raghavan, "Pretty Good Phone Privacy",		Schmitt, P. and B. Raghavan, "Pretty Good Phone Privacy",
	Proceedings of the 30th USENIX Security Symposium, August		Proceedings of the 30th USENIX Security Symposium, August
	2021, <https://www.usenix.org/conference/usenixsecurity21/		2021, <https://www.usenix.org/conference/usenixsecurity21/
	presentation/schmitt>.		presentation/schmitt>.
	[PRIVACY-PASS]		[PRIVACY-PASS]
	Celi, S., Davidson, A., Valdez, S., and C. A. Wood,		Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
	"Privacy Pass Issuance Protocol", Work in Progress,		"Privacy Pass Issuance Protocol", Work in Progress,
	Internet-Draft, draft-ietf-privacypass-protocol-15, 25		Internet-Draft, draft-ietf-privacypass-protocol-16, 3
	September 2023, <https://datatracker.ietf.org/doc/html/		October 2023, <https://datatracker.ietf.org/doc/html/
	draft-ietf-privacypass-protocol-15>.		draft-ietf-privacypass-protocol-16>.
	[RemoteTimingAttacks]		[RemoteTimingAttacks]
	Brumley, D. and D. Boneh, "Remote Timing Attacks are		Brumley, D. and D. Boneh, "Remote Timing Attacks are
	Practical", Proceedings of the 12th USENIX Security		Practical", Proceedings of the 12th USENIX Security
	Symposium, August 2003,		Symposium, August 2003,
	<https://www.usenix.org/legacy/events/sec03/tech/brumley/		<https://www.usenix.org/legacy/events/sec03/tech/brumley/
	brumley.pdf>.		brumley.pdf>.
	[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional		[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for use in		Algorithms and Identifiers for RSA Cryptography for use in
	skipping to change at line 821 ¶		skipping to change at line 829 ¶
	1999, pp. 154-170, DOI 10.1007/3-540-49162-7_12, October		1999, pp. 154-170, DOI 10.1007/3-540-49162-7_12, October
	1999, <https://link.springer.com/		1999, <https://link.springer.com/
	chapter/10.1007/3-540-49162-7_12>.		chapter/10.1007/3-540-49162-7_12>.
	Appendix A. Test Vectors		Appendix A. Test Vectors
	This section includes test vectors for the blind signature protocol		This section includes test vectors for the blind signature protocol
	defined in Section 4. The following parameters are specified for		defined in Section 4. The following parameters are specified for
	each test vector:		each test vector:
	p, q, n, e, d: RSA private and public key (sk and pk) parameters,		p, q, n, e, d:
	each encoded as a hexadecimal string.		RSA private and public key (sk and pk) parameters, each encoded as
			a hexadecimal string.
	msg: Input message being signed, encoded as a hexadecimal string.		msg:
	The hash is computed using SHA-384.		Input message being signed, encoded as a hexadecimal string. The
			hash is computed using SHA-384.
	msg_prefix: Message randomizer prefix, encoded as a hexadecimal		msg_prefix:
	string. This is only present for variants that use the		Message randomizer prefix, encoded as a hexadecimal string. This
	randomization preparation function.		is only present for variants that use the randomization
			preparation function.
	prepared_msg: The message actually signed. If the variant does not		prepared_msg:
	use the randomization preparation function, this is equal to msg.		The message actually signed. If the variant does not use the
			randomization preparation function, this is equal to msg.
	salt: Randomly generated salt used when computing the signature.		salt:
	The length is either 48 or 0 bytes.		Randomly generated salt used when computing the signature. The
			length is either 48 or 0 bytes.
	encoded_msg: EMSA-PSS encoded message. The mask generation function		encoded_msg:
	is MGF1 with SHA-384.		EMSA-PSS encoded message. The mask generation function is MGF1
			with SHA-384.
	inv: The message blinding inverse, encoded as a hexadecimal string.		inv: The message blinding inverse, encoded as a hexadecimal string.
	blinded_msg, blind_sig: The protocol values exchanged during the		blinded_msg, blind_sig:
	computation, encoded as hexadecimal strings.		The protocol values exchanged during the computation, encoded as
			hexadecimal strings.
	sig: The output message signature.		sig: The output message signature.
	A.1. RSABSSA-SHA384-PSS-Randomized Test Vector		A.1. RSABSSA-SHA384-PSS-Randomized Test Vector
	p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305		p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305
	59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca		59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca
	7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e		7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e
	41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10		41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10
	8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048		8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048
End of changes. 20 change blocks.
	53 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48.