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

"Riad S. Wahby" <rsw@jfet.org> Thu, 25 July 2019 14:36 UTC

Return-Path: <rswatjfet.org@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CA71201CF for <cfrg@ietfa.amsl.com>; Thu, 25 Jul 2019 07:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.558
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1ks3pZnb8Tl for <cfrg@ietfa.amsl.com>; Thu, 25 Jul 2019 07:36:30 -0700 (PDT)
Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6FC120325 for <cfrg@irtf.org>; Thu, 25 Jul 2019 07:36:29 -0700 (PDT)
Received: by mail-pg1-f181.google.com with SMTP id x15so12802614pgg.8 for <cfrg@irtf.org>; Thu, 25 Jul 2019 07:36:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cZ4iXV+6UXWxUMv32NulJsjqe3iZSosD7BYpyQ8t3s0=; b=mUPvUMp7g4ak1sAX5jsVksHBIB0A+n9o8j6rowTguK9dQrFCSonvq5fpxtsvS17zyt VFqRuwXlVPTo1ZtnRJMs4n2I7amot94OBOz2uDsKU+McsPT0dMQ/PN0g3Ijz+wuG0Sop wALHFxmAA2CRCcoaJVjK3pCFGtB42Dl3vl6IKsoYnmYKly9oWDYs3gM17Ft2pJgNB/OJ 85Nr4fRllbiKZ4/y1M4AfAkBfMv3YgXfVLMbWWr9AJIXTOFBKm2gTsdB8k3dT1BLnl9/ xXXF8fA46wuVytCnvCg6G993aLr8Ew3ZqNjBbLhYGtEPRqpt4ltbYUFKEYKpFlE/5wAp YTHw==
X-Gm-Message-State: APjAAAXsd95q0JJk8hkSK+6atW2Xx65ZiwrBL+IggFz8Gf9bD8tnqrOO WzS8jaq6/QkEHG8IwUU02SA=
X-Google-Smtp-Source: APXvYqzKrsli3NdHT0AJimayDOHnauB65lbmUl/MO9BNgnn204sqhT2vgkimYakpYAY3SV/h1t2haA==
X-Received: by 2002:a63:124a:: with SMTP id 10mr86008233pgs.254.1564065388610; Thu, 25 Jul 2019 07:36:28 -0700 (PDT)
Received: from localhost (positron.stanford.edu. [171.67.76.114]) by smtp.gmail.com with ESMTPSA id d6sm43871291pgf.55.2019.07.25.07.36.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jul 2019 07:36:27 -0700 (PDT)
Date: Thu, 25 Jul 2019 07:36:26 -0700
From: "Riad S. Wahby" <rsw@jfet.org>
To: Filippo Valsorda <filippo@ml.filippo.io>
Cc: draft-hdevalence-cfrg-ristretto@ietf.org, cfrg@irtf.org
Message-ID: <20190725143626.aetja4eeyzyimcne@positron.jfet.org>
References: <0370cd6b-adf3-4be2-9ab4-79693b9dc096@www.fastmail.com> <B7F73174-29F0-4B83-8AC0-A7D42D372D4A@inf.ethz.ch> <075d43b1-e123-42a9-ccd9-64fe45306f8b@web3.foundation> <20190724212030.ddcswlg5uxm3muzo@positron.jfet.org> <CAPC=aNVCV2cn62rhQsu+RsJsdjt2Dqqw_rqooLsuc8J5v9s3kQ@mail.gmail.com> <20190725004633.l5k7toldcgy7uthb@positron.jfet.org> <a391f8d5-c4c4-4650-9392-860864543198@www.fastmail.com> <20190725015259.betglszxmwpgg7q7@positron.jfet.org> <3dde344b-40d2-4ea8-84c9-7ddec039afe3@www.fastmail.com> <20190725034958.bp6nnhqedjwmyzng@positron.jfet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190725034958.bp6nnhqedjwmyzng@positron.jfet.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/AWt39r-bEWE3BxDgl-XxvEFTC5k>
Subject: Re: [Cfrg] Adoption request: draft-hdevalence-cfrg-ristretto
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 14:36:37 -0000

With apologies for a self-reply, a few addenda to my suggestions
based on off-list discussions:

0. Define the term "internal representation" up front. Make clear
   that it's a restricted version of an elliptic curve point that
   is defined over some underlying curve, and that all operations on
   intenal representations not explicitly allowed by the text of the
   document are prohibited.

"Riad S. Wahby" <rsw@jfet.org> wrote:
> 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."

Clarify in the above that inputs to ENCODE and EQUALS MUST be internal
representations; any other inputs are prohibited.

Also clarify that the only way to get an internal representation
is from DECODE, FROM_UNIFORM_BYTES, or from a permitted operation
applied to an existing internal representation.

> 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".

Also, rename FROM_UNIFORM_BYTES to either FROM_BYTES or FROM_STRING,
and remove the length and distribution requirements on the input.
The hash-to-curve document handles the uniformity internally while
ensuring that conforming usage meets relevant security requirements.
There's no reason to make higher-level protocols reinvent the wheel.

Again, happy to write a PR for this and/or read future drafts,

-=rsw