[CFRG] draft-irtf-cfrg-vrf-09 comments and clarifications

Christopher Peikert <christopher.peikert@algorand.com> Tue, 09 November 2021 23:49 UTC

Return-Path: <christopher.peikert@algorand.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 255963A0B9E for <cfrg@ietfa.amsl.com>; Tue, 9 Nov 2021 15:49:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algorand.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 ysAmKD7HfqKK for <cfrg@ietfa.amsl.com>; Tue, 9 Nov 2021 15:49:31 -0800 (PST)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 A3AEC3A0BEC for <cfrg@irtf.org>; Tue, 9 Nov 2021 15:49:31 -0800 (PST)
Received: by mail-yb1-xb35.google.com with SMTP id y3so1757221ybf.2 for <cfrg@irtf.org>; Tue, 09 Nov 2021 15:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algorand.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=7hCt+amRGqClaok/9WxLwLCSgxIiweldPV16elXASQE=; b=YEtA5zJGu6R4ONWm2TbVI2ztpqEw3U3iRDl66pg1HJ6OSe86z2DKrOLwiWvU/zci4z Xq2PJaXaTY5frbvCy/yNxFeybFGXly2r5jALbeLx6zM5G7MYyr7aJs8/u0+u2RRqPNME gV5v5DPzaUfTRLfSaTeHWohy0kpV2NX27N9sCSd8bnqlNm/+J6dEWbKr1IG5pteJCwQG +OAfrzKCN6MCz6vpB0j71cCIXIWiYXtmyf36HA/2EOL9foCL9bTbvmbF8LtOQ0IC9qFZ zbzit2ARBFUBD3qdq25N4vxNG2xXwPkfC/IN/P54fzms7Yvl1yxgtBt7d5qkI7Bp3tmD pgXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7hCt+amRGqClaok/9WxLwLCSgxIiweldPV16elXASQE=; b=ftoAVwWDdRXrH0RMF/vOwuTRxUUIGejqfml4YoblWm6F7KSHu+gAHcOfZdYzAtWMQQ JpAimdK+YZ2UMLi7LTdYSNkmtoIQeSoBOl8RVitCppu6iF4whB65Dt2dNNwxIui6YmZj L/8TnCQl7Y7R2QRk0fS1w3j/8/wYD++KqyF79qdLY3CLLgJ5OnvYRiramuNEso+C+lLr EL57dbtTwz6O++NzZonGTuQt3cUh7jXcI5mHJtmxxf+/eqqS46y/Kxpy48B+N04ZXC+l Dz/baD4U93OLcFdrn1WJ655TxIqlASEAwt4CAwYwZn5bFaB0JGiNP8Do8Aapuuv60MwZ 8i/A==
X-Gm-Message-State: AOAM531T/YgsSUc1i3T8ukKt5vGHAD8lE7bc+cX+OeLzjQCSKLA6moXk gyaKrctrzR3oTweEvcYg9i4xPK4KxcWSuw7Y7/kJ43iTow6wTfvI
X-Google-Smtp-Source: ABdhPJwJW7gOT7vkeCH0UJlIoEwIZuTgNGLJ+uISA658CAVNpVRQYYojWYmOoo9b4Ywf0sfa0E2Nl3st2lFxkmc42T8=
X-Received: by 2002:a25:a2cd:: with SMTP id c13mr12750336ybn.95.1636501768582; Tue, 09 Nov 2021 15:49:28 -0800 (PST)
MIME-Version: 1.0
From: Christopher Peikert <christopher.peikert@algorand.com>
Date: Tue, 09 Nov 2021 18:49:17 -0500
Message-ID: <CAJ9Arpi+=PT8pakA=dtDW9HLYY5wu7Zphv7S3sWURKXDe8Os7Q@mail.gmail.com>
To: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000097549505d063c249"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0p98hdvsXIl3Nh3SD8OHZbyATpI>
Subject: [CFRG] draft-irtf-cfrg-vrf-09 comments and clarifications
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: Tue, 09 Nov 2021 23:49:36 -0000

Hello, Jiayu Xu and I have two additional remarks about the current ECVRF
draft, specifically Sections 5.4.1 and 5.6.

Section 5.4.1: hash-to-curve should perhaps be generally described as
outputting a *finite* (i.e., non-identity) EC point H in G. The three
instantiations in Sections 5.4.1.1-3 are described this way, but the
general operation is not.

Non-identity H is used in the published proof of uniqueness (both trusted
and full): if H is identity, then discrete logs with base H are not well
defined and the proof doesn't make sense as written.

However, it interestingly turns out that non-identity H is not a
*necessary* requirement for uniqueness; the existing proof easily extends
to deal with this case. Essentially, if a cheating prover attempts to
provide some Gamma for which cofactor*Gamma is (incorrectly) not identity,
then there is only one possible value of the hash-challenge c for which the
prover can succeed. This is exactly the same situation as when a prover
attempts to provide an incorrect Gamma when H is not identity.

The published proofs of collision resistance (trusted and full) and
pseudorandomness also do not require H to be non-identity.

So, there is an option to drop this non-identity requirement, or at least
provide further clarity about it. (Perhaps it will be needed for some
future security property we have yet to contemplate.)

Section 5.6 says:

   In order to obtain "full uniqueness" and "full collision resistance"
(which provide protection against a malicious VRF public key), the Verifier
MUST perform the following additional validation procedure upon receipt of
the public VRF key. [The procedure simply rejects any public key that
belongs to the small-order "torsion" subgroup.]

This text is formally true but somewhat confusing. The validation is needed
only for "full collision resistance," not "full uniqueness." (Details
follow.) So, we suggest removing the mention of "full uniqueness" from the
above.

For collision resistance, there is an easy attack if the public key is
invalid.

However, full uniqueness holds as long as the public key is a valid
elliptic curve point --- even if it is in the torsion subgroup, or is even
the identity element. This is essentially because a valid proof ensures that

   cofactor*Gamma = dlog_B(cofactor*pubkey) * H .

(This holds even if the dlog on the right-hand side is zero.) So the LHS,
and hence the function output, is uniquely defined.

Sincerely yours in cryptography,
Chris