SignedBigInteger::operator==(const UnsignedBigInteger&) was rejecting
all negative value before testing for equality. It now accepts negative
zero and test for a value equality with the UnsignedBigInteger.
Instead we just use a specific constructor. With this set of
constructors using curly braces for constructing is highly recommended.
As then it will not do too many implicit conversions which could lead to
unexpected loss of data or calling the much slower double constructor.
Also to ensure we don't feed (Un)SignedBigInteger infinities we throw
RangeError earlier for Durations.
This means it can take any (un)signed word of size at most Word.
This means the constructor can be disambiguated if we were to add a
double constructor :^).
This requires a change in just one test.
This allows using different options for rounding, like IEEE
roundTiesToEven, which is the mode that JS requires.
Also fix that the last word read from the bigint for the mantissa could
be shifted incorrectly leading to incorrect results.
SignedBigInteger can immediately use this by just negating the double if
the sign bit is set.
For simple cases (below 2^53) we can just convert via an u64, however
above that we need to extract the top 53 bits and use those as the
mantissa.
This function currently does not behave exactly as the JS spec specifies
however it is much less naive than the previous implementation.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
These are mostly minor mistakes I've encountered while working on the
removal of StringView(char const*). The usage of builder.put_string over
Format<FormatString>::format is preferrable as it will avoid the
indirection altogether when there's no formatting to be done. Similarly,
there is no need to do format(builder, "{}", number) when
builder.put_u64(number) works equally well.
Additionally a few Strings where only constant strings were used are
replaced with StringViews.
The ASN.1 decoder was originally using AK::BitmapView for decoded
BitStrings, however the specification requires that the bits are stored
in a byte from the most significant to the least significant.
Storing three bits '110' would result in a byte '1100 0000', i.e. 0xC0.
However, AK::BitmapView expects the bits to be stored at the bottom like
'0000 0110', i.e. 0x06. For the current uses the data was always a
multiple of eight bits, resulting in complete bytes, which could
directly be interpreted correctly.
For the implementation of the key usage extension of certificates the
correct implementation of the BitString is required.
ASN.1 encodes booleans as false is zero and true is non-zero. The
decoder currently returned true when the boolean was zero.
Since this decoder was barely used it did not cause any problems,
however for support of other certificate extensions the correct version
is required.
In this format the year is specified using two digits. In the case that
these digits are 50 or more, we should assume that the year is in
1950-1999. If it is 49 or less, the year is 2000-2049.
This is specified in RFC5280 section 4.1.2.5.1.
The SHA384 and SHA512 hashes would produce incorrect results for data
where the length % 128 was in the range 112-119. This was because the
total number of bits in the hashed values was added at the end as a
64-bit number instead of a 128-bit number. In most cases this would not
cause any issues, as this space was padded with zeroes, however in the
case that the length % 128 was 112-119, some incorrect data ended up
where this 128-bit length value was expected.
This change fixes the problems in LibTLS where some websites would
result in a DecryptError on handshake.
All the elliptic curve implementations had a long list of private
methods which were all stored in a single .cpp file. Now we simply use
static methods instead.
Add the required methods to SECP256r1 to conform to the EllipticCurve
virtual base class. Using this updated version of SECP256r1, support in
LibTLS is implemented.
These changes generalize the interface with an elliptic curve
implementation. This allows LibTLS to support elliptic curves generally
without needing the specifics of elliptic curve implementations.
This should allow for easier addition of other elliptic curves.
This implementation of the secp256r1 elliptic curve uses two techniques
to improve the performance of the operations.
1. All coordinates are stored in Jacobian form, (X/Z^2, Y/Z^3, Z), which
removes the need for division operations during point addition or
doubling. The points are converted at the start of the computation,
and converted back at the end.
2. All values are transformed to Montgomery form, to allow for faster
modular multiplication using the Montgomery modular multiplication
method. This means that all coordinates have to be converted into
this form, and back out of this form before returning them.
CRC32 table is generated at compile-time and put into a static
variable in the header file. This can be moved to be a function
instead of a class, be moved to the `.cpp` file` and generated as an
array instead of a class which only implements `operator[]`.
This will verify that the signature of the ephemeral key used in the
DHE and ECDHE key exchanges is actually generated by the server.
This verification is done using the first certificate provided by the
server, however the validity of this certificate is not checked here.
Instead this code expects the validity to be checked earlier by
`TLSv12::handle_certificate`.
This add an implementation for the EMSA-PKCS1-V1_5-ENCODE function from
RFC8017 section 9.2. The verification of this encoding is implemented by
simply encoding the message to be verified, and then comparing the two
encoded string.
The digest info for the different hash function is from RFC8017 section
9.2 notes 1. These byte sequences are actually ASN.1 encoded data,
however these are always constant for a specific hash function and can
be treated as opaque byte sequences.
If a big integer were to become negative zero, set the sign to instead
be positive. This prevents odd scenarios where users of signed big ints
would falsely think the result of some big int arithmetic is negative.
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
Removes the UnsignedBigInteger overloads of
SignedBigInteger::binary_{and,or,xor}(). They're now unused, and they
also didn't work when *this was negative.
We went through some trouble to make & and | work right. Reimplement ^
in terms of & and | to make ^ work right as well.
This is less fast than a direct implementation, but let's get things
working first.
Similar to the bitwise_and change, but we have to be careful to
sign-extend two's complement numbers only up to the highest set bit
in the positive number.
Bitwise and is defined in terms of two's complement, so some converting
needs to happen for SignedBigInteger's sign/magnitude representation to
work out.
UnsignedBigInteger::bitwise_not() is repurposed to convert all
high-order zero bits to ones up to a limit, for the two's complement
conversion to work.
Fixes test262/test/language/expressions/bitwise-and/bigint.js.
Bitwise operators are defined on two's complement, but SignedBitInteger
uses sign-magnitude. Correctly convert between the two.
Let LibJS delegate to SignedBitInteger for bitwise_not, like it does
for all other bitwise_ operations on bigints.
No behavior change (LibJS is now the only client of
SignedBitInteger::bitwise_not()).
