Re: [CFRG] Small subgroup question for draft-irtf-cfrg-hash-to-curve

Loup Vaillant-David <loup@loup-vaillant.fr> Fri, 09 April 2021 19:54 UTC

Return-Path: <loup@loup-vaillant.fr>
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 28DB53A09C3 for <cfrg@ietfa.amsl.com>; Fri, 9 Apr 2021 12:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 rBZvxEgMv2KX for <cfrg@ietfa.amsl.com>; Fri, 9 Apr 2021 12:54:50 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33EBF3A09BD for <cfrg@irtf.org>; Fri, 9 Apr 2021 12:54:49 -0700 (PDT)
X-Originating-IP: 78.198.246.40
Received: from grey-fade (unknown [78.198.246.40]) (Authenticated sender: loup@loup-vaillant.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C561D60005; Fri, 9 Apr 2021 19:54:45 +0000 (UTC)
Message-ID: <1afa42b3b8cb429e549eededd07403513a6d24a1.camel@loup-vaillant.fr>
From: Loup Vaillant-David <loup@loup-vaillant.fr>
To: Armando Faz <armfazh=40cloudflare.com@dmarc.ietf.org>, "Hao, Feng" <Feng.Hao@warwick.ac.uk>
Cc: IRTF CFRG <cfrg@irtf.org>
Date: Fri, 09 Apr 2021 21:54:44 +0200
In-Reply-To: <CABZxKYmf2F0MV=aSa3ZrGbW3OuEzbsjMJ3ubCfPK+3Zg-Bkohw@mail.gmail.com>
References: <CABZxKYmf2F0MV=aSa3ZrGbW3OuEzbsjMJ3ubCfPK+3Zg-Bkohw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/HPXA3otu1u0GgkClgYybqAaubr8>
Subject: Re: [CFRG] Small subgroup question for draft-irtf-cfrg-hash-to-curve
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: Fri, 09 Apr 2021 19:54:54 -0000

> The concern is akin to the generation of keys. For example, calling a
> PRGN(seed) to get a key K. Of course, the key generation procedure
> must ban the case of K=0. […]

That is far from obvious to me. Banning a key just reduces the search
space. Should we ban 0 because the attacker is more likely to test it
first? Then what about 1? Or 37? Or 2^256 - 1? Any published number? In
my opinion, the best solution is a uniform RNG. If we really want to
maximise unpredictability, we must not ban any number. Not even zero.

At least in the case of elliptic curves, one may argue that we should
ban the identity point because its properties are observably different
from all other points. Not just the bit pattern, but the fact that it
has order 1. (And even then I'd be cautious.)

Loup.