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

Re: RSA blind signatures

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 26 Nov 2012 17:00:43 -0800
Message-ID: <CACvaWva8sq9C3_LxMY1ZM0YSbqnNgjVq05OuKH_YfFB7P81B_Q@mail.gmail.com>
To: "Acar, Tolga" <tolga.acar@intel.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, Stefan Xenon <stefanxe@gmx.net>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
BigNums have been discussed in the past in TC39 (aka the ECMAScript
standardization), and I believe need a new champion for that group.

I do think that they *do not* belong in this WG. BigNums are not
really a DOM concept, and the arguments for why "native JS" isn't
suitable for crypto I think highlights why a BigNum API in the DOM (as
opposed to the Javascript VM) is a Bad Thing(tm).

That said, if anyone is considering implementing polyfilled crypto
APIs via a BigNum interface, without support of the JVM, I would
suggest that "They're doing it wrong," since it's going to have all of
the problems that existing polyfilled APIs do today - lack of constant
time comparison, lack of correctness guarantee, possible Javascript VM
optimization hijinks, etc. So the argument for supporting a
cryptographic API - as opposed to something like fractal images or
formula - seems problematic.

If the argument is that "This is safe in other contexts" (SysApps or
platforms that use "technologies used on the Web" but are NOT "the
Web"), then I think it's a further case for TC39, as it's more about
using JavaScript as a fundamental language than it is about the web

For the purposes of blind signatures, I would suggest the proposal
instead would be to propose an algorithm and parameters for handling
blind signatures (or how the existing algorithm and parameters
can/should be adjusted) for discussion, rather than advocating a 'roll
your own'.

On Mon, Nov 26, 2012 at 4:45 PM, Acar, Tolga <tolga.acar@intel.com> wrote:
> 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 01:01:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:49 UTC