Re: [Cfrg] Curve25519 lacks private/public homomorphism?

Dan Brown <> Tue, 05 February 2019 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0066124BAA for <>; Tue, 5 Feb 2019 09:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.61
X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 94qbvq60ud9z for <>; Tue, 5 Feb 2019 09:20:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAE04130E92 for <>; Tue, 5 Feb 2019 09:20:21 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2019 12:20:14 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Feb 2019 12:20:14 -0500
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::59f9:6b62:c489:7f43%13]) with mapi id 14.03.0415.000; Tue, 5 Feb 2019 12:20:13 -0500
From: Dan Brown <>
To: Richard Barnes <>, CFRG <>
Thread-Topic: [Cfrg] Curve25519 lacks private/public homomorphism?
Thread-Index: AQHUvNgOFwu3M9YoVUKwftYRZJ/N2qXRccEw
Date: Tue, 05 Feb 2019 17:20:12 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0167_01D4BD4D.23A22F70"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Cfrg] Curve25519 lacks private/public homomorphism?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Feb 2019 17:20:25 -0000

Hi Richard,


Could you not just add delta to the private key (instead of multiplying the private key)?  (Add [delta]G to the public key.)  


This seems to meet your four bullet points, though I did no follow-up reading.


Adding delta is certainly NOT a morphism of the DH group, though it is a morphism of the curve, etc., etc.  Maybe you need the group morphism property for a sophisticated reason that you forgot to list?


Anyway, if delta is small enough, say delta<2^200, there is little chance of disturbing the top bit.  (If some bottom bits are fixed, set the few bottom bits of delta to zero.)


By the way, it is not yet clear to me why these key “updates” would be “useful”.  (Either added or multiplied).


Best regards,




From: Cfrg <> On Behalf Of Richard Barnes
Sent: Monday, February 4, 2019 5:21 PM
To: CFRG <>
Subject: [Cfrg] Curve25519 lacks private/public homomorphism?




I'm trying to work through whether the MLS working group can use Curve25519 in a particular way, and was wondering if folks here had any insights.


MLS has a case where it would be useful to be able to be able to implement the following:


- Given a DH key pair whose private key is held by one set of parties and public key by another

- Have a third party (holding only the public key) be able to generate a "delta" such that:

  - The holders the private key can use the delta to update the private key to a new value

  - The holders of the public key can use the delta to compute the corresponding new public key


That is, we're looking to use a certain homomorphism in the DH group action that translates a change in private key to a change in public key.  For example, with traditional ECDH, you could generate a random number that the private key holders could multiply with the private key, and the public key holders could just do a DH operation to multiply the public key by the delta.  (A sketch in Go here [1].)


When you try to do this with Curve25519 (or Curve448), however, you run into a problem: `k_list[31] |= 64`.  The X25519 function in RFC 7748 [2] ensures that the second-most-significant bit of a scalar private key is always set, but this bit is not necessarily set in the product of two such scalars.  In other words, there are scalars `ab` such that you can arrive at `abG` as the result of a DH computation, but never abG will never be a public key (since `X25519(ab, 9) != abG`).  The mapping from private keys to public keys is not a homomorphism with regard to addition or multiplication.


This means we're out of luck with regard to our delta scheme.  If the delta happens to result in a new private key with its penultimate bit unset, then it can't actually be used as a private key -- and there's no way for the delta-generating party to know this.


Is this surprising to people?  Is it a consequence of some property of Curve25519 that is good for security, or is it just collateral damage?  (Why does the penultimate bit need to be set?)  Do folks have other ideas for a "homomorphic" construction such as the above that would accommodate this quirk of Curve25519?


Thanks a lot,




[1] <> 

[2] <>