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

"Riad S. Wahby" <> Thu, 25 July 2019 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 301C11200B9 for <>; Wed, 24 Jul 2019 19:10:34 -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 l92T-wjqZuJH for <>; Wed, 24 Jul 2019 19:10:32 -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 A13D9120059 for <>; Wed, 24 Jul 2019 19:10:32 -0700 (PDT)
Received: by with SMTP id k189so3111260pgk.13 for <>; Wed, 24 Jul 2019 19:10:32 -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=sokUoanYIQxvvZb7yYqLc2g9umcLXN0dDqKjizLj2Es=; b=B+gQYpUaHtLdvA1Lq0OMCXCSqzn46Q0LDaKvjnXorJeuEGhyuo+LOnlOuQpIKWcRjR sLFxmN1lYT5qUj5MCtmI3sipPPongwUhY4xLwApdqZJNBHw1L4971xUkXRA0LAP07dcy /1JV4WYnf7lbmWAmLqgW1eLcPdk9Cf9eISSVGR/jf0H8rK1dCexergCFe/skZl04E6er euElxUSKJK0tyvaIHQLZdhBaqE9crldxy7LyJupfSpuTp305Fe2O5A42Bqk6TwCLuuqq h8bOypL5E/loxd/HXlqqMNLbim4cIzRH7jznHwUEWGv0tikuQo7AKCMnEAxICSR2DO5b f4rA==
X-Gm-Message-State: APjAAAU0RJnXGx7R/h2Lq8BrvBGluRkt85KfqsEE2x7SaGasom9VByop 5axgCwKHYLDTpQvajh1OhV0baEam
X-Google-Smtp-Source: APXvYqxa/fLKTp1/4Pi08Sl3hyxCw2/NutBNAcG2xoUp/egGWre/2BWc/sDInBJFIMfNo6aVKjbGPw==
X-Received: by 2002:a17:90a:eb04:: with SMTP id j4mr86775420pjz.103.1564020631112; Wed, 24 Jul 2019 19:10:31 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id v22sm45593176pgk.69.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jul 2019 19:10:30 -0700 (PDT)
Date: Wed, 24 Jul 2019 19:10:29 -0700
From: "Riad S. Wahby" <>
To: Filippo Valsorda <>
Cc: 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: Thu, 25 Jul 2019 02:10:34 -0000

Filippo Valsorda <> wrote:
>     DECODE -> map -> (something) -> reverse_map -> ENCODE
> This chain that you describe, if done correctly, would in fact be just
> an alternative implementation of ristretto255, as it operates entirely
> within the realm of internal representatives.

Sweet! I think I'm starting to get it...

In this case, let's be clear that we're talking about DECODE and ENCODE
as defined in Section 3, i.e., working on edwards25519 points as the
"internal representation."

>     ENCODE -> map -> (something) -> reverse_map -> DECODE
> This, correct me if I'm wrong, is an example of the kind of map Jeff
> is talking about: something that takes abstract ristretto255 elements
> (which might be implemented with something else than edwards25519) and
> maps them to edwards25519 points (NOT internal representatives).

Sorry, I don't understand this. edwards25519 points *are* valid
internal representations.

(I fully understand that munging the bitstring that comes out of
ENCODE is crazy and not allowedt, though!)

>     edwards25519 point -> (something) -> reverse_map -> ENCODE
>     DECODE -> map -> edwards25519 point -> (something)

Wait, what is the type signature of reverse_map? ENCODE takes an
edwards25519 point (again, per Section 3), so to me this looks like
a type error, in which case I fully agree this can't return anything

> An example of this is draft-irtf-cfrg-voprf-01 defining its own map to
> ristretto255 internal representatives.

As the Ristretto draft is currently written, that appears to be true
(or, at least, if it's false, it's only by chance).

(Not to muddy the waters, but for the record I'm strongly hoping
that the next Ristretto draft will replace its specification of
FROM_UNIFORM_BYTES with edwards25519-SHA256-EDELL2-RO. There's
no reason for Ristretto to be incompatible with hash-to-curve.
But let's worry about other issues first.)