< draft-dew-cfrg-signature-key-blinding-01.txt   draft-dew-cfrg-signature-key-blinding-02.txt >
WG Working Group F. Denis WG Working Group F. Denis
Internet-Draft Fastly Inc. Internet-Draft Fastly Inc.
Intended status: Informational E. Eaton Intended status: Informational E. Eaton
Expires: 8 September 2022 University of Waterloo Expires: 4 November 2022 University of Waterloo
C. A. Wood C. A. Wood
Cloudflare, Inc. Cloudflare, Inc.
7 March 2022 3 May 2022
Key Blinding for Signature Schemes Key Blinding for Signature Schemes
draft-dew-cfrg-signature-key-blinding-01 draft-dew-cfrg-signature-key-blinding-02
Abstract Abstract
This document describes extensions to existing signature schemes for This document describes extensions to existing digital signature
key blinding. This functionality guarantees that a blinded public schemes for key blinding. The core property of signing with key
key and all signatures produced using the blinded key pair are blinding is that a blinded public key and all signatures produced
unlinkable to the unblinded key pair. Moreover, signatures produced using the blinded key pair are independent of the unblinded key pair.
using blinded key pairs are indistinguishable from signatures Moreover, signatures produced using blinded key pairs are
produced using unblinded key pairs. indistinguishable from signatures produced using unblinded key pairs.
This functionality has a variety of applications, including Tor onion
services and privacy-preserving airdrop for bootstrapping
cryptocurrency systems.
About This Document About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://chris- The latest revision of this draft can be found at https://chris-
wood.github.io/draft-dew-cfrg-signature-key-blinding/draft-dew-cfrg- wood.github.io/draft-dew-cfrg-signature-key-blinding/draft-dew-cfrg-
signature-key-blinding.html. Status information for this document signature-key-blinding.html. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-dew-cfrg- may be found at https://datatracker.ietf.org/doc/draft-dew-cfrg-
signature-key-blinding/. signature-key-blinding/.
skipping to change at page 2, line 10 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 September 2022. This Internet-Draft will expire on 4 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Key Blinding . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key Blinding . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Ed25519ph, Ed25519ctx, and Ed25519 . . . . . . . . . . . . . 5 4. Ed25519ph, Ed25519ctx, and Ed25519 . . . . . . . . . . . . . 6
4.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 5 4.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 6
4.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 5 4.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 6
5. Ed448ph and Ed448 . . . . . . . . . . . . . . . . . . . . . . 6 5. Ed448ph and Ed448 . . . . . . . . . . . . . . . . . . . . . . 7
5.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 6 5.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 7
5.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 6 5.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 7
6. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 7 6.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 8
6.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 8 6.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Ed25519 Test Vectors . . . . . . . . . . . . . . . . . . 9 9.1. Ed25519 Test Vectors . . . . . . . . . . . . . . . . . . 10
9.2. ECDSA(P-256, SHA-256) Test Vectors . . . . . . . . . . . 9 9.2. ECDSA(P-384, SHA-384) Test Vectors . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
EdDSA [EDDSA] is a type of Schnorr signature algorithm based on Digital signature schemes allow a signer to sign a message using a
Edwards curves. The specification [RFC8032] describes several private signing key and produce a digital signature such that anyone
variants of EdDSA with parameter sets for the edwards25519 and can verify the digital signature over the message with the public
edwards448 curves as described in [RFC7748]. According to the verification key corresponding to the signing key. Digital signature
specification, private keys are randomly generated seeds, which are schemes typically consist of three functions:
then used to derive scalar elements and their corresponding public
group element for signing and verifying messages, respectively.
Given an EdDSA private and public key pair (sk, pk), any message * KeyGen: A function for generating a private signing key skS and
signed by sk is linkable to pk. One simply checks whether the the corresponding public verification key pkS.
message signature is valid under pk. In some settings, in is useful
to produce signatures with a given key pair (sk, pk) such that the
resulting signature is not linkable to pk without knowledge of a
particular witness r. That is, given pk corresponding to sk, witness
r, and a message signature, one can determine if the signature was
indeed produced using sk. In effect, the witness "blinds" the key
pair associated with a message signature.
This functionality is also possible with other signature schemes, * Sign(skS, msg): A function for signing an input message msg using
including [ECDSA] and some post-quantum signature schemes [ESS21]. a private signing key skS, producing a digital signature sig.
This document describes a modification to the EdDSA key generation * Verify(pkS, msg, sig): A function for verifying the digital
and signing procedures in [RFC8032] to support this blinding signature sig over input message msg against a public verification
operation, referred to as key blinding. It also specifies an key pkS, yielding true if the signature is valid and false
extension to [ECDSA] that enables the same functionality. otherwise.
In some applications, it's useful for a signer to produce digital
signatures using the same long-term private signing key such that a
verifier cannot link any two signatures to the same signer. In other
words, the signature produced is independent of the long-term
private-signing key, and the public verification key for verifying
the signature is independent of the long-term public verification
key. This type of functionality has a number of practical
applications, including, for example, in the Tor onion services
protocol [TORDIRECTORY] and privacy-preserving airdrop for
bootstrapping cryptocurrency systems [AIRDROP]. It is also necessary
for a variant of the Privacy Pass issuance protocol [RATELIMITED].
One way to accomplish this is by signing with a private key which is
a function of the long-term private signing key and a freshly chosen
blinding key, and similarly by producing a public verification key
which is a function of the long-term public verification key and same
blinding key. A signature scheme with this functionality is referred
to as signing with key blinding. A signature scheme with key
blinding extends a basic digital scheme with four new functions:
* BlindKeyGen: A function for generating a private blind key.
* BlindPublicKey(pkS, bk): Blind the public verification key pkS
using the private blinding key bk, yielding a blinded public key
pkR.
* UnblindPublicKey(pkR, bk): Unblind the public verification key pkR
using the private blinding key bk.
* BlindKeySign(skS, bk, msg): Sign a message msg using the private
signing key skS with the private blind key bk.
A signature scheme with key blinding aims to achieve unforgeability
and unlinkability. Informally, unforgeability means that one cannot
produce a valid (message, signature) pair for any blinding key
without access to the private signing key. Similarly, unlinkability
means that one cannot distinguish between two signatures produced
from two separate key signing keys, and two signatures produced from
the same signing key but with different blinding keys.
This document describes extensions to EdDSA [RFC8032] and ECDSA
[ECDSA] to enable signing with key blinding. Security analysis of
these extensions is currently underway; see Section 7 for more
details.
This functionality is also possible with other signature schemes,
including some post-quantum signature schemes [ESS21], though such
extensions are not specified here.
1.1. DISCLAIMER 1.1. DISCLAIMER
This document is a work in progress and is still undergoing security This document is a work in progress and is still undergoing security
analysis. As such, it MUST NOT be used for real world applications. analysis. As such, it MUST NOT be used for real world applications.
See Section 7 for additional information. See Section 7 for additional information.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 29 skipping to change at page 5, line 23
* ModInverse(x, L): Compute the multiplicative inverse of x modulo * ModInverse(x, L): Compute the multiplicative inverse of x modulo
L. L.
In pseudocode descriptions below, integer multiplication of two In pseudocode descriptions below, integer multiplication of two
scalar values is denoted by the * operator. For example, the product scalar values is denoted by the * operator. For example, the product
of two scalars x and y is denoted as x * y. of two scalars x and y is denoted as x * y.
3. Key Blinding 3. Key Blinding
At a high level, a signature scheme with key blinding allows signers At a high level, a signature scheme with key blinding allows signers
to blind their signing key such that any signature produced under the to blind their private signing key such that any signature produced
blinded signing key is unlinkable from the unblinded signing key. with a private signing key and blinding key is independent of the
Similar to the signing key, the blind is also a private key that private signing key. Similar to the signing key, the blinding key is
remains secret. For example, the blind is a 32-byte or 57-byte also a private key that remains secret. For example, the blind is a
random seed for Ed25519 or Ed448 variants, respectively, whereas the 32-byte or 57-byte random seed for Ed25519 or Ed448 variants,
blind for ECDSA over P-256 is a random scalar in the P-256 group. respectively, whereas the blind for ECDSA over P-256 is a random
scalar in the P-256 group. Key blinding introduces four new
functionalities for the signature scheme:
Key blinding introduces three new functionalities for the signature * BlindKeyGen: A function for generating a private blind key.
scheme:
* BlindPublicKey(pkS, skB): Blind the public key pkS using the * BlindPublicKey(pkS, bk): Blind the public verification key pkS
private key skB. using the private blinding key bk, yielding a blinded public key
pkR.
* UnblindPublicKey(pkM, skB): Unblind the public key pkM using the * UnblindPublicKey(pkR, bk): Unblind the public verification key pkR
private key skB. using the private blinding key bk.
* BlindKeySign(skS, skB, msg): Sign a message msg using the private * BlindKeySign(skS, bk, msg): Sign a message msg using the private
key skS with the private blind skB. signing key skS with the private blind key bk.
Correctness requires the following equivalence to hold: For a given bk produced from BlindKeyGen, correctness requires the
following equivalence to hold:
UnblindPublicKey(BlindPublicKey(pkS, bk), bk) = pkS
UnblindPublicKey(BlindPublicKey(pkS, skB), skB) = pkS
Security requires that signatures produced using BlindKeySign are Security requires that signatures produced using BlindKeySign are
unlinkable from signatures produced using the standard signature unlinkable from signatures produced using the standard signature
generation function with the same private key. generation function with the same private key.
4. Ed25519ph, Ed25519ctx, and Ed25519 4. Ed25519ph, Ed25519ctx, and Ed25519
This section describes implementations of BlindPublicKey, This section describes implementations of BlindPublicKey,
UnblindPublicKey, and BlindKeySign as modifications of routines in UnblindPublicKey, and BlindKeySign as modifications of routines in
[RFC8032], Section 5.1. [RFC8032], Section 5.1. BlindKeyGen invokes the key generation
routine specified in [RFC8032], Section 5.1.5 and outputs only the
private key.
4.1. BlindPublicKey and UnblindPublicKey 4.1. BlindPublicKey and UnblindPublicKey
BlindPublicKey transforms a private blind skB into a scalar for the BlindPublicKey transforms a private blind bk into a scalar for the
edwards25519 group and then multiplies the target key by this scalar. edwards25519 group and then multiplies the target key by this scalar.
UnblindPublicKey performs essentially the same steps except that it UnblindPublicKey performs essentially the same steps except that it
multiplies the target public key by the multiplicative inverse of the multiplies the target public key by the multiplicative inverse of the
scalar, where the inverse is computed using the order of the group L, scalar, where the inverse is computed using the order of the group L,
described in [RFC8032], Section 5.1. described in [RFC8032], Section 5.1.
More specifically, BlindPublicKey(pk, skB) works as follows. More specifically, BlindPublicKey(pk, bk) works as follows.
1. Hash the 32-byte private key skB using SHA-512, storing the 1. Hash the 32-byte private key bk using SHA-512, storing the digest
digest in a 64-octet large buffer, denoted h. Only the lower 32 in a 64-octet large buffer, denoted b. Interpret the lower 32
bytes are used for generating the public key. bytes buffer as a little-endian integer, forming a secret scalar
s. Note that this explicitly skips the buffer pruning step in
[RFC8032], Section 5.1.
2. Interpret the buffer as a little-endian integer, forming a secret 2. Perform a scalar multiplication ScalarMult(pk, s), and output the
scalar s. Note that this explicitly skips the buffer pruning encoding of the resulting point as the public key.
step in [RFC8032], Section 5.1. Perform a scalar multiplication
ScalarMult(pk, s), and output the encoding of the resulting point
as the public key.
UnblindPublicKey(pkM, skB) works as follows. UnblindPublicKey(pkR, bk) works as follows.
1. Compute the secret scalar s from skB as in BlindPublicKey. 1. Compute the secret scalar s from bk as in BlindPublicKey.
2. Compute the sInv = ModInverse(s, L), where L is as defined in 2. Compute the sInv = ModInverse(s, L), where L is as defined in
[RFC8032], Section 5.1. [RFC8032], Section 5.1.
3. Perform a scalar multiplication ScalarMult(pk, sInv), and output 3. Perform a scalar multiplication ScalarMult(pk, sInv), and output
the encoding of the resulting point as the public key. the encoding of the resulting point as the public key.
4.2. BlindKeySign 4.2. BlindKeySign
BlindKeySign transforms a private key skB into a scalar for the BlindKeySign transforms a private key bk into a scalar for the
edwards25519 group and a message prefix to blind both the signing edwards25519 group and a message prefix to blind both the signing
scalar and the prefix of the message used in the signature generation scalar and the prefix of the message used in the signature generation
routine. routine.
More specifically, BlindKeySign(skS, skB, msg) works as follows: More specifically, BlindKeySign(skS, bk, msg) works as follows:
1. Hash the private key skS, 32 octets, using SHA-512. Let h denote 1. Hash the private key skS, 32 octets, using SHA-512. Let h denote
the resulting digest. Construct the secret scalar s1 from the the resulting digest. Construct the secret scalar s1 from the
first half of the digest, and the corresponding public key A1, as first half of the digest, and the corresponding public key A1, as
described in [RFC8032], Section 5.1.5. Let prefix1 denote the described in [RFC8032], Section 5.1.5. Let prefix1 denote the
second half of the hash digest, h[32],...,h[63]. second half of the hash digest, h[32],...,h[63].
2. Hash the 32-byte private key skB using SHA-512, storing the 2. Hash the 32-byte private key bk using SHA-512, storing the digest
digest in a 64-octet large buffer, denoted b. Interpret the in a 64-octet large buffer, denoted b. Interpret the lower 32
lower 32 bytes buffer as a little-endian integer, forming a bytes buffer as a little-endian integer, forming a secret scalar
secret scalar s2. Let prefix2 denote the second half of the hash s2. Let prefix2 denote the second half of the hash digest,
digest, b[32],...,b[63]. b[32],...,b[63].
3. Compute the signing scalar s = s1 * s2 (mod L) and the signing 3. Compute the signing scalar s = s1 * s2 (mod L) and the signing
public key A = ScalarMult(G, s). public key A = ScalarMult(G, s).
4. Compute the signing prefix as concat(prefix1, prefix2). 4. Compute the signing prefix as concat(prefix1, prefix2).
5. Run the rest of the Sign procedure in [RFC8032], Section 5.1.6 5. Run the rest of the Sign procedure in [RFC8032], Section 5.1.6
from step (2) onwards using the modified scalar s, public key A, from step (2) onwards using the modified scalar s, public key A,
and string prefix. and string prefix.
5. Ed448ph and Ed448 5. Ed448ph and Ed448
This section describes implementations of BlindPublicKey, This section describes implementations of BlindPublicKey,
UnblindPublicKey, and BlindKeySign as modifications of routines in UnblindPublicKey, and BlindKeySign as modifications of routines in
[RFC8032], Section 5.2. [RFC8032], Section 5.2. BlindKeyGen invokes the key generation
routine specified in [RFC8032], Section 5.1.5 and outputs only the
private key.
5.1. BlindPublicKey and UnblindPublicKey 5.1. BlindPublicKey and UnblindPublicKey
BlindPublicKey and UnblindPublicKey for Ed448ph and Ed448 are BlindPublicKey and UnblindPublicKey for Ed448ph and Ed448 are
implemented just as these routines are for Ed25519ph, Ed25519ctx, and implemented just as these routines are for Ed25519ph, Ed25519ctx, and
Ed25519, except that SHAKE256 is used instead of SHA-512 for hashing Ed25519, except that SHAKE256 is used instead of SHA-512 for hashing
the secret blind to a 114-byte buffer and the order of the edwards448 the secret blind to a 114-byte buffer (and using the lower 57-bytes
group L is as defined in [RFC8032], Section 5.2.1. for the secret), and the order of the edwards448 group L is as
defined in [RFC8032], Section 5.2.1.
5.2. BlindKeySign 5.2. BlindKeySign
BlindKeySign for Ed448ph and Ed448 is implemented just as this BlindKeySign for Ed448ph and Ed448 is implemented just as this
routine for Ed25519ph, Ed25519ctx, and Ed25519, except in how the routine for Ed25519ph, Ed25519ctx, and Ed25519, except in how the
scalars (s1, s2), public keys (A1, A2), and message strings (prefix1, scalars (s1, s2), public keys (A1, A2), and message strings (prefix1,
prefix2) are computed. More specifically, BlindKeySign(skS, skB, prefix2) are computed. More specifically, BlindKeySign(skS, bk, msg)
msg) works as follows: works as follows:
1. Hash the private key skS, 57 octets, using SHAKE256(skS, 117). 1. Hash the private key skS, 57 octets, using SHAKE256(skS, 117).
Let h denote the resulting digest. Construct the secret scalar Let h denote the resulting digest. Construct the secret scalar
s1 from the first half of the digest, and the corresponding s1 from the first half of the digest, and the corresponding
public key A1, as described in [RFC8032], Section 5.2.5. Let public key A1, as described in [RFC8032], Section 5.2.5. Let
prefix1 denote the second half of the hash digest, prefix1 denote the second half of the hash digest,
h[57],...,h[113]. h[57],...,h[113].
2. Perform the same routine to transform the secret blind skB into a 2. Perform the same routine to transform the secret blind bk into a
secret scalar s2, public key A2, and prefix2. secret scalar s2, public key A2, and prefix2.
3. Compute the signing scalar s = s1 * s2 (mod L) and the signing 3. Compute the signing scalar s = s1 * s2 (mod L) and the signing
public key A = ScalarMult(A1, s2). public key A = ScalarMult(A1, s2).
4. Compute the signing prefix as concat(prefix1, prefix2). 4. Compute the signing prefix as concat(prefix1, prefix2).
5. Run the rest of the Sign procedure in [RFC8032], Section 5.2.6 5. Run the rest of the Sign procedure in [RFC8032], Section 5.2.6
from step (2) onwards using the modified scalar s, public key A, from step (2) onwards using the modified scalar s, public key A,
and string prefix. and string prefix.
6. ECDSA 6. ECDSA
[[DISCLAIMNER: Multiplicative blinding for ECDSA is known to be NOT [[DISCLAIMER: Multiplicative blinding for ECDSA is known to be NOT be
be SUF-CMA-secure in the presence of an adversary that controls the SUF-CMA-secure in the presence of an adversary that controls the
blinding value. [MSMHI15] describes this in the context of related- blinding value. [MSMHI15] describes this in the context of related-
key attacks. This variant may likely be removed in followup versions key attacks. This variant may likely be removed in followup versions
of this document based on further analysis.]] of this document based on further analysis.]]
This section describes implementations of BlindPublicKey, This section describes implementations of BlindPublicKey,
UnblindPublicKey, and BlindKeySign as functions implemented on top of UnblindPublicKey, and BlindKeySign as functions implemented on top of
an existing [ECDSA] implementation. In the descriptions below, let p an existing [ECDSA] implementation. BlindKeyGen invokes the key
be the order of the corresponding elliptic curve group used for generation routine specified in [ECDSA] and outputs only the private
ECDSA. For example, for P-256, p = 115792089210356248762697446949407 key. In the descriptions below, let p be the order of the
573529996955224135760342422259061068512044369. corresponding elliptic curve group used for ECDSA. For example, for
P-256, p = 1157920892103562487626974469494075735299969552241357603424
22259061068512044369.
6.1. BlindPublicKey and UnblindPublicKey 6.1. BlindPublicKey and UnblindPublicKey
BlindPublicKey multiplies the public key pkS by an augmented private BlindPublicKey multiplies the public key pkS by an augmented private
key skB yielding a new public key pkR. UnblindPublicKey inverts this key bk yielding a new public key pkR. UnblindPublicKey inverts this
process by multiplying the input public key by the multiplicative process by multiplying the input public key by the multiplicative
inverse of the augmented skB. Augmentation here maps the private key inverse of the augmented bk. Augmentation here maps the private key
skB to another scalar using hash_to_field as defined in Section 5 of bk to another scalar using hash_to_field as defined in Section 5 of
[H2C], with DST set to "ECDSA Key Blind", L set to the value [H2C], with DST set to "ECDSA Key Blind", L set to the value
corresponding to the target curve, e.g., 48 for P-256 and 72 for corresponding to the target curve, e.g., 48 for P-256 and 72 for
P-384, expand_message_xmd with a hash function matching that used for P-384, expand_message_xmd with a hash function matching that used for
the corresponding digital signature algorithm, and prime modulus the corresponding digital signature algorithm, and prime modulus
equal to the order p of the corresponding curve. Letting equal to the order p of the corresponding curve. Letting
HashToScalar denote this augmentation process, BlindPublicKey and HashToScalar denote this augmentation process, BlindPublicKey and
UnblindPublicKey are then implemented as follows: UnblindPublicKey are then implemented as follows:
BlindPublicKey(pk, skB) = ScalarMult(pk, HashToScalar(skB)) BlindPublicKey(pk, bk) = ScalarMult(pk, HashToScalar(bk))
UnblindPublicKey(pk, skB) = ScalarMult(pk, ModInverse(HashToScalar(skB), p)) UnblindPublicKey(pk, bk) = ScalarMult(pk, ModInverse(HashToScalar(bk), p))
6.2. BlindKeySign 6.2. BlindKeySign
BlindKeySign transforms the signing key skS by the private key skB BlindKeySign transforms the signing key skS by the private key bk
into a new signing key, skR, and then invokes the existing ECDSA into a new signing key, skR, and then invokes the existing ECDSA
signing procedure. More specifically, skR = skS * HashToScalar(skB) signing procedure. More specifically, skR = skS * HashToScalar(bk)
(mod p). (mod p).
7. Security Considerations 7. Security Considerations
The signature scheme extensions in this document aim to achieve The signature scheme extensions in this document aim to achieve
unforgeability and unlinkability. Informally, unforgeability means unforgeability and unlinkability. Informally, unforgeability means
that one cannot produce a valid (message, signature) pair for any that one cannot produce a valid (message, signature) pair for any
blinding key without access to the private signing key. Similarly, blinding key without access to the private signing key. Similarly,
unlinkability means that one cannot distinguish between two unlinkability means that one cannot distinguish between two
signatures produced from two separate key signing keys, and two signatures produced from two separate key signing keys, and two
skipping to change at page 8, line 36 skipping to change at page 9, line 42
ensure this is compliant with the signature algorithm described in ensure this is compliant with the signature algorithm described in
[RFC8032]. [RFC8032].
The constructions in this document assume that both the signing and The constructions in this document assume that both the signing and
blinding keys are private, and, as such, not controlled by an blinding keys are private, and, as such, not controlled by an
attacker. [MSMHI15] demonstrate that ECDSA with attacker-controlled attacker. [MSMHI15] demonstrate that ECDSA with attacker-controlled
multiplicative blinding for producing related keys can be abused to multiplicative blinding for producing related keys can be abused to
produce forgeries. In particular, if an attacker can control the produce forgeries. In particular, if an attacker can control the
private blinding key used in BlindKeySign, they can construct a private blinding key used in BlindKeySign, they can construct a
forgery over a different message that validates under a different forgery over a different message that validates under a different
public key. Further analysis is needed to determine whether or not public key. One mitigation to this problem is to change BlindKeySign
it is safe to keep this functionality in the specification given this such that the signature is computed over the input message as well as
problem. the blind public key. However, this would require verifiers to treat
both the blind public key and message as input to their verification
interface. The construction in Section 6 does not require this
change. However, further analysis is needed to determine whether or
not this construction is safe.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Test Vectors 9. Test Vectors
This section contains test vectors for a subset of the signature This section contains test vectors for a subset of the signature
schemes covered in this document. schemes covered in this document.
9.1. Ed25519 Test Vectors 9.1. Ed25519 Test Vectors
This section contains test vectors for Ed25519 as described in This section contains test vectors for Ed25519 as described in
[RFC8032]. Each test vector lists the private key and blind seeds, [RFC8032]. Each test vector lists the private key and blind seeds,
denoted skS and skB and encoded as hexadecimal strings, along with denoted skS and bk and encoded as hexadecimal strings, along with the
their corresponding public keys pkS and pkB encoded has hexadecimal public key pkS corresponding to skS encoded has hexadecimal strings
strings according to [RFC8032], Section 5.1.2. Each test vector also according to [RFC8032], Section 5.1.2. Each test vector also
includes the blinded public key pkR computed from skS and skB, includes the blinded public key pkR computed from skS and bk, denoted
denoted pkR and encoded has a hexadecimal string. Finally, each pkR and encoded has a hexadecimal string. Finally, each vector
vector includes the message and signature values, each encoded as includes the message and signature values, each encoded as
hexadecimal strings. hexadecimal strings.
// Randomly generated private key and blind seed // Randomly generated private key and blind seed
skS: 875532ab039b0a154161c284e19c74afa28d5bf5454e99284bbcffaa71eebf45 skS: 875532ab039b0a154161c284e19c74afa28d5bf5454e99284bbcffaa71eebf45
pkS: 3b5983605b277cd44918410eb246bb52d83adfc806ccaa91a60b5b2011bc5973 pkS: 3b5983605b277cd44918410eb246bb52d83adfc806ccaa91a60b5b2011bc5973
skB: c461e8595f0ac41d374f878613206704978115a226f60470ffd566e9e6ae73bf bk: c461e8595f0ac41d374f878613206704978115a226f60470ffd566e9e6ae73bf
pkB: 0de25ad2fc6c8d2fdacd2feb85d4f00cbe33a63a5b0939a608aeb5450990ccf6
pkR: e52bbb204e72a816854ac82c7e244e13a8fcc3217cfdeb90c8a5a927e741a20f pkR: e52bbb204e72a816854ac82c7e244e13a8fcc3217cfdeb90c8a5a927e741a20f
message: 68656c6c6f20776f726c64 message: 68656c6c6f20776f726c64
signature: f35d2027f14250c07b3b353359362ec31e13076a547c749a981d0135fce06 signature: f35d2027f14250c07b3b353359362ec31e13076a547c749a981d0135fce06
7a361ad6522849e6ed9f61d93b0f76428129b9eb3f9c3cd0bfa1bc2a086a5eebd09 7a361ad6522849e6ed9f61d93b0f76428129b9eb3f9c3cd0bfa1bc2a086a5eebd09
// Randomly generated private key seed and zero blind seed // Randomly generated private key seed and zero blind seed
skS: f3348942e77a83943a6330d372e7531bb52203c2163a728038388ea110d1c871 skS: f3348942e77a83943a6330d372e7531bb52203c2163a728038388ea110d1c871
pkS: ada4f42be4b8fa93ddc7b41ca434239a940b4b18d314fe04d5be0b317a861ddf pkS: ada4f42be4b8fa93ddc7b41ca434239a940b4b18d314fe04d5be0b317a861ddf
skB: 0000000000000000000000000000000000000000000000000000000000000000 bk: 0000000000000000000000000000000000000000000000000000000000000000
pkB: 3b6a27bcceb6a42d62a3a8d02a6f0d73653215771de243a63ac048a18b59da29
pkR: 7b8dcabbdfce4f8ad57f38f014abc4a51ac051a4b77b345da45ee2725d9327d0 pkR: 7b8dcabbdfce4f8ad57f38f014abc4a51ac051a4b77b345da45ee2725d9327d0
message: 68656c6c6f20776f726c64 message: 68656c6c6f20776f726c64
signature: b38b9d67cb4182e91a86b2eb0591e04c10471c1866202dd1b3b076fb86a61 signature: b38b9d67cb4182e91a86b2eb0591e04c10471c1866202dd1b3b076fb86a61
c7c4ab5d626e5c5d547a584ca85d44839c13f6c976ece0dcba53d82601e6737a400 c7c4ab5d626e5c5d547a584ca85d44839c13f6c976ece0dcba53d82601e6737a400
9.2. ECDSA(P-256, SHA-256) Test Vectors 9.2. ECDSA(P-384, SHA-384) Test Vectors
This section contains test vectors for ECDSA with P-256 and SHA-256, This section contains test vectors for ECDSA with P-384 and SHA-384,
as described in [ECDSA]. Each test vector lists the signing and as described in [ECDSA]. Each test vector lists the signing and
blinding keys, denoted skS and skB, each serialized as a big-endian blinding keys, denoted skS and bk, each serialized as a big-endian
integers and encoded as hexadecimal strings. Each test vector also integers and encoded as hexadecimal strings. Each test vector also
lists the unblinded and blinded public keys, denoted pkS and pkB and blinded public key pkR, encoded as compressed elliptic curve points
encoded as compressed elliptic curve points according to [ECDSA]. according to [ECDSA]. Finally, each vector lists message and
Finally, each vector lists message and signature values, where the signature values, where the message is encoded as a hexadecimal
message is encoded as a hexadecimal string, and the signature value string, and the signature value is serialized as the concatenation of
is serialized as the concatenation of scalars (r, s) and encoded as a scalars (r, s) and encoded as a hexadecimal string.
hexadecimal string.
// Randomly generated signing and blind private keys // Randomly generated signing and blind private keys
skS: fb577883a7d5806392cc24433485716a663c3390050dd69f970340442ddfadf5f96 skS: 0e1e4fcc2726e36c5a24be3d30dc6f52d61e6614f5c57a1ec7b829d8adb7c85f456
9f96119b9674d717231b3440ee790 c30c652d9cd1653cef4ce4da9008d
pkS: 02c220ad8c512bb91ab8636c1d4ad8ad322d46786cb89c979335f871e017ced191c pkS: 03c66e61f5e12c35568928d9a0ffbc145ee9679e17afea3fba899ed3f878f9e82a8
67cb94a584d866e9e24cfca90dd4a45 859ce784d9ff43fea2bc8e726468dd3
skB: be45d7118e851486e201b720b1c101d4df4dc68a868a720397eb91428dcf2da4da4 bk: 865b6b7fc146d0f488854932c93128c3ab3572b7137c4682cb28a2d55f7598df467
c50f8ae6b0885af4d2e1801f9348a e890984a687b22c8bc60a986f6a28
pkB: 0313ae8964beca953c0db3c936a49de6c34ad198c2d5aaa7ada46b44a6742584587 pkR: 038defb9b698b91ee7f3985e54b57b519be237ced2f6f79408558ff7485bf2d60a2
1a9f87554dcbb2a75a7b7af7b324b08 4dc986b9145e422ea765b56de7c5956
pkR: 02f7741b9291001bd42f9aef9e99c010f1f69b1dfe115a95309fe81ca1f68e2ffaa
3dfc131e47752023537be2c3526d331
message: 68656c6c6f20776f726c64 message: 68656c6c6f20776f726c64
signature: bd887d5e74742ce7e3ee42794b38f90afc8773bcdab84f8148f59a0b1006c signature: 5e5643a8c22b274ec5f776e63ed23ff182c8c87642e35bd5a5f7455ae1a19
ab6bd6111052f6ddd2e3c9ed5db6e46c5e9fbb850091cb30bf70e5e11412556d7c1265f0 a9956795df33e2f8b30150904ef6ba5e7ee4f18cef026f594b4d21fc157552ce3cf6d7ef
40ae1ff7c77a7196239058c51b311cc5a3038234c6bbba79bc9b53c148f c3226b8d8194fc93df1c7f5facafc96daab7c5a0d840fbd3b9342f2ddad
10. References 10. References
10.1. Normative References 10.1. Normative References
[ECDSA] American National Standards Institute, "Public Key [ECDSA] American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry - The Cryptography for the Financial Services Industry - The
Elliptic Curve Digital Signature Algorithm (ECDSA)", Elliptic Curve Digital Signature Algorithm (ECDSA)",
ANSI ANS X9.62-2005, November 2005. ANSI ANS X9.62-2005, November 2005.
skipping to change at page 10, line 46 skipping to change at page 11, line 46
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>. <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.2. Informative References 10.2. Informative References
[EDDSA] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. [AIRDROP] Wahby, R. S., Boneh, D., Jeffrey, C., and J. Poon, "An
Yang, "High-speed high-security signatures", Journal of airdrop that preserves recipient privacy", n.d.,
Cryptographic Engineering Vol. 2, pp. 77-89, <https://eprint.iacr.org/2020/676.pdf>.
DOI 10.1007/s13389-012-0027-1, August 2012,
<https://doi.org/10.1007/s13389-012-0027-1>.
[ESS21] Eaton, E., Stebila, D., and R. Stracovsky, "Post-Quantum [ESS21] Eaton, E., Stebila, D., and R. Stracovsky, "Post-Quantum
Key-Blinding for Authentication in Anonymity Networks", Key-Blinding for Authentication in Anonymity Networks",
2021, <https://eprint.iacr.org/2021/963>. 2021, <https://eprint.iacr.org/2021/963>.
[H2C] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., [H2C] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
and C. A. Wood, "Hashing to Elliptic Curves", Work in and C. A. Wood, "Hashing to Elliptic Curves", Work in
Progress, Internet-Draft, draft-irtf-cfrg-hash-to-curve- Progress, Internet-Draft, draft-irtf-cfrg-hash-to-curve-
14, 18 February 2022, 14, 18 February 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
hash-to-curve-14>. hash-to-curve-14>.
[MSMHI15] Morita, H., Schuldt, J., Matsuda, T., Hanaoka, G., and T. [MSMHI15] Morita, H., Schuldt, J., Matsuda, T., Hanaoka, G., and T.
Iwata, "On the Security of the Schnorr Signature Scheme Iwata, "On the Security of the Schnorr Signature Scheme
and DSA Against Related-Key Attacks", Information Security and DSA Against Related-Key Attacks", Information Security
and Cryptology - ICISC 2015 pp. 20-35, and Cryptology - ICISC 2015 pp. 20-35,
DOI 10.1007/978-3-319-30840-1_2, 2016, DOI 10.1007/978-3-319-30840-1_2, 2016,
<https://doi.org/10.1007/978-3-319-30840-1_2>. <https://doi.org/10.1007/978-3-319-30840-1_2>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RATELIMITED]
for Security", RFC 7748, DOI 10.17487/RFC7748, January Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and
2016, <https://www.rfc-editor.org/rfc/rfc7748>. C. A. Wood, "Rate-Limited Token Issuance Protocol", Work
in Progress, Internet-Draft, draft-privacypass-rate-limit-
tokens-02, 2 May 2022,
<https://datatracker.ietf.org/doc/html/draft-privacypass-
rate-limit-tokens-02>.
[TORBLINDING] [TORBLINDING]
Hopper, N., "Proving Security of Tor’s Hidden Service Hopper, N., "Proving Security of Tor’s Hidden Service
Identity Blinding Protocol", 2013, Identity Blinding Protocol", 2013,
<https://www-users.cse.umn.edu/~hoppernj/basic-proof.pdf>. <https://www-users.cse.umn.edu/~hoppernj/basic-proof.pdf>.
[TORDIRECTORY]
"Tor directory protocol, version 3", n.d.,
<https://gitweb.torproject.org/torspec.git/tree/dir-
spec.txt>.
Acknowledgments Acknowledgments
The authors would like to thank Dennis Jackson for helpful The authors would like to thank Dennis Jackson for helpful
discussions that informed the development of this draft. discussions that informed the development of this draft.
Authors' Addresses Authors' Addresses
Frank Denis Frank Denis
Fastly Inc. Fastly Inc.
475 Brannan St 475 Brannan St
 End of changes. 51 change blocks. 
152 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/