Homomorphic Multiplication for X25519 and X448Ciscorlb@ipv.sxWickrjalwen@wickr.comIOHKcorettis@gmail.comInternet-DraftIn some contexts it is useful for holders of the private and public parts of an
elliptic curve key pair to be able to independently apply an updates to those
values, such that the resulting updated public key corresponds to the updated
private key. Such updates are straightforward for older elliptic curves, but
for X25519 and X448, the “clamping” prescribed for scalars requires some
additional processing. This document defines a multiplication procedure that
can be used to update X25519 and X448 key pairs. This algorithm can fail to
produce a result, but only with negligible probability. Failures can be
detected by the holder of the private key.Source for this draft and an issue tracker can be found at
https://github.com/bifurcation/draft-barnes-cfrg-mult-for-7748.In some contexts it is useful for holders of the private and public parts of an
elliptic curve key pair to be able to independently apply an updates to those
values, such that the resulting updated public key corresponds to the updated
private key. [[ TODO: Cite examples (e.g. HKD like BIP32, Tor Hidden Service
Identity Blinding, MLS), security properties]]Such updates are straightforward with traditional elliptic curve groups, such as
the NIST and Brainpool curve groups , or with the
proposed Ristretto groups . In these
groups, multiplication of points by scalars is a homomorphism with regard to
multiplication of scalars, so a key pair can be updated by multiplying the
private key and the same “delta” scalar. In other words, the following diagram
commutes for all d, where d\* represents scalar multiplication by d and
\*G represents multiplication of a scalar with the base point of the curve:The X25519 and X448 functions defined in RFC 7748 , however, require
scalars to be “clamped” before point multiplication is performed, which breaks
this homomorphism. In particular, scalars are passed through the
decodeScalar25519 or decodeScalar448 functions, respectively, which force a
high-order bit to be set. Since this high-order bit is not guaranteed to be set
in the product of two such numbers, the product of of two scalars may not
represent a valid private key. In fact, there are points on Curve25519/Curve448
which are not X25519/X448 public keys, because their discrete logs do not have
the correct high bit set.Fortunately, X25519 and X448 use only one coordinate to represent curve
points, which means they are insensitive to the sign of the point, so a scalar
private key and its negative result in the same public key. And if a given
scalar does not have the correct bit set, then its negative modulo the curve
order almost certainly does. (We quantify these ideas below.) This allows us
to construct an amended multiplication routine that succeeds with overwhelming
probability, and where the failure cases are detectable by the holder of the
private key.The remainder of this document describes these algorithms, quantifies the
failure cases and the resulting probabilities of failure, and discusses how
failures can be detected.The following procedures allow for updating X25519/X448 public keys and private
keys in constant time. The values sk and pk represent the private and
public keys of the key pair, and the value d represents a “delta” scalar being
applied. All arithmetic operations are performed modulo the order n of the
relevant curve:X25519:
x = 0x14def9dea2f79cd65812631a5cf5d3edn = 8 * (2^253 + x)b = 254X448:
x = 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0dn = 4 * (2^446 - x)b = 447The pulic operation is clearly just a normal DH operation in the relevant curve.
The private operation computes the product of the delta with the private key as
well as its negative modulo the curve order. If the product does not have the
correct bit set, then the cswap operation ensures that that the negative is
returned.If updatePrivate and updatePublic are called on both halves of a key pair,
and updatePrivate produces a valid private key (with the relevant high bit
set), then the output private and public keys will correspond to each other.
(That is, the public key will equal the private key times the base point.) If
the updatePrivate function does not return a valid private key, then the
update has failed, and the delta d cannot be used with this key pair.An update of a private key sk by a delta d fails if and only if neither
d*sk or n - d*sk has the relevant bit set. In this section, we will assume
that for uniform d, this product c = d*sk is uniformly distributed among
scalars modulo n. From this assumption, we can describe the set of values c
for which updates fail, and thus estimate the probability that an update will
fail.In general, an update fails if neither c nor its negative has the relevant
high bit set, i.e., if they are not in the range [M, N], where M = 2^b and
N = 2^{b+1} - 1. So our failure criterion is:So the probability of failures is proportional to the size of the set where this
conditions applies. In the following subsections, we will calculate these
values for X25519 and X448.In the case of X25519, the following values apply:Thus we have n - N < M < n-M < N, so the failure set F and the failure
probability |F|/n are as follows:In the case of Curve448, the following values apply:Thus we have n - N < 0 < n - M < M < N, so the failure set F and the failure
probability |F|/n are as follows:Protocols making use of the update mechanism defined in this document should
account for the possibility that updates can fail. As described above, entities
updating private keys can tell when the update fails. However, entities that
hold only the public key of a key pair will not be able to detect such a
failure. So when this mechanism is used in a given protocol context, it should
be possible for the private-key updater to inform other actors in the protocol
that a failure has occurred.[[ TODO: Comment on whether this algorithm achieves the security objective
stated in the introduction ]]The major security concerns with this algorithm are implementation-related. The
updatePrivate function requires access to the private key in ways that are
typically not exposed by HSMs or other limited-access crypto libraries.
Implementing key updates with such limited interfaces will require either
exporting the private key or implementing the update algorithm internally to the
HSM/library. (The latter obviously being preferable.)As an algorithm involving secret key material, the updatePrivate function
needs to be implemented in in a way that does not leak secrets through side
channels. While the algorithm specified above is logically constant-time, it
reques that multiplication, subtraction, and conditional swap be implemented in
constant time.This document makes no request of IANA.Elliptic Curves for SecurityThis 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 ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.Digital Signature Standard (DSS)Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve GenerationThis memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.The ristretto255 GroupThis memo specifies a prime-order group, ristretto255, suitable for implementing complex cryptographic protocols such as zero-knowledge proofs. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group.All values are presented as little-endian integers. An implementation should
verify that the following relations hold:sk1 = updatePriv(d, sk0)pk1 = updatePub(d, pk0)pk1 = CurveN(sk1)Successful update (no swap):Successful update (swap):Failed update:Successful update (no swap):Successful update (swap):Failed update:Thanks to Mike Hamburg for reviewing an early version of the ideas that led to
this document.