Re: [CFRG] Call for adoption for draft-wood-cfrg-rsa-blind-signatures

Jeff Burdges <burdges@gnunet.org> Tue, 27 April 2021 18:28 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 920B33A1B1E for <cfrg@ietfa.amsl.com>; Tue, 27 Apr 2021 11:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WZpKvLK-pHCn for <cfrg@ietfa.amsl.com>; Tue, 27 Apr 2021 11:28:54 -0700 (PDT)
Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55793A1B1B for <cfrg@irtf.org>; Tue, 27 Apr 2021 11:28:39 -0700 (PDT)
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 0731A1C00D2; Tue, 27 Apr 2021 20:30:33 +0200 (CEST)
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: <CAMr0u6njjMkmmAhFg3t+0EJOuh=q4towqi4j=hk9-russTbXDA@mail.gmail.com>
Date: Tue, 27 Apr 2021 20:28:27 +0200
Cc: CFRG <cfrg@irtf.org>, Taler <taler@gnu.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <74CC6D18-B7B0-4FF8-A227-463434C250C9@gnunet.org>
References: <CAMr0u6njjMkmmAhFg3t+0EJOuh=q4towqi4j=hk9-russTbXDA@mail.gmail.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/L6FVK7WtcRRWzwZ_CHJQ5fay-YY>
Subject: Re: [CFRG] Call for adoption for draft-wood-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: Tue, 27 Apr 2021 18:29:00 -0000

I previously raised an objection to PSS padding in blind RSA over both confusion concerns as well as absence of security arguments.  I agree with Mihir Bellare that Blind RSA with PSS padding and rejection sampled aka FDH blinding factors looks secure, but actually technically nobody yet made this claim concrete.  Anyways..

We need a strong clarification that blinding factors should be rejection sampled from the RSA group, meaning same bit width and rejection if they exceed the modulus.  I’ve some GCD test in GNU Taler’s code but that’s unnecessary since n - phi(n) = pq - (p-1)(q-1) = p + q -1 << n. 

Implementations that produce produce blinding factors using floor(log_2 n) bits provide no appreciable anonymity.  It’s a trivial attack:  An exchange computes isig[i] / rsig[j] for all issued signatures isig[i] and all redeemed signatures rsig[j].  Anytime i and j correspond then isig[i] / rsig[j] gives a blinding factor, so if blinding factors leak half a bit of entropy, then the exchange deanonymizes the user after only a few spent coins, usually only one transaction.

Implementations that produce blinding factors using the PSS code deanonymize users with only one coin!  I’d say blinding factors are the most important part of the document.

It’s obviously simplest if one spells out an FDH once and then reuses it for both the signature and blinding factor, so it’s better if a draft provides this option.  I’d imagine GNU Taler would continue using this approach, meaning RSA-FDH should see deployment eventually.  

I also accept Christopher Wood’s argument that reusing existing RSA-PSS verification code provides value too.

In short, fix the blinding factors, make a big deal about them, and maybe support RSA-FDH and RSA-PSS variants. 

Best,
Jeff



> On 25 Feb 2021, at 17:38, Mihir Bellare <mihir@eng.ucsd.edu> wrote:
> On Wed, Feb 24, 2021 at 10:45 PM Jeff Burdges <burdges@gnunet.org> wrote:
> 
> > Bellare and Rogaway suggested PSS over FDH because PSS provides a tighter security argument than FDH, due to the signer providing randomness, i.e. purely a provable security reason.
> 
> The proofs for RSA-FDH and RSA-PSS as normal signatures are from the one-wayness assumption on RSA. As you say, the reduction for RSA-PSS is tight, and that for RSA-FDH is not. The proof for Blind-RSA-FDH is from the One-More Discrete Log (OMDL) problem, and this would also be the case for Blind-RSA-PSS. I have not done the latter proof in detail, so this is just a guess, but I don't see a difference in tightness between the two. So from the point of view of tightness of security arguments, my guess is that Blind-RSA-FDH and Blind-RSA-PSS are about the same. I understand of course that there may be many other factors and reasons to prefer one over the other.
> 
> PSS, when used as a normal signature, can be de-randomized in the usual way of deriving the randomness by hashing the secret signing key and the message, but this does not seem to apply in the blind case.
> 
> Mihir



> 
> On 18 Mar 2021, at 10:21, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
> 
> Dear CFRG participants,
> As a follow-up to the discussion at the recent CFRG meeting, this email commences a 3-week call for adoption for "RSA Blind Signatures" draft (draft-wood-cfrg-rsa-blind-signatures-00) that will end on April 9th 2021:
> 
> https://datatracker.ietf.org/doc/draft-wood-cfrg-rsa-blind-signatures/
> 
> Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it. Please reply to this email (or in exceptional circumstances you can email CFRG chairs directly at cfrg-chairs@ietf.org).
> 
> Thank you,
> Stanislav (for the chairs)
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg