W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > November 2012

RE: RSA blind signatures

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tue, 27 Nov 2012 21:43:50 +0000
To: Ryan Sleevi <sleevi@google.com>
CC: "Acar, Tolga" <tolga.acar@intel.com>, Mike Jones <Michael.Jones@microsoft.com>, Stefan Xenon <stefanxe@gmx.net>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
Message-ID: <eda176e14b6545988b3cf84d85ba6e6d@BY2PR03MB041.namprd03.prod.outlook.com>
There is increasing pressure for additional signature algorithms (blind signatures are one of them), to support these we need some math capabilities on the client to be able to do these type of signature algorithms, we also have many non browser based JS environments that this would need to be available so this is not just a polyfill issue. The charter does not limit us on providing these types of functions

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Tuesday, November 27, 2012 11:47 AM
To: Anthony Nadalin
Cc: Acar, Tolga; Mike Jones; Stefan Xenon; public-webcrypto-comments@w3.org
Subject: Re: RSA blind signatures

On Tue, Nov 27, 2012 at 11:20 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
> I don't believe it's outside the current charter at all, please point 
> to where you think this violates the current charter, I also don't 
> believe the sole purpose of this group is to avoid polyfilling

Sorry, I should have been clearer. The *main* point, not the *sole* point.

As far as the charter, for the same reason I don't think it's necessary for the charter to say that the File API is out of scope (even though you may want to do encrypted files), I would think the notable *absence* of anything regarding big integers support, and instead the focus on how big integers are used (signing, encryption), was self-evident that this API is operating at a layer higher than big integers. Given that several members have expressed surprise that we're even talking as low-level as "algorithms" (as opposed to JOSE-style constructs that describe ciphersuites) seems to me that it's well understood that anything lower level/more primitive was not part of our work product.

If people want big integer support, it can easily be polyfilled - SJCL is a proof positive of this. In today's world of Javascript optimizing VMs, the performance implications alone are one that require careful measurement and concern. Categorically, the mere overhead of having to marshal through the DOM, under the existing DOM+JS implementations (V8, SpiderMonkey, Nitro, Chakra) quickly exceeds the implied performance gains from architecture specific operations (PCMPEQQ, PCMPGTQ, etc). Having it as a fundamental Ecmascript type fully allows for the JS engine to JIT out optimized assembly without the overhead of a DOM roundtrip - and is fully suitable for non-DOM backed implementations (eg: the node.js's of the world).

Further, polyfilling cryptographic operations via bigint invariably begs further feature creep - for example, can/should there be a secure memory comparison function native (to the DOM? To Javascript?). Can you efficiently or accurately polyfill algorithms without it, given the different JITing strategies of the different engines that can quickly cause you to leak timing information. An example thought experiment of this is the engine deciding that the memory comparison function was a hotpath mid-execution, and thus JITing it and transferring control to the JITted function, which would then allow an attacker, on a per-engine basis (which is fine, given that browsers typically only ship with one engine), to exploit timing to determine how far in the loop the comparison executed.

It's for reasons like these (and the many more presumed implied) that this API tries to provide the "high level" (by comparison to big int, "low level" compared to DOMCrypt) algorithm-based API. Just like PKCS#11, CryptoAPI, CNG, CDSA/CSSM, and NSS do not define big integer APIs, I do not think we should either.

>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Tuesday, November 27, 2012 11:17 AM
> To: Anthony Nadalin
> Cc: Acar, Tolga; Mike Jones; Stefan Xenon; 
> public-webcrypto-comments@w3.org
> Subject: Re: RSA blind signatures
>
> On Tue, Nov 27, 2012 at 10:55 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>> Just not sure I follow the logic from this thread, we are propose 
>> other function that is needed for various crypto functions, why not the bigint?
>
> Because we're specifically not proposing something that low-level. The only reason you need bigint is to polyfill something. The whole point of this API is so that you don't have to polyfill something.
>
>> When it comes to blind signatures there are several ways to do that, 
>> we have the requirement to be able to use blind signatures (not 
>> Chaum's RSA) within the browser, we also need bigint. So we are in favor of this proposal.
>
> There has not been a proposal. This is a question about something outside of our charter. The question at hand is whether or not to recharter to embrace this feature.
>
> I strongly oppose rechartering, since this is clearly an issue of the language, and not of user agents. If Javascript wishes to support arbitrary precision integers, as opposed to the current types today, then it should be done in TC39. Given that TC39 has discussed this in the past, I see no value in us taking up that mantle.
>
> This is especially true because, within this group, the only reason to 
> talk bigints is to talk about polyfilling (whether ZRTP, arbitrary 
> KDFs from DH shared secrets, blind signatures, or vanity crypto), and 
> I would argue that the entire purpose of this group is to avoid the 
> need for polyfilling (which you can already do today - see, for 
> example, SJCL)
>
>>
>>
>>
>> From: Acar, Tolga [mailto:tolga.acar@intel.com]
>> Sent: Monday, November 26, 2012 4:45 PM
>> To: Mike Jones; Stefan Xenon; public-webcrypto-comments@w3.org; 
>> sleevi@google.com
>>
>>
>> Subject: RE: RSA blind signatures
>>
>>
>>
>> Although I, too, would like to work on and use a bigint API in js, I 
>> am much less inclined to augment the web crypto API with a general 
>> purpose bigint API that looks more like math (group operations in
>> particular) than crypto library. If there is interest in a bigint API 
>> in js, and it looks like there is, that should come under separate 
>> cover instead of being mixed with the Web Crypto API. So, what does 
>> that "separate cover" mean? A new WG, a natural extension of this WG?
>>
>>
>>
>> -          Tolga
>>
>>
>>
>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
>> Sent: Friday, November 23, 2012 10:57 PM
>> To: Stefan Xenon; public-webcrypto-comments@w3.org; sleevi@google.com
>> Subject: RE: RSA blind signatures
>>
>>
>>
>> For what it's worth, I know of other groups interested in native 
>> speed bigint math in JavaScript.
>>
>> -- Mike
>>
>> ________________________________
>>
>> From: Stefan Xenon
>> Sent: 11/23/2012 8:15 AM
>> To: public-webcrypto-comments@w3.org; sleevi@google.com
>> Subject: Re: RSA blind signatures
>>
>> Hi Ryan,
>> by any chance, could we propose such bigint API? If this would have a 
>> realistic chance, how is the process to move forward?
>>
>> Regards
>> Stefan
>>
>> Am 23.11.2012 18:43, schrieb Ryan Sleevi:
>>> A bigint API has not been proposed.
>>>
>>> On Nov 23, 2012 1:47 AM, "Stefan Xenon" <stefanxe@gmx.net 
>>> <mailto:stefanxe@gmx.net>> wrote:
>>>
>>>     Hi!
>>>     We are developing a system (www.opencoin.org
>>>     <http://www.opencoin.org>) which uses Chaum's RSA
>>>     blind signatures. Of course I don't expect the Web Crypto API to
>>>     natively support blind signatures. Instead we would like to utilize
>>>     "raw" big integer operations to speed up our calculations. But In your
>>>     current draft I couldn't find such basic operations exposed to web
>>>     applications. Primarily we would need big integer operations for
>>>     exponentiation and inverting (both modulo). Did I overlook such
>>>     functions? Or would it be possible for your API to expose such 
>>> functions
>>>     to web applications?
>>>
>>>     Regards,
>>>     Stefan
>>>
>>>
>
>
>
>
Received on Tuesday, 27 November 2012 21:47:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 November 2012 21:47:45 GMT