Re: [Cfrg] Call for participation: privacy-pass virtual IETF BoF

Jeff Burdges <> Wed, 25 March 2020 11:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 941083A0D27 for <>; Wed, 25 Mar 2020 04:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.958
X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qnw_ZJ-XFeLt for <>; Wed, 25 Mar 2020 04:15:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8B623A0D25 for <>; Wed, 25 Mar 2020 04:15:02 -0700 (PDT)
Received: from [] ( [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by (Postfix) with ESMTP id DF36E1C00D2; Wed, 25 Mar 2020 12:19:14 +0100 (CET)
From: Jeff Burdges <>
Content-Type: multipart/signed; boundary="Apple-Mail=_6C606EC2-2706-47AD-8663-7B3CDFBE78D6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 25 Mar 2020 12:14:53 +0100
References: <> <>
To: Alex Davidson <>, "" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Cfrg] Call for participation: privacy-pass virtual IETF BoF
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: Wed, 25 Mar 2020 11:15:05 -0000

I’ve wondered if there should  be a general DLEQ proof draft that abstracts both the VRF proposal and the privacy pass proposal?

It’s hard for me to imagine anyone implementing either proposal without producing that abstract DLEQ proof machinery, if only for their own peace of mind.  At the same time, these DLEQ proofs are not miss-use resistant like signatures, which includes VRFs, or perhaps like PrivacyPass.

I suppose miss-use resistance wins here, but I have thought only about miss-use resistance for VRFs, not for PrivacyPass.  At least some tricks remain the same, like issuing public keys must be included with the nonce when hashed-to-the-curve to prevent related key attacks.