Re: [Cfrg] Adoption request: draft-hdevalence-cfrg-ristretto

"Riad S. Wahby" <> Wed, 24 July 2019 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10175120372 for <>; Wed, 24 Jul 2019 14:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.558
X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1z5NaJVhgFAk for <>; Wed, 24 Jul 2019 14:20:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80D8112029D for <>; Wed, 24 Jul 2019 14:20:33 -0700 (PDT)
Received: by with SMTP id m30so21565895pff.8 for <>; Wed, 24 Jul 2019 14:20:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=EzOzUDBiMoMVha6Woq3Y4g/sVz80DVNEv/xWSWrQr7s=; b=S+7G2EuXhq63O4XIyNLT10W2p+MP6dKMmxQtY581IPffqKcDlI8g9MbUwHpA1x06eq Eeh/VuT0lZlNJj8W3O5ZrCgrbgVskUrH57lEpb1l2vONmA8JDJCGA5O8FaML2cFaqXNZ xyTWPIFT5lV1fZGNMH53NR9/gC92wSnHZwt/5gSB557D4fnAYgGC5vhh6m7MxhMnsq6u MkCJJchGRRJWWBBCDz39a4lh/9qkV4ecAOpkfB3O6pY4WH4BlNPFGMVOZEZH+hs95dr8 4Yp1W4ZOjOujI3FsAIhwBiCUf0Ro4UE2Jg+klPjt4DsR10No1TtwYS31Qm6f0eXzCrsD oNwQ==
X-Gm-Message-State: APjAAAUUY91446W68OUC7m+qtDNMpuVFFxkBViBAUV1EQi1eZ33PGAXK c5KOcy+HZQ/5PIEdOIWCtNw=
X-Google-Smtp-Source: APXvYqwkTVdF/1TK2v2cbkNt1J2SWL/XurpQRBCZkAw4c+4Z38E2IbbPwkL3AU9gwdHfXeTfLhWh3A==
X-Received: by 2002:a17:90a:7d04:: with SMTP id g4mr90175384pjl.41.1564003232888; Wed, 24 Jul 2019 14:20:32 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id o95sm40941466pjb.4.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jul 2019 14:20:31 -0700 (PDT)
Date: Wed, 24 Jul 2019 14:20:30 -0700
From: "Riad S. Wahby" <>
To: Jeff Burdges <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Cfrg] Adoption request: draft-hdevalence-cfrg-ristretto
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: Wed, 24 Jul 2019 21:20:35 -0000

Hello Jeff,

I think I'm being a little slow here---sorry! But:

Jeff Burdges <> wrote:
> I'd expect the only contentious issue around Ristretto might be the
> decision that a mapping from Ristretto to Ed25519 should not be
> standardized.
> It's clear such a map is useful, so often people start off favoring one,
> but it's also clear such a map leads to non-compliant implementations,
> so similarly often people eventually come around to the opinion that
> such a map should not be standardized.

Can you please explain in a little more detail what you mean by
"such a map leads to non-compliant implementations"? The most naive
interpretation appears to be: currently a bunch of people do different
things, so if the document requires one thing, some of those people
will be non-compliant. Is that right? Or do you mean that somehow
it would be impossible for (some) implementations to comply with any
particular spec? (If so, why?)

In any case, it seems to me that what we should care about is
interoperability, not compliance for its own sake. Is it the case
that dictating the Edwards mapping just doesn't matter, because
implementations will be able to interoperate despite using different
mappings internally? (I assume yes, based on my understanding of
Decaf.) If that's right, it seems reasonable to give implementors
latitude to make decisions that have no effect on interoperability.
(As a very rough analogy, RFC7748 doesn't say "you MUST do modular
reductions in such-and-such way," because that doesn't matter from
an interop perspective.)

If my interpretation is correct, then I suggest the authors provide
a mapping that implementations MAY use, as a way of assisting
implementors in getting things right. This is probably as simple as
citing the birational map between edwards25519 and curve25519 from
Section 4.1 of RFC7748, and explaining how to use this map in concert
with the Ristretto functions.

Also, a couple general comments for the authors regarding the document
as it currently stands:

First, the text of section 1 makes repeated reference to Edwards
curves, but the document deals with a Montgomery curve (and, per the
above, explicitly *does not* deal with an Edwards curve)---and the
word Montgomery *never appears in the document*! Of the curves are
equivalent, but the document should be intelligible even to readers
who don't instantly recall this fact. I'm happy to suggest specific
(likely minor) edits to the intro to help clarify this point.

Second, to make extremely clear what's going on with the Ristretto
functions, it probably makes sense to reiterate, for each function,
the types of the input and output. For example, I think the document
is saying that DECODE takes a 32-octet string as input and returns
a point (X : Y : Z : T) on curve25519 (i.e., the Montgomery curve)
equivalent to the affine point (x, y) = (X/Z, Y/Z) (and analogously
for the rest). Is this right? To my reading, this is not obvious from
the document. That might be me being slow---sorry!---but perhaps in
that case the authors will interpret this as feedback from a very
naive reader who would love some extra handholding :)

Looking forward to Ristretto,