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

"Riad S. Wahby" <> Thu, 25 July 2019 03:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8054F120179 for <>; Wed, 24 Jul 2019 20:50:02 -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 2HEDzDEJrGI3 for <>; Wed, 24 Jul 2019 20:50:01 -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 05972120089 for <>; Wed, 24 Jul 2019 20:50:01 -0700 (PDT)
Received: by with SMTP id c2so22802978plz.13 for <>; Wed, 24 Jul 2019 20:50:01 -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=JQJBc+vjX3FgRWYhy4dQ5KqQI6WawgFxd48Kb97ml1Q=; b=WIGGg76bqX/ADh035DVww9PrF2+AuDskrRk1NBD80EbgilH6Gyvo6/rFjc8gTiftnG zf2sCqt17XCjnFrQcEFgKzdN6dSjINz2lUeWXIDzO3pX+I8vdU98aEXW9h5C3Onn6Kxw 97xPXcd/x6XHSAAIxlwFucT2lnK4hewkNz61WqL7EAPGF1DyEl0KAgzbUrY+aM+EtqdH KSmlSclwwZbUS6F0LBHmIZK0KGSZ3bTCIz2W7DhMxTMd6Th0xhvdCJ3xxjN/CFl8zB9u USj71W2EaBfYrB3PrbiRRpJFRPq8Adk2Vvhh6WO68P9WdUg+MB6QMSHyUT5oJj/9VIsZ 4jfw==
X-Gm-Message-State: APjAAAWmuLzU3/EL7dK7gQqdVX4a7+OPJgyJ4TGbb1USW7fmAwtuw7A7 Bk7aDrfypNrWt8vLLKulIxg=
X-Google-Smtp-Source: APXvYqwV8RTZxT1SZHrlCmlR8GnApDmNFxXkt7MxSMASjv3LbeAcyAqUKJb//Depk2+8QqRzf/atow==
X-Received: by 2002:a17:902:a03:: with SMTP id 3mr87750859plo.302.1564026600558; Wed, 24 Jul 2019 20:50:00 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id h12sm53985764pje.12.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jul 2019 20:49:59 -0700 (PDT)
Date: Wed, 24 Jul 2019 20:49:58 -0700
From: "Riad S. Wahby" <>
To: Filippo Valsorda <>
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: Thu, 25 Jul 2019 03:50:03 -0000

Filippo Valsorda <> wrote:
> I fully agree that Section 3.3 should be expanded to clarify that the
> operations are indeed edwards25519 addition, subtraction and scalar
> multiplication (when using edwards25519 as internal representatives).

Sweet! Thank you so much for your patience helping me understand.

Here's a concrete proposal to clarify the document:

1. Make the Section 3 implementations of ENCODE, DECODE, EQUALS, and
   FROM_UNIFORM_BYTES normative, and clarify that the inputs to ENCODE
   and EQUALS and the outputs of DECODE and FROM_UNIFORM_BYTES are
   edwards25519 points that are "internal representations."

2. As now, forbid implementors from exposing any point that is an
   internal representation.

3. Explicitly allow mapping any internal representation to any curve
   isomorphic to edwards25519, and state that the output of any such
   mapping remains an internal representation and thus subject to
   all of these requirements.

   (List the edwards25519/curve25519 isomorphism as an example,
   and direct the reader to the birational map in RFC7748.)

   I'd also get rid of the text in the Section 3 header that talks
   about groups of order l, since edwards25519 is not such a group
   and thus no group isomorphic to it is either.

4. Explicitly allow addition, subtraction / inversion, and
   multiplication on any point that is an internal representation.
   These operations MUST be isomorphic to addition, subtraction /
   inversion, and multiplication on edwards25519.

5. Explicitly state that any internal representation that is the
   result of a sequence of mapping operations MUST be converted back
   to edwards25519 internal representation via the inverse sequence
   of mappings before applying the ENCODE or EQUALS function.

6. Explain that implementors MAY compose (e.g.)  DECODE/mapping,
   FROM_UNIFORM_BYTES/mapping, reverse-mapping/ENCODE,
   reverse-mapping/EQUALS, and similar into monolithic functions.
   In other words, the idea isn't to dictate the structure of the code,
   only the underlying algebraic properties.

7. Make FROM_UNIFORM_BYTES incorporate edwards25519-SHA256-EDELL2-RO
   by reference, and specify a DST (domain separation tag, see Section
   5.1 and 5.3 of hash-to-curve), e.g., "Ristretto255-Hash".

I'm happy to read future drafts, create PRs, etc.---let me know how
I can help!