Re: [CFRG] RSA blind signatures

Jeff Burdges <burdges@gnunet.org> Wed, 24 February 2021 08:49 UTC

Return-Path: <burdges@gnunet.org>
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 E93C13A0D69 for <cfrg@ietfa.amsl.com>; Wed, 24 Feb 2021 00:49:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3ENt564t3O85 for <cfrg@ietfa.amsl.com>; Wed, 24 Feb 2021 00:49:51 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957763A11C7 for <cfrg@irtf.org>; Wed, 24 Feb 2021 00:49:29 -0800 (PST)
Received: from [127.0.0.1] (sam.net.in.tum.de [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by sam.net.in.tum.de (Postfix) with ESMTP id E04601C00D2; Wed, 24 Feb 2021 09:50:37 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Jeff Burdges <burdges@gnunet.org>
In-Reply-To: <CAOyO2_LgLbuyK-azfDCaYPPmUxv6uug29xr2upkz_V1+0UuwNA@mail.gmail.com>
Date: Wed, 24 Feb 2021 09:49:20 +0100
Cc: Taler <taler@gnu.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB35855F-555B-41AB-89BE-629C3402F230@gnunet.org>
References: <44983891-284f-4552-b4c7-bc432148d214@www.fastmail.com> <CAOyO2_LgLbuyK-azfDCaYPPmUxv6uug29xr2upkz_V1+0UuwNA@mail.gmail.com>
To: Michele Orrù <lists@tumbolandia.net>, IRTF CFRG <cfrg@irtf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/El3SzPM4j3eg-ItZcaGZNzxZ6mA>
Subject: Re: [CFRG] RSA blind signatures
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: Wed, 24 Feb 2021 08:49:54 -0000

As a rule, there are relatively few keys in an RSA blind signature deployment, so you could batch verify all messages with the same public key.  I suppose someone who knows the secret p and q might construct FDH with interesting summations, ala https://eprint.iacr.org/2020/945  I’d expect some common RSA assumption forbids this for anyone who does not know the secret key though, so RSA batch verification should turn out secure.

I think RSA batch verification does not improve performance for one spend operation *if* your public keys represent denominations in powers of two, but batch verification does help RSA if you’ve less dense denominations.  In this setting, an RSA blind signature would likely be checked twice, first at a merchant, and second at the exchange/bank/mint.  I suppose exchanges could quickly return “no double spend” to merchants, and then aggregate RSA verification across thousands of spends.  

You'll never benefit from common message aggregation for BLS blind signatures, so every denomination requires another 1500 microsecond Miller loop, which  sounds slower than RSA, no?

Jeff





> On 24 Feb 2021, at 09:17, Michele Orrù <lists@tumbolandia.net> wrote:
> 
> For those cases needing Privacy Pass but with public verifiability, I would kindly ask CFRG to also take a second to evaluate blind BLS signatures.
> 
> It is true that verification would be much slower than RSA;  however, they have efficient batching algorithms (for which the amortized cost is ~2 scalar multiplications) and the issuance protocol is literally the same as a Privacy Pass.
> Additionally, they have the same number of rounds and same number of messages.  
> 
> This would avoid perhaps creating an entire new standard and having just a new section on the privacy pass draft?
> Hoping to help,
> --
> Michele.
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg