]>
Key Blinding for Signature Schemes
Fastly Inc.
475 Brannan St
San Francisco
United States of America
fde@00f.net
University of Waterloo
200 University Av West
Waterloo
Canada
ted@eeaton.ca
Cloudflare, Inc.
101 Townsend St
San Francisco
United States of America
caw@heapingbits.net
AREA
WG Working Group
InternetDraft
This document describes extensions to existing signature schemes
for key blinding. This functionality guarantees that a blinded public key and
all signatures produced using the blinded key pair are unlinkable to the
unblinded key pair. Moreover, signatures produced using blinded key pairs
are indistinguishable from signatures produced using unblinded key pairs.
About This Document
The latest revision of this draft can be found at .
Status information for this document may be found at .
Discussion of this document takes place on the
CFRG Working Group mailing list (),
which is archived at .
Source for this draft and an issue tracker can be found at
.
Introduction
EdDSA is a type of Schnorr signature algorithm
based on Edwards curves. The specification describes several variants of
EdDSA with parameter sets for the edwards25519 and edwards448 curves as described in
. According to the specification, private keys are randomly generated
seeds, which are 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 signed by sk is
linkable to pk. One simply checks whether the 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, including
and some postquantum signature schemes .
This document describes a modification to the EdDSA key generation and signing
procedures in to support this blinding operation, referred to as key
blinding. It also specifies an extension to that enables the same
functionality.
DISCLAIMER
This document is a work in progress and is still undergoing security analysis.
As such, it MUST NOT be used for real world applications. See
for additional information.
Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
The following terms are used throughout this document to describe the blinding modification.

G: The standard base point.

sk: A signature scheme private key. For EdDSA, this is a a randomly generated
private seed of length 32 bytes or 57 bytes according to
or , respectively. For , sk is a random scalar
in the primeorder elliptic curve group.

pk(sk): The public key corresponding to the private key sk.

concat(x0, ..., xN): Concatenation of byte strings.
concat(0x01, 0x0203, 0x040506) = 0x010203040506.
 ScalarMult(pk, k): Multiply the public key pk by scalar k, producing a new
public key as a result.
 ModInverse(x, L): Compute the multiplicative inverse of x modulo L.
In pseudocode descriptions below, integer multiplication of two scalar values is denoted
by the * operator. For example, the product of two scalars x and y is denoted as x * y.
Key Blinding
At a high level, a signature scheme with key blinding allows signers to blind their
signing key such that any signature produced under the blinded signing key is unlinkable
from the unblinded signing key. Similar to the signing key, the blind is also a private
key that remains secret. For example, the blind is a 32byte or 57byte random seed for
Ed25519 or Ed448 variants, respectively, whereas the blind for ECDSA over P256 is
a random scalar in the P256 group.
Key blinding introduces three new functionalities for the signature scheme:
 BlindPublicKey(pkS, skB): Blind the public key pkS using the private key skB.
 UnblindPublicKey(pkM, skB): Unblind the public key pkM using the private key skB.
 BlindKeySign(skS, skB, msg): Sign a message msg using the private key skS with the private
blind skB.
Correctness requires the following equivalence to hold:
Security requires that signatures produced using BlindKeySign are unlinkable from
signatures produced using the standard signature generation function with the same
private key.
Ed25519ph, Ed25519ctx, and Ed25519
This section describes implementations of BlindPublicKey, UnblindPublicKey, and BlindKeySign as
modifications of routines in .
BlindPublicKey and UnblindPublicKey
BlindPublicKey transforms a private blind skB into a scalar for the edwards25519 group
and then multiplies the target key by this scalar. UnblindPublicKey performs essentially
the same steps except that it multiplies the target public key by the multiplicative
inverse of the scalar, where the inverse is computed using the order of the group L,
described in .
More specifically, BlindPublicKey(pk, skB) works as follows.
 Hash the 32byte private key skB using SHA512, storing the digest in a 64octet
large buffer, denoted h. Only the lower 32 bytes are used for generating the public key.
 Interpret the buffer as a littleendian integer, forming a secret scalar s. Note that this
explicitly skips the buffer pruning step in . 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.
 Compute the secret scalar s from skB as in BlindPublicKey.
 Compute the sInv = ModInverse(s, L), where L is as defined in .
 Perform a scalar multiplication ScalarMult(pk, sInv), and output the encoding
of the resulting point as the public key.
BlindKeySign
BlindKeySign transforms a private key skB into a scalar for the edwards25519 group and a
message prefix to blind both the signing scalar and the prefix of the message used
in the signature generation routine.
More specifically, BlindKeySign(skS, skB, msg) works as follows:
 Hash the private key skS, 32 octets, using SHA512. Let h denote the
resulting digest. Construct the secret scalar s1 from the first
half of the digest, and the corresponding public key A1, as
described in . Let prefix1 denote the second
half of the hash digest, h[32],...,h[63].
 Hash the 32byte private key skB using SHA512, storing the digest in a 64octet
large buffer, denoted b. Interpret the lower 32 bytes buffer as a littleendian
integer, forming a secret scalar s2. Let prefix2 denote the second half of
the hash digest, b[32],...,b[63].
 Compute the signing scalar s = s1 * s2 (mod L) and the signing public key A = ScalarMult(G, s).
 Compute the signing prefix as concat(prefix1, prefix2).
 Run the rest of the Sign procedure in from step (2) onwards
using the modified scalar s, public key A, and string prefix.
Ed448ph and Ed448
This section describes implementations of BlindPublicKey, UnblindPublicKey, and BlindKeySign as
modifications of routines in .
BlindPublicKey and UnblindPublicKey
BlindPublicKey and UnblindPublicKey for Ed448ph and Ed448 are implemented just as these
routines are for Ed25519ph, Ed25519ctx, and Ed25519, except that SHAKE256 is used instead
of SHA512 for hashing the secret blind to a 114byte buffer and the order of the edwards448
group L is as defined in .
BlindKeySign
BlindKeySign for Ed448ph and Ed448 is implemented just as this routine for Ed25519ph,
Ed25519ctx, and Ed25519, except in how the scalars (s1, s2), public keys (A1, A2),
and message strings (prefix1, prefix2) are computed. More specifically,
BlindKeySign(skS, skB, msg) works as follows:
 Hash the private key skS, 57 octets, using SHAKE256(skS, 117). Let h denote the
resulting digest. Construct the secret scalar s1 from the first
half of the digest, and the corresponding public key A1, as
described in . Let prefix1 denote the second
half of the hash digest, h[57],...,h[113].
 Perform the same routine to transform the secret blind skB into a secret
scalar s2, public key A2, and prefix2.
 Compute the signing scalar s = s1 * s2 (mod L) and the signing public key A = ScalarMult(A1, s2).
 Compute the signing prefix as concat(prefix1, prefix2).
 Run the rest of the Sign procedure in from step (2) onwards
using the modified scalar s, public key A, and string prefix.
ECDSA
[[DISCLAIMNER: Multiplicative blinding for ECDSA is known to be NOT be SUFCMAsecure in the presence of an adversary that controls the blinding value. describes this in the context of relatedkey attacks. This variant may likely be removed in followup versions of this document based on further analysis.]]
This section describes implementations of BlindPublicKey, UnblindPublicKey, and BlindKeySign as
functions implemented on top of an existing implementation. In the descriptions below,
let p be the order of the corresponding elliptic curve group used for ECDSA. For example, for
P256, p = 115792089210356248762697446949407573529996955224135760342422259061068512044369.
BlindPublicKey and UnblindPublicKey
BlindPublicKey multiplies the public key pkS by an augmented private key skB yielding a
new public key pkR. UnblindPublicKey inverts this process by multiplying the input public
key by the multiplicative inverse of the augmented skB. Augmentation here maps the private
key skB to another scalar using hash_to_field as defined in ,
with DST set to "ECDSA Key Blind", L set to the value corresponding to the target curve,
e.g., 48 for P256 and 72 for P384, expand_message_xmd with a hash function matching
that used for the corresponding digital signature algorithm, and prime modulus equal to
the order p of the corresponding curve. Letting HashToScalar denote this augmentation
process, BlindPublicKey and UnblindPublicKey are then implemented as follows:
~~~
BlindPublicKey(pk, skB) = ScalarMult(pk, HashToScalar(skB))
UnblindPublicKey(pk, skB) = ScalarMult(pk, ModInverse(HashToScalar(skB), p))
~~~
BlindKeySign
BlindKeySign transforms the signing key skS by the private key skB into a new
signing key, skR, and then invokes the existing ECDSA signing procedure. More
specifically, skR = skS * HashToScalar(skB) (mod p).
Security Considerations
The signature scheme extensions in this document aim 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 blinds. Security
analysis of the extensions in this document with respect to these two properties
is currently underway.
Preliminary analysis has been done for a variant of these extensions used for
identity key blinding routine used in Tor's Hidden Service feature .
For EdDSA, further analysis is needed to ensure this is compliant with the signature
algorithm described in .
The constructions in this document assume that both the signing and blinding keys
are private, and, as such, not controlled by an attacker.
demonstrate that ECDSA with attackercontrolled multiplicative blinding
for producing related keys can be abused to produce forgeries. In particular,
if an attacker can control the private blinding key used in BlindKeySign, they
can construct a forgery over a different message that validates under a different
public key. Further analysis is needed to determine whether or not it is safe
to keep this functionality in the specification given this problem.
IANA Considerations
This document has no IANA actions.
Test Vectors
This section contains test vectors for a subset of the signature schemes
covered in this document.
Ed25519 Test Vectors
This section contains test vectors for Ed25519 as described in .
Each test vector lists the private key and blind seeds, denoted skS and skB
and encoded as hexadecimal strings, along with their corresponding public keys
pkS and pkB encoded has hexadecimal strings according to .
Each test vector also includes the blinded public key pkR computed from skS and skB,
denoted pkR and encoded has a hexadecimal string. Finally, each vector includes
the message and signature values, each encoded as hexadecimal strings.
ECDSA(P256, SHA256) Test Vectors
This section contains test vectors for ECDSA with P256 and SHA256, as
described in . Each test vector lists the signing and blinding keys,
denoted skS and skB, each serialized as a bigendian integers and encoded
as hexadecimal strings. Each test vector also lists the unblinded and
blinded public keys, denoted pkS and pkB and encoded as compressed elliptic
curve points according to . Finally, each vector lists message and
signature values, where the message is encoded as a hexadecimal string, and
the signature value is serialized as the concatenation of scalars (r, s) and
encoded as a hexadecimal string.
References
Normative References
Public Key Cryptography for the Financial Services Industry  The Elliptic Curve Digital Signature Algorithm (ECDSA)
American National Standards Institute
EdwardsCurve Digital Signature Algorithm (EdDSA)
This document describes elliptic curve signature scheme Edwardscurve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Informative References
PostQuantum KeyBlinding for Authentication in Anonymity Networks
Proving Security of Tor’s Hidden Service Identity Blinding Protocol
Highspeed highsecurity signatures
Elliptic Curves for Security
This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128bit and ~224bit security level, respectively, and are generated deterministically based on a list of required properties.
On the Security of the Schnorr Signature Scheme and DSA Against RelatedKey Attacks
Hashing to Elliptic Curves
Cloudflare, Inc.
Cornell Tech
Cloudflare, Inc.
Stanford University
Cloudflare, Inc.
This document specifies a number of algorithms for encoding or
hashing an arbitrary string to a point on an elliptic curve. This
document is a product of the Crypto Forum Research Group (CFRG) in
the IRTF.
Acknowledgments
The authors would like to thank Dennis Jackson for helpful discussions
that informed the development of this draft.