Re: [Cfrg] Call for adoption: draft-hdevalence-cfrg-ristretto-01
Alex Davidson <alex.davidson92@gmail.com> Mon, 30 September 2019 18:20 UTC
Return-Path: <alex.davidson92@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 D12CB120052 for <cfrg@ietfa.amsl.com>; Mon, 30 Sep 2019 11:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1ZwHgSP0EgMX for <cfrg@ietfa.amsl.com>; Mon, 30 Sep 2019 11:20:33 -0700 (PDT)
Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (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 CFF4312006E for <cfrg@irtf.org>; Mon, 30 Sep 2019 11:20:32 -0700 (PDT)
Received: by mail-ua1-x944.google.com with SMTP id n2so4510469ual.11 for <cfrg@irtf.org>; Mon, 30 Sep 2019 11:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WNP8tcKG8DwSozZgPHin7U9I403yAH5NeoYHD+qKXlw=; b=MtWmAr1NPjXcitAp2hI/Ks/Och7XovbJglhFabsfCfRgkicj5BQt+0L443+jd62G2g qVfncx26f7jJxS0j8TtP0sZlLXtrYU6KLWnDdR4hCNuvKLhYjO472saRRTNQylUYX00P lskHc4hmqwEM381EMninqA+nVjtN559pUjh6mTFY+ujDSL7i7b6qMy6hTNig9eKm1drK hXzr2dOcH/6Goqns9XU+RyIgy8XJwwI4PoGCrCF4mDhLDwyHx9DVHprdwmIG9kmH1cYI qp8jOq14ng8R/t/BUsV2sXsDNVfhtRCpyY/LlJHa7W77PGXFdanwKsFi/Il1fs3kfs5c jQhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WNP8tcKG8DwSozZgPHin7U9I403yAH5NeoYHD+qKXlw=; b=OUwF7JyzzjSfSBhT9ZHTd0x9qHSlifaD7Gmn9UzeHlyT4nA3kyfMtFj3B5GrFdKyU+ GnDKXzm/fhyyTfI4XePqqRXNRAk3IptClrK/GYJBS3yOvFPK97ncb2jbLwZf5ewqgdqB AytdFqRAPFM52N06cg+dZrjWHcrvGS12NwAUGj3Y1VbY0bis67Agb9UBYw514EQOfMNC w5rVMY4YfK5LIr+xE0DYHQHQEI4izyfFxDHeV26ZIbSmJ5R1EvgE/DiXbmACHvERSrMe 5QOqCAZWWNZ0Pwx/SyQrmiKK4okvvKq3nFnN8PGPfXJhW0n6FgB/rpAyMrrejGN4mdva gppg==
X-Gm-Message-State: APjAAAVv7Lgsi0ybd4wyg5clIqvqfW8diwj1vc3r5uRxG/9I/6XGiStW oNe5qekiW0rPSV6TuSEvw9HTZg/UHuAQJ3z+xw==
X-Google-Smtp-Source: APXvYqww2SxYEPF8ybKbOFAn50pxB9fCLb0fsQEgwBuH4GH3y2+fccua3ZZ+1V3qN5S0wrTFWDjJoZekieUF8QJaaqM=
X-Received: by 2002:ab0:2b0a:: with SMTP id e10mr12453340uar.4.1569867631549; Mon, 30 Sep 2019 11:20:31 -0700 (PDT)
MIME-Version: 1.0
References: <e43c34da-1e2c-d1b5-9fc1-5bcc8373ebc8@isode.com> <CAL02cgQorNKVrOPvqZQtDQNK-F0nH_dwj3i39zadkBKM1O0U5A@mail.gmail.com> <161fc653-2cab-4c6d-812b-92d2e426719d@www.fastmail.com> <6be1dbd1-308c-4e32-98e3-f02dbceefa4d@www.fastmail.com> <CAD5V+fPL+OAoQu_emTSULvv=-hUsrQx97y-7EoeKsfoXH=NTbA@mail.gmail.com> <704a89b1-1527-90c6-41c5-6f17a03d973d@mit.edu>
In-Reply-To: <704a89b1-1527-90c6-41c5-6f17a03d973d@mit.edu>
From: Alex Davidson <alex.davidson92@gmail.com>
Date: Mon, 30 Sep 2019 19:20:19 +0100
Message-ID: <CAD5V+fPR37VYr9K6T7A3FTAuxgaaMv-WdQd6mXcGHyydks7Cag@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: Filippo Valsorda <filippo@ml.filippo.io>, draft-hdevalence-cfrg-ristretto.authors@ietf.org, cfrg@irtf.org
Content-Type: multipart/alternative; boundary="00000000000085dff00593c94a00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/u1WX6ge_62RWx4oOAgqmUOR99Nk>
Subject: Re: [Cfrg] Call for adoption: draft-hdevalence-cfrg-ristretto-01
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: Mon, 30 Sep 2019 18:20:35 -0000
Hi Greg, I should have made it more explicit here that I'm assuming that the initial hash function evaluation is modelled as a random oracle. In general, pseudorandom functions are designed to provide pseudorandom outputs (indistinguishable from the output of a uniformly sampled function) even under adversarially-chosen inputs. So in some sense requiring that the client in an OPRF protocol supplies uniformly sampled inputs due to internal functionality reasons is overly restrictive (and prevents some useful applications e.g. [1,2]). As such, maintaining the ability of a client to supply non-uniform inputs would seem to at least require some form of pre-processing before using the Ristretto point encoding API. Alex [1]: https://eprint.iacr.org/2016/799.pdf [2]: https://eprint.iacr.org/2014/650.pdf On Mon, Sep 30, 2019 at 5:37 PM Greg Hudson <ghudson@mit.edu> wrote: > On 9/30/19 7:36 AM, Alex Davidson wrote: > > For the second point, there is a possible solution in defining a > > FROM_BYTES API > > function as part of the Ristretto interface. This would take non-uniform > > bytes, > > transform them to uniform bytes, and then invoke FROM_UNIFORM_BYTES on > the > > output of this transformation. For ristretto255 it would be fine to use > > SHA512, [...] > > Hashing non-uniform inputs does not produce uniform outputs. Some > obvious statistical biases may be eliminated, but certain outputs are > still more likely than others (unless hash collisions manage to > precisely cancel out the non-uniformity of the input). Is Ristretto > asking for too much by requiring a "uniformly distributed 64-byte string > b"? >
- [Cfrg] Call for adoption: draft-hdevalence-cfrg-r… Alexey Melnikov
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Richard Barnes
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Christopher Wood
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Christopher Wood
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Filippo Valsorda
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Alex Davidson
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Greg Hudson
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Alex Davidson
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Riad S. Wahby
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Riad S. Wahby
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Greg Hudson
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… John Mattsson
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Alexey Melnikov
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Filippo Valsorda
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Riad S. Wahby
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Riad S. Wahby
- Re: [Cfrg] Call for adoption: draft-hdevalence-cf… Filippo Valsorda