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 19:47:36 UTC