[Bug 29139] Allow specifying numbers in place of BigInteger?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29139

--- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Eric Roman from comment #0)
> This is feature request to re-define BigInteger from:
>   typedef Uint8Array BigInteger;
> To:
>   typedef (unsigned long or Uint8Array) BigInteger

I think this would be a very dangerous change, and not desirable, even though
appealing for a convenience wrapper.

Because such a type would go through normalization in the JS<->WebIDL
conversion, it would also allow things like "65537" or "no" to be accepted as
inputs, or perhaps even more confusingly, { "toString": function() { return
"0"; } }.

This is because of the ToNumber(v) step in
http://heycam.github.io/webidl/#es-unsigned-long . "no" would be NaN, which
would raise a TypeError in this specific case, while "65537" would be directly
converted.

It's also of questionable utility that a generic BigInteger should be
convertible from a Number, given the precision issues that various ES
implementations have (although admittedly, perhaps those issues are resolved in
ES5/ES6, and I'm operating on old knowledge). As it relates to WebCrypto's
usage, it only really seems to come up with publicExponent - the prime/base of
the DhKeyGenParams / DhKeyAlgorithm / DhImportParams don't lend themselves to
expressions as Numbers (they're necessarily large integers)

The publicExponent for RSA is the interesting one, because that's the only real
place this would be useful. Unfortunately, the API itself is quite dangerous
here that it's exposed directly as a BigInteger. In hindsight, it may have made
more sense to do an enum of the Fermat primes (65537 is also known as F_4 in
many implementations). The shape of the API was driven by the at-the-time
concern of the need to support smart cards / existing crypto, which
necessitated support for F_1 (aka 3), although using 3 as the exponent for an
RSA key makes Bleichenbacher's Attack a more pen-and-paper exercise (
http://cryptopals.com/sets/6/challenges/42/ ). Alternatively, leaving
publicExponent as an unsigned long (since 65537 is the only sane value) would
also have made sense.

But I don't support changing the definition of BigInteger as a whole. I think
that just makes the bad situation worse.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 22 September 2015 19:08:28 UTC