RE: RSA blind signatures

I guess I disagree on this one,, while that may be a goal in TC39 there is still value in making this an API for this group, and TC39 can take it father if they so want/need, but there is a need for some functions so we can support algorithms (signature, encryption, etc. ) outside the standard ones, this is both is a browser and non-browser environments

From: Alex Russell []
Sent: Friday, November 30, 2012 5:36 AM
To: Ryan Sleevi
Cc:; Acar, Tolga; Mike Jones; Stefan Xenon
Subject: Re: RSA blind signatures

What Ryan said.

As a TC39 member, let me second the sentiment that bignum support does not belong in an API. It should be done with full operator support and arbitrary precision if we're ever to have a hope of making bigger storage classes usable by mere mortals. I also recommend Ryan's approach: ask for the highest level thing you think you can get away with as that'll give implementations room to optimize while we figure out BigNum and BigInt in ES7.

On Nov 26, 2012 5:01 PM, "Ryan Sleevi" <<>> wrote:
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 <<>> 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 [<>]
> Sent: Friday, November 23, 2012 10:57 PM
> To: Stefan Xenon;<>;<>
> 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:<>;<>
> 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" <<>
>> <<>>> wrote:
>>     Hi!
>>     We are developing a system (<>
>>     <>) 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 Friday, 30 November 2012 16:51:16 UTC