This has quite a lot of fall out. But the majority of it is just type or
UDL substitution, where the changes just fall through to other function
calls.
By changing property key storage to UTF-16, the main affected areas are:
* NativeFunction names must now be UTF-16
* Bytecode identifiers must now be UTF-16
* Module/binding names must now be UTF-16
This helps make callers only use the slice of the output buffer that
was written to.
As part of updating the callers of the API several bugs were fixed and
useless code paths were removed:
- The exported data is not host-endianess dependent (always big endian)
- The exported data does not contain leading zeros
- The output buffer is only written up to the result's size
We have a bunch of TODO/FIXME about supporting applicable specifications
for algorithms that are not mentioned in the spec. There is no plan to
have any, there is nothing to do as of now.
This is wrong and leads to invalid numbers. We've been kind of
unfortunate in not catching this earlier because we skipped the key
validation part.
Many tests would fail with the next commits if this wasn't fixed.
There is no need to have `RSAPrivateKey`, `RSAPublicKey`, `ECPrivateKey`
and `ECPublicKey` to be templatize to utilize different implementation
of numbers.
Fix various TODO by checking the validity of ECDSA and ECDH keys when
they are imported. There are no checks in place for raw import because
the spec doesn't contemplate them yet.
Also add some internal tests since WPT doesn't seem to provide them.
Replace the implementation of maths in `UnsignedBigInteger`
and `SignedBigInteger` with LibTomMath. This gives benefits in terms of
less code to maintain, correctness and speed.
These changes also remove now-unsued methods and improve the error
propagation for functions allocating lots of memory. Additionally, the
new implementation is always trimmed and won't have dangling zeros when
exporting it.
The fast path of to_i32() can be neatly inlined everywhere, and we still
have to_i32_slow_case() for non-trivial conversions.
For to_u32(), it really can just be implemented as a static cast to i32!
Our `UnsignedBigInteger` implementation cannot handle numbers whose
size is not a multiple of 4. For this reason we need to carry the real
size around for P-521 support.
This replaces the old `OAEP` implementation with one backed by OpenSSL.
The changes also include some added modularity to the RSA class by
making the `RSA_EME` and `RSA_EMSE` for encryption/decryption and
signing/verifying respectively.
It used to be that the caller would supply a buffer to write the output
to. This created an anti-pattern in multiple places where the caller
would allocate a `ByteBuffer` and then use `.bytes()` to provide it to
the `PKSystem` method. Then the callee would resize the output buffer
and reassign it, but because the resize was on `Bytes` and not on
`ByteBuffer`, the caller using the latter would cause a bug.
Additionally, in pretty much all cases the buffer was pre-allocated
shortly before.
Make sure that `HashAlgorithmIdentifier` is passed through
`normalize_an_algorithm` to verify that the hash is valid and supported.
This is required by the spec, but we are not following it very strictly
in `normalize_an_algorithm` because it is pretty convoluted.
Fixes ~60 tests.
Fixes multiple slightly wrong behaviours of the `deriveBits` method
across various algorithms. Some of them might be due to a spec update.
Add tests related to fixes.
Add support for AES-KW for key wrapping/unwrapping. Very similar
implementation to other AES modes.
Added generic tests for symmetric import and specific AES-KW ones.
Adds ~400 test passes on WPT. Now we do better than Firefox in
`WebCryptoAPI/wrapKey_unwrapKey`!
The ASN1 structure for PCKS#8 was wrong and missing one wrapping of the
key in a OctetString.
The issue was discovered while implementing `wrapKey` and `unwrapKey` in
the next commits.