- From: Alex Russell <slightlyoff@google.com>
- Date: Fri, 30 Nov 2012 05:36:17 -0800
- To: Ryan Sleevi <sleevi@google.com>
- Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, "Acar, Tolga" <tolga.acar@intel.com>, Mike Jones <Michael.Jones@microsoft.com>, Stefan Xenon <stefanxe@gmx.net>
- Message-ID: <CANr5HFUrMv_PK1RA9WN3t484KR+D5JWuS3LDg7TNpm-cZix5sw@mail.gmail.com>
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. Regards On Nov 26, 2012 5:01 PM, "Ryan Sleevi" <sleevi@google.com> 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 > platform. > > 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 Friday, 30 November 2012 13:36:47 UTC