From nobody Thu Feb 25 04:32:41 2021 Return-Path: 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 C53693A17EF for ; Thu, 25 Feb 2021 04:32:39 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=zpEot6pq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=amf1VHEe 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 rVd7WpARbjvA for ; Thu, 25 Feb 2021 04:32:38 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0448A3A16A7 for ; Thu, 25 Feb 2021 04:32:37 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id CDA0F5C00FE; Thu, 25 Feb 2021 07:32:36 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Thu, 25 Feb 2021 07:32:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=SF ez/CCEQktGG4FXMvtpetRpg7EDYtcO0sO9QLwzYpY=; b=zpEot6pqCV8N7HtqjC Kfv/1zvopkIPr7iDsHw8H9vDiipxeQsD6u7xNGaf6xyaL5frkyS5BeI3WzlOqB8f OUkvmMWhxMUT1hG/0c0eg/CWzRnAgLcbanI42p87qnqRYzqAX9vM+UWtlYMjdAFP xftio9WqQg44TvNLAFM1Zv35pt6+VsyOyty3ChE+9uL1HJkWVHMa6ADqi3BvawrC Ujb8xCsTc/XaPFL8m+hLXi/et54AGR3OlopNox4tQtcFrpOTlTd32WbpBLPrbwo5 RmYpCT+fHmdiVZqIPpkFYEXxIzPISnGcjS4xoekr98dpXmZu1afsruBWG4HbtOL/ PomA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=SFez/CCEQktGG4FXMvtpetRpg7EDYtcO0sO9QLwzY pY=; b=amf1VHEedGDAmJEPZqUeHh4H22pORz7pNo+p+hydtiavJMbaSPuQGmFIg 9nn2d+w9F4//iUPQgRKEg3leCDi2peCJ9bUpiOybbNa3nrXIJGAzq2DoFw+jm5id JFUg39iwrAxgGrl0x+FHd1DKTwcDxeDFPKHNHv1WGmOl5BmmzWObrJ/OY5HqUipp 09cW3ZLRNE86LJGHRCCxQIZ+z4hmZQwUq+bvx3hGPWdPA0EfrnZ+sCDblXbZQoqL I+tBQgcCr6zYqUoJFKlpFx6Ojgz3s61n44YIaqvYj3tc3Lb7qALCZrXQ0XuSH+tn ULFPrSVX8HHHTyxQ28pBXA/naU6iQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeelgdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepteekudelvefhgeeigeetteejuefhueekueelkedtudei hfdtgfeghedttdevudelnecuffhomhgrihhnpehutggurghvihhsrdgvughupdhirggtrh drohhrghdpshhouhhrtggvfhhorhhgvgdrihhonecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E92AA1600AB; Thu, 25 Feb 2021 07:32:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: References: <44983891-284f-4552-b4c7-bc432148d214@www.fastmail.com> <19E2AA22-2B2B-4BCB-8171-B6386D39C616@gnunet.org> Date: Thu, 25 Feb 2021 04:32:14 -0800 From: "Christopher Wood" To: "Jeff Burdges" Cc: "IRTF CFRG" , Taler Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 12:32:40 -0000 On Wed, Feb 24, 2021, at 10:44 PM, Jeff Burdges wrote: >=20 >=20 > > On 25 Feb 2021, at 00:25, Christopher Wood wro= te: > >> If I recall, RSA-PSS depends upon signer randomness for its securit= y=20 > >> arguments. As such, one should ideally not base an RSA blind signa= ture=20 > >> off PSS but instead specify a full domain hash (FDH). =20 > >=20 > > Is this a useful distinction? Blind RSA in general requires randomne= ss for it to be useful (as you carefully point out above).=20 >=20 > That=E2=80=99s randomness by the token holder. I=E2=80=99m taking abo= ut randomness=20 > held by the issuer. Perhaps I'm missing something, but my point was the following: Clients, = who actually encode messages -- either via FDH or PSS -- require randomn= ess to blind their message sent to the server. Servers (issuers), in con= trast, deterministically sign the blinded message sent to them. (They ho= pefully also include some variant of blinding to mitigate obvious side c= hannels, but that's an implementation detail.) =20 > Bellare and Rogaway suggested PSS over FDH because PSS provides a=20 > tighter security argument than FDH, due to the signer providing=20 > randomness, i.e. purely a provable security reason. > https://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf >=20 Indeed. This, along with availability, is primarily what led to PSS in t= his case.=20 > > In any case, the rationale for PSS was two-fold: > >=20 > > 1) It's widely supported in libraries. (To my knowledge FDH is not w= idely supported... yet.) >=20 > We verify RSA blind signatures roughly three times in a typical token=20= > deployment, once by the user after token issuance as part of the=20 > signing algorithm, once by the merchant upon tokens being spent, and=20= > once by the exchange upon tokens finally being redeemed. As the signe= r=20 > code must change, only the merchant code justifies a gymnastics for=20= > support of existing libraries. >=20 > > 2) One can basically replicate FDH with a zero-length salt, even tho= ugh some APIs make it difficult to do so. >=20 > Is a zero length salt secure? It=E2=80=99s likely "less" secure than = an FDH=E2=80=99s=20 > rejection sampling, but do we know if a security proof exists or if it= =20 > de facto becomes roughly PKCS#1 v1.5 like?=20 I'm not an expert, and I'm certainly not advocating for it, but 2019/126= 8 [1] seems to suggest it's safe. Best, Chris [1] https://eprint.iacr.org/2019/1268.pdf > We cannot abuse the salt to perform rejection sampling since presumabl= y=20 > the three components in PSS=E2=80=99 output, maskedDB, H, and bc all a= void the=20 > high bit, which gets set like 1/3rd of the time. >=20 > Jeff >=20 > p.s. An FDH consumes the input message using hash function with=20 > extensible output, like shake, blake2x, ad hoc hash plus stream cipher= =20 > constructions, or strobe https://strobe.sourceforge.io and then=20 > produces first the low order log_2 n + 1 - k output bits L where k =3D= =20 > 128 or 256, and then it produces the high k output bits H using=20 > rejection sampling, i.e. loop until (H || L) < n. It=E2=80=99s probab= ly fine=20 > if the whole output were rejection sampled all at once, slightly slowe= r=20 > but the performance loss sounds minor given the arithmetic. =20 >=20 >=20 >=20 >