Our structured serialization implementation had its own bespoke encoder
and decoder to serialize JS values. It also used a u32 buffer under the
hood, which made using its structures a bit awkward. We had previously
worked around its data structures in transferable streams, which nested
transfers of MessagePort instances. We basically had to add hooks into
the MessagePort to route to the correct transfer receiving steps, and
we could not invoke the correct AOs directly as the spec dictates.
We now use IPC mechanics to encode and decode data. This works because,
although we are encoding JS values, we are only ultimately encoding
primitive and basic AK types. The resulting data structures actually
enforce that we implement transferable streams exactly as the spec is
worded (I had planned to do that in a separate commit, but the fallout
of this patch actually required that change).
Our currently implementation of structured serialization has a design
flaw, where if the serialized/transferred type was not used in the
destination realm, it would not be seen as exposed and thus we would
not re-create the type on the other side.
This is very common, for example, transferring a MessagePort to a just
inserted iframe, or the just inserted iframe transferring a MessagePort
to it's parent. This is what Google reCAPTCHA does.
This flaw occurred due to relying on lazily populated HashMaps of
constructors, namespaces and interfaces. This commit changes it so that
per-type "is exposed" implementations are generated.
Since it no longer relies on interface name strings, this commit
changes serializable types to indicate their type with an enum,
in line with how transferrable types indicate their type.
This makes Google reCAPTCHA work on https://www.google.com/recaptcha/api2/demo
It currently doesn't work on non-Google origins due to a separate
same-origin policy bug.
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.
Before this change, we were going through the chain of base classes for
each IDL interface object and having them set the prototype to their
prototype.
Instead of doing that, reorder things so that we set the right prototype
immediately in Foo::initialize(), and then don't bother in all the base
class overrides.
This knocks off a ~1% profile item on Speedometer 3.
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.
The spec never mentions the possibility for the `hash` member of
`RsaHashedKeyAlgorithm` to be a string, it should be a `KeyAlgorithm`
object containing a `name` string member.
Spec: https://w3c.github.io/webcrypto/#dfn-RsaHashedKeyAlgorithm
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`!
We do not concern ourselves with small OOM handling any longer. But the
main point of this patch is that we are for some reason getting a build
error with clang-19 here about ignoring a nodiscard return type inside
JsonArray::try_for_each.
This implements the last WebCryptoAPI methods `wrapKey` and `unwrapKey`.
Most of the functionality is already there because they rely on
`encrypt` and `decrypt`. The only test failures are for `AES-GCM` which
is not implemented yet.
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.
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.
