- From: <bugzilla@jessica.w3.org>
- Date: Tue, 22 Sep 2015 19:08:23 +0000
- To: public-webcrypto@w3.org
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