23445 2013-10-07 10:05:19 +0000 typo with BigInteger? 2014-01-28 18:44:02 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC All RESOLVED FIXED P2 minor --- 1 info watsonm ap info watsonm oldest_to_newest 94386 0 info 2013-10-07 10:05:19 +0000 16. BigInteger reads "A leading zero Uint8 element is not needed if the most significant bit of the integer is set." Shouldn't it be the other way around, "A leading zero Uint8 element is not needed if the most significant bit of the integer is NOT set." 98918 1 watsonm 2014-01-23 00:44:42 +0000 (In reply to Franz Antesberger from comment #0) > 16. BigInteger reads "A leading zero Uint8 element is not needed if the most > significant bit of the integer is set." > Shouldn't it be the other way around, > "A leading zero Uint8 element is not needed if the most significant bit of > the integer is NOT set." I don't think that sentence is required at all. The rest of the definition is unambiguous, although "multiple-precision" could be replaced with "arbitrary magnitude" (integers have exactly the 'precision' that they have, nothing else). 99090 2 info 2014-01-25 21:22:58 +0000 We have two things to be considered: 1) What do we need for a minimum? 2) What do all the others? First to 2) All the others (bouncy castle, openssl) - use big endian (as here) - use leading zeros, when the high bit is set - leading zeros are done bytewise, not wordwise 2nd to 1) what should we do here? - I think, BigInteger should be bound to ArrayBuffer, not to Uint8Array. Calculation with Uint32Arrays is MUCH faster. - big endian is nice, but all the BigInt-Libs I know use little endian, is that an issue? We could easily build a wrapper - X.509 Certificates use little endian, byte arrays and leading zeros, if high byte >= 0x80. I completely agree with your "multiple-precision" argument. I think, we have two ways: a) we could replace "BigInteger" with "BigUnsignedInteger" -- then no leading zeros are needed. But the name does not sound well. b) we could use "BigInteger", but then please with leading zeros, if leading >= 0x80. I will try to make a complete proposal for this chapter next weekend 99164 3 watsonm 2014-01-27 16:41:51 +0000 (In reply to Franz Antesberger from comment #2) > We have two things to be considered: > 1) What do we need for a minimum? > 2) What do all the others? > First to 2) > All the others (bouncy castle, openssl) > - use big endian (as here) > - use leading zeros, when the high bit is set > - leading zeros are done bytewise, not wordwise > 2nd to 1) > what should we do here? > - I think, BigInteger should be bound to ArrayBuffer, not to Uint8Array. > Calculation with Uint32Arrays is MUCH faster. > - big endian is nice, but all the BigInt-Libs I know use little endian, is > that an issue? We could easily build a wrapper > - X.509 Certificates use little endian, byte arrays and leading zeros, if > high byte >= 0x80. > > I completely agree with your "multiple-precision" argument. > > I think, we have two ways: > a) we could replace "BigInteger" with "BigUnsignedInteger" -- then no > leading zeros are needed. But the name does not sound well. > b) we could use "BigInteger", but then please with leading zeros, if leading > >= 0x80. > > I will try to make a complete proposal for this chapter next weekend - it seems safer to stick with big endian, since that is what we have had since the beginning - switching to ArrayBuffer is another issue (I filed bug 24409) - I don't understand the need for the leading 0x00 - it just introduces an error case that need not exist. I do understand why we might want to highlight to implementors that the top bit is not a sign bit, because this is an unsigned integer. A note would be sufficient for this, rather than a normative requirement. 99178 4 watsonm 2014-01-27 19:06:25 +0000 I propose replacing the existing text of this section with: "The BigInteger typedef is a Uint8Array that holds a arbitrary magnitude unsigned integer in big-endian order. Implementation note: Since the integer is unsigned, the highest order bit is NOT a sign bit. Implementors should take care when mapping to big integer implementations that expected signed integers." 99210 5 watsonm 2014-01-27 22:55:23 +0000 As discussed on call 1/27, we will require values read from the API to be in cannonical (most compact) form and will be tolerant of leading zero bits when values are passed to the API: "The BigInteger typedef is a Uint8Array that holds a arbitrary magnitude unsigned integer in big-endian order. Values read from the API SHALL have minimal typed array length (that is, at most 7 leading zero bits). The API SHALL accept values with any number of leading zero bits. Implementation note: Since the integer is unsigned, the highest order bit is NOT a sign bit. Implementors should take care when mapping to big integer implementations that expected signed integers." 99212 6 watsonm 2014-01-27 23:05:21 +0000 As discussed on call 1/27, we will require values read from the API to be in cannonical (most compact) form and will be tolerant of leading zero bits when values are passed to the API: "The BigInteger typedef is a Uint8Array that holds a arbitrary magnitude unsigned integer in big-endian order. Values read from the API SHALL have minimal typed array length (that is, at most 7 leading zero bits, except the value 0 which shall have length 8 bits). The API SHALL accept values with any number of leading zero bits. Implementation note: Since the integer is unsigned, the highest order bit is NOT a sign bit. Implementors should take care when mapping to big integer implementations that expected signed integers." 99224 7 watsonm 2014-01-28 00:15:18 +0000 https://dvcs.w3.org/hg/webcrypto-api/rev/33a21d9f624a 99323 8 info 2014-01-28 18:20:30 +0000 I think, it is a bad idea to restrict to unsigned -- there are a lot of funny things you can do with the Chineese Reminder Theorem, but there you need signed integers. And I think, it is a worse idea, calling it "BigInteger", when it is unsigned. All the Typed Arrays use a "U", when unsigned. So if restricting to unsigned, it should be renamed to "BigUInteger". One day we might need signed BigIntegers. For now we just store RSA-Keys, which really are unsigned The leading zeros come from the ASN.1 INTEGER type, see e.g. http://luca.ntop.org/Teaching/Appunti/asn1.html 99329 9 watsonm 2014-01-28 18:38:04 +0000 (In reply to Franz Antesberger from comment #8) > I think, it is a bad idea to restrict to unsigned -- there are a lot of > funny things you can do with the Chineese Reminder Theorem, but there you > need signed integers. > And I think, it is a worse idea, calling it "BigInteger", when it is > unsigned. All the Typed Arrays use a "U", when unsigned. So if restricting > to unsigned, it should be renamed to "BigUInteger". One day we might need > signed BigIntegers. > For now we just store RSA-Keys, which really are unsigned > I think you should raise a new bug "Make BigInteger signed or rename it" for this issue. > The leading zeros come from the ASN.1 INTEGER type, see e.g. > http://luca.ntop.org/Teaching/Appunti/asn1.html 99331 10 info 2014-01-28 18:44:02 +0000 Done, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24430