AK/Random is already the same as SecureRandom. See PR for more details.
ProcessPrng is used on Windows for compatibility w/ sandboxing measures
See e.g. https://crbug.com/40277768
There is no need to have `RSAPrivateKey`, `RSAPublicKey`, `ECPrivateKey`
and `ECPublicKey` to be templatize to utilize different implementation
of numbers.
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.
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.
This commit replaces the old implementation of `EMSA_PKCS1_V1_5` with
one backed by OpenSSL. In doing so, the `sign` and `verify` methods of
RSA have been modified to behave like expected and not just be
encryption and decryption.
I was not able to split this commit because the changes to `verify` and
`sign` break pretty much everything.
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.
Replace our slow, possibly incorrect RSA key generation with OpenSSL.
This should fix many WPT tests that are timing out because we were too
slow at computing keys.
This adds a thin wrapper to LibCrypto for generating cryptographically
secure random values and replaces current usages of PRNG within
LibCrypto as well.
Ensure becomes `m1` greater than `m2` even when smaller by more than
one `p`. Since the next operations on `m1` are modulus `p` we can add it
as many times as it's needed.
Previously, if `nullptr` was passed as params for
`wrap_in_private_key_info` or `wrap_in_subject_public_key_info` an ASN1
null was serialized. This was not the intended behaviour for many.
The issue was discovered while implementing `wrapKey` and `unwrapKey` in
the next commits.
The textbook RSA decryption method of `c^d % n` is quite slow. If the
necessary parameters are present, the CRT variant will be used.
Performing RSA decryption this way is ~3 times faster.
- Removed the constructor taking a (n, d, e) tuple and moved
it to `RSAPrivateKey`
- Removed default constructor with key generation because it was always
misused and the default key size is quite small
- Added utility constructors to accept a key pair, public key, private
key or both
- Made constructor parameters const
- Updated test to use generated random keys where possible
In order for public/private key serialization to work correctly we must
store the size of the key because P-521 cannot be stored as full words
inside `UnsignedBigInteger` and therefore is exported as the wrong
length (68 instead of 66).
This makes it also possible to refactor some methods and cleanup
constants scattered around.
Gets almost all import/export tests, expect the JWK ones that calculate
the public key on export. The `SECPxxxr1` implementation currently fails
to do calculations for P-521.
The decoding inside `RSA::parse_rsa_key` is quite complex because it
tries to understand if it's decoding PKCS#8 or PKCS#1. Simplify the code
by moving the burden to the PEM decoder.
Added basic EC private and public key definitions as well as ASN.1
encoding and decoding.
A lot of refactoring can be made around the ASN.1 processing (here and
in other parts of the codebase) by utilizing what is available
in `LibCrypto::Certificate` as macros, but I think it's outside the
scope of implementing ECDH support for WebCryptoAPI.
Add support for encoding parameters in `wrap_in_private_key_info` and
`wrap_in_subject_public_key_info` as well as turn `Span<int>` into
`Span<int const>`.
