Re: [Cfrg] Fwd: New Version Notification for draft-barnes-cfrg-mult-for-7748-00.txt

Joel Alwen <> Tue, 05 November 2019 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABF7F120090 for <>; Tue, 5 Nov 2019 07:16:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cFORlUIpKMl1 for <>; Tue, 5 Nov 2019 07:16:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14ECE1200B3 for <>; Tue, 5 Nov 2019 07:16:37 -0800 (PST)
Received: by with SMTP id h2so16590738qto.1 for <>; Tue, 05 Nov 2019 07:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y6F9XjKwUuX5wkyxuhp9O+U3AKqOva0JikLYBeXDtCw=; b=arX5dDAuduGIvVXc9uT7EOfqgztwo9RjHsNX0dbw2DAl0rWuea04/87cT2Joymr29x kH0qOup1I6u6Uug1uxn8C8EVxXOAmqYXjv0qFF6Khs3qTgQ1cEDEvRYYsXhDzLl8wbCq oPmGTSna8RnxR5Fjx4I+dWJK8Z9ug5iWLx6r6lmLLHQlkkzVN+i2WSzSmZxYVGlHUeDV CahH9Dirjg0paUCV7nw3RfVl9f+OH0dFd2gzk6Ba5vu6aQTiYwBBUiJVegOnfFe9+kGt 51TYSbU5y+2tYR2OUSApE2vwINlgO59Q/5vgUIC34TxBHIzcgz3lasIYOC+yijcKWTBL 6lzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y6F9XjKwUuX5wkyxuhp9O+U3AKqOva0JikLYBeXDtCw=; b=TcfK+v4eyeheV8+RcZxqJXY6dvUx2ro7B+odP9sCiag1/MvEuj4O39rSAMatBVfIhE 4NVBUkjc9aGJFhtANeETjAnbpCAYoYAHfMaYKcCNFJlzCMbvC0PCAp1Zo/tWGqDvyIDp +gmIjCVQpq2uJ66lHGmzq7CBH3Z2AZHHwPbnwFaF9svqNjRBGBLxRj1/SqcgJRy7acRz IQ2ehb0IlQ93HJbNliOuChsoAGZPVjs3H/mYBhGSG0/a1wiSYVsVXboNgV4462H6rFF1 ltlqN9807VgWodaGvlkffqb4fI7dfnsO5EXnkSKxzcVES1gHrt5/lLwjV+KvnNai6sba Ngwg==
X-Gm-Message-State: APjAAAXjHiihxhmtK4zPNkiTD0PU7KAQ7KQaph2aAysBbTftdF9WOtep nlDxRXgWh7O45nI4dWIQ/1EHbpaWTJb3WnRFWPzeug==
X-Google-Smtp-Source: APXvYqwm36LBfg5uesSx/PEpIRqPF0Sbrb+M/22Gj/Pfuahf5UoZLmlSTItz2uquZ001DUG1bv57qhdkJhn6DXrWQuE=
X-Received: by 2002:ac8:7655:: with SMTP id i21mr18341323qtr.53.1572966994908; Tue, 05 Nov 2019 07:16:34 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Joel Alwen <>
Date: Tue, 5 Nov 2019 16:16:20 +0100
Message-ID: <>
To: Watson Ladd <>
Cc: Richard Barnes <>,, Sandro Coretti <>
Content-Type: multipart/alternative; boundary="000000000000f9aaf505969aeaae"
Archived-At: <>
Subject: Re: [Cfrg] Fwd: New Version Notification for draft-barnes-cfrg-mult-for-7748-00.txt
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 Nov 2019 15:16:41 -0000

>  What's the application where you cannot modify the implementation to
compute n*X for any n, not just one of a particular length?

The idea is for key updates/re-randomization to be implemented as a (thin)
layer on-top of an arbitrary X25519/X448 implementations. To me, this seems
like a significantly less risky approach than to expect implementers to
correctly modify the (often pretty complex) X25519/X448 implementations. In
particular, if I'm not mistaken, then what you are proposing would require
digging in to the montgomery ladder code. The second concern I'd have with
your suggest is it requires modifying otherwise standard libraries which
means people would have to backport those changes to every new version of
the library (or worse, not update).

>  Secondly the calculation assumes d uniformly random

Yes, that is the intended instantiation here. But depending on the
application it could be relaxed in one of two ways. For key updates as used
in BIP32 style Hierarchical Deterministic Key Derivation [2] and Tor's
Hidden Service Identity Blinding [3] I believe its sufficient that d simply
has negligible probability of hitting the "failure set" F. Thus d's
distribution could be very far from uniform and still be fine. However, for
the Updateable-PKE application as being considered for MLS [1] we also want
an extra forward secrecy type of property. Namely, given the old pk and the
updated key pair it should be infeasible to compute the old sk (more
precisely, the old sk should still have CPA security). Formally, that
probably means d should be (close to) uniform.

Having said this, we actually expect d to be chosen by first sampling some
input(s) to a cryptographic hash function and setting d to be the output.
I.e. choose d' and set d:=truncate(H(d'), |d|). With this approach I
believe it would in fact be secure to have d' chosen adversarially (up to a
large number of updates). After all, modeling H as a RO means the
likelihood any given d' hits F is at most 2^{-125} for X25519 (and much
smaller for X448) so even trying say 2^{45} different d' values still only
has a 2^{-80} probability of finding a single d \in F. (Not to mention that
given only the pk its not at all clear to me if its even feasible to
determine what the corresponding set F looks like.) All three applications
above use some variant of this technique for sampling d.

In any case, to be clear, AFAIK adversarially chosen d is outside the
target adversarial model for MLS.

- Joël


On Tue, 5 Nov 2019, 04:08 Watson Ladd, <> wrote:

> On Mon, Nov 4, 2019 at 6:53 PM Richard Barnes <> wrote:
>> Hi CFRG folks,
>> This draft is a proposal to address a deficiency in X25519 and X448 that
>> has been noted a couple of times on this list (e.g., [1]), namely the fact
>> that multiplication of scalars and point multiplication do not commute.
>> While looking into applications of updateable public-key encryption in the
>> context of MLS [2], my co-authors came upon a solution that while not
>> perfect, works in all but a statistically insignificant number of cases.
> If you have a ladder that doesn't require the high bit to be in any
> particular place, then you're fine.  What's the application where you
> cannot modify the implementation to compute n*X for any n, not just one of
> a particular length? Secondly the calculation assumes d uniformly random:
> but if d is say 2, then whether or not the generation fails is entirely
> dependent on the second bit of y if we write sk=2^254+8y, as 2*sk is
> 2^255+8*2*y, which if it's in the fail range proves y<x/2, which is true
> for about half the possibly y if I understand the notation correctly. What
> I don't know is if you can do this again, and extract another bit, and
> another, etc.
>> The draft describes how to do scalar multiplication in a way that is
>> compatible with point multiplication in the X25519 and X448 groups,
>> describes the cases where these algorithms can fail, and provides methods
>> for detecting failure.  While "move to Ristretto" is also a solution to
>> this problem, it seemed like a solution for X25519 / X448, even if partial,
>> might have a slightly faster path to deployment.
>> As with any -00 draft, feedback is very welcome!  If Go is your preferred
>> medium, we've also implemented the relevant concepts in the corresponding
>> GitHub repo [3].
>> Thanks,
>> --Richard
>> [1]
>> [2]
>> [3]
>> ---------- Forwarded message ---------
>> From: <>
>> Date: Mon, Nov 4, 2019 at 6:44 PM
>> Subject: New Version Notification for
>> draft-barnes-cfrg-mult-for-7748-00.txt
>> To: Richard L. Barnes <>sx>, Joël Alwen <>om>,
>> Sandro Corretti <>
>> A new version of I-D, draft-barnes-cfrg-mult-for-7748-00.txt
>> has been successfully submitted by Richard L. Barnes and posted to the
>> IETF repository.
>> Name:           draft-barnes-cfrg-mult-for-7748
>> Revision:       00
>> Title:          Homomorphic Multiplication for X25519 and X448
>> Document date:  2019-11-04
>> Group:          Individual Submission
>> Pages:          10
>> URL:
>> Status:
>> Htmlized:
>> Htmlized:
>> Abstract:
>>    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.  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.
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
>> _______________________________________________
>> Cfrg mailing list
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.