The `SignatureEncoding` impl added in `rsa` v0.9 (or more specifically,
the `From<Signature>` impl for `Box<[u8]>` failed to properly left pad
the signatures so they matched the modulus size.
This adds the appropriate padding to the signature encoder.
The `RsaPrivateKey` type previously had a `Deref` impl providing access
to the associated `RsaPublicKey`.
`Deref` is intended for "smart pointer types", i.e. container types
which manage a (typically generic) inner type in some way. This doesn't
seem like one of those cases.
`AsRef`, on the other hand, is for cheap reference conversions, which is
exactly what's happening here, so it's a better fit and provides the
same functionality (albeit explicitly rather than via deref coercion).
The padding mode modules have gotten quite large.
This commit refactors types into respective submodules, with the
toplevel module defining the same-named padding schemes.
There were several modules that defined traits, including one called
`traits`.
This consolidates all of them under `traits`, retaining the previous
module structure as internal submodules:
- `keytraits` => `traits::keys`
- `padding` => `traits::padding`
- `traits` => `traits::encryption`
Additionally this removes the traits that were re-exported at the
toplevel, instead re-exporting them all under `traits`.
Adds an on-by-default feature which enables `num-bigint-dig/u64_digit`.
Disabling this on 32-bit platforms (e.g. WASM) should improve
performance.
Closes#252
`RsaPrivateKey` self-zeroizes on drop, so add the `ZeroizeOnDrop` marker
trait to `RsaPrivateKey` and all newtypes thereof, i.e. `DecryptingKey`
and `SigningKey` for the various padding modes.
This also removes the `Zeroize` impl on `RsaPrivateKey`, since it
self-zeroizes on `Drop`, and allowing `Zeroize` might accidentally
permit use-after-zeroize vulnerabilities.
In both the PKCS#1v1.5 and PSS implementations, checks the signature
value to ensure it does not overflow the modulus.
In the PKCS#1v1.5 implementation, checks the signature length to ensure
it matches the public key size. The PSS implementation was already doing
this.
Closes#272
* feat: decouple key generation and random generation
Make generate_multi_prime_key_with_exp() generic enough to generate
abstract key structure. Rewrite RsaPrivateKey constructors to use
RsaPrivateKey::from_components().
* feat: move key-related traits to separate module
Move PublicKeyParts to the separate module.
* feat: stop using RsaPrivateKey in internals.rs
Make internals.rs generic enough to be moved to the algorithms module.
* feat: move soft RSA implementation to crate::algorithms::rsa.rs
Separate software RSA implementation to separate module under
crate::algorithms.
* key: drop raw_int_*_primitive wrappers
Now as raw_int_encryption_primitive() and raw_int_decryption_primitive()
became simple wrappers around properly defined functions we can inline
them and always use software RSA algorithm from src::algorithms::rsa.rs.
* feat: move internals.rs to src/algortihms/pad.rs
internals.rs now contains only small functions related to BigUint to
Vec<u8> conversion. Move them to src/algorithms/pad.rs and get rid of
internals.rs
* algorithms: protect all functions with pub(crate)
While it is expected that the functions inside algorithms crates might
be useful (and used) by other parties, they are low level functions and
as such impose a high risk of being misused. Protect all of them with
pub(crate) to prevent them from being exposed by mistake.
Also add big fat warnings to raw RSA functions, which should never be
used unless authors knows exactly what they are using.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
The crate contains several exported traits targeting
hardware-accelerated implementations (PublicKey, PrivateKey,
EncryptionPrimitive, DecriptionPrimitive). However these traits
overcomplicate internal structure of the crate. It is not clear, which
level of API can be implemented by the hardware accelerators.
The crate is already quite complicated, implementing both
PaddingScheme-based API and Signer/Verifier/Encryptor/Decryptor API.
Remove the complication for now. The proper level of indirection can be
introduced once support for actual hardware accelerators is implemented.
Inline and drop the RsaPrivateKey::raw_decryption_primitive() function.
There is no need to zeroize argument, it is ciphertext, so it can be
assumed to be safe.
Change raw_int_decryption_primitive() and raw_int_decryption_primitive()
to output Result<BigUint> instead of Result<Vec<u8>>, because they also
take BigUint rather than Vec<u8> or &[u8].
In order to simplify adding support for RSA hardware accelerators, move
all formatting and padding functions to a separate modules, making it
theoretically possible to use that for implementing support for
low-level RSA hardware accelerators.
Also follows the pkcs1v15 change and use BigUint as a Signature's
internal implementation.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
This one half of #220.
Doing anything with a signature involves converting it from bytes into a
`BigUint`, so this changes the inner type the latter which is more
useful.
It should also help address #272, since it will enable doing those sort
of checks more eagerly.
Switch to using RsaPssParams::new() from pkcs1 crate. This fixes the
issue reported by zlint for x509-cert, where SHA* digest algorithms had
empty parameters instead of NULL parameters (as required by Mozilla
policy and permitted by RFC4055).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Following #290, which amended `pkcs1v15::SigningKey`, this commit makes
a corresponding change to `Pkcs1v15Sign` so the method name is
consistent with `SigningKey::new_unprefixed`
Current new() and random() functions cause confusion. There is the
default from ASN.1 encoding of RSAPSS parameters (20). There is also
another default of (mod_size - 2 - hash_size). And there is a
recommendation to use salt_len of hash_size.
Drop old defaults and always use digest output size as the salt_len.
Clearly document new default.
* pss: specify salt_len when verifying the message
All RSA PSS standards (e.g. RFC 8017) clearly specify that RSA PSS
verification has an explicit salt length parameter (rather than
determining it from the message). Drop our 'automagic' code and pass
salt length when verifying the message. Old functions now default to
digest output size as a hash length.
* pss: remove possible non-constant time operation in PSS salt handling
The emsa_pss_get_salt() is possibly non-constant-time op. Change it to
be a contant-time operation.
---------
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Renames the following:
- `SigningKey::new` => `SigningKey::new_unprefixed`
- `SigningKey::new_with_prefix` => `SigningKey::new`
- `VerifyingKey::new` => `VerifyingKey::new_unprefixed`
- `VerifyingKey::new_with_prefix` => `VerifyingKey::new`
The `*_with_prefix` methods are preserved with a deprecation warning,
which should help people migrate to the new versions.
Closes#238
To create proper RsaPssParams it is necessary to determine the salt
length specified for the signing key. Add a function to get it from
signing keys.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Basically all of the `actions-rs/*` actions are unmaintained. See
<https://github.com/actions-rs/toolchain/issues/216> for more
information. Due to their age they generate several warnings in
CI runs.
To get rid of some of those warnings the occurrences of
`actions-rs/toolchain` are replaced by `dtolnay/rust-toolchain`.
Reverts-the-revert from #254, reinstating #251
This reverts commit 26f38ad66a09fc42ed6d73e3b1864f0251db4e2d.
Since we need to upgrade `pkcs1` and `pkcs8`, which are MSRV 1.65, now
is a good time to start making brekaing changes again.
* feat: relax Sized requirement for random source parameters
* oaep: move OAEP test cases to src/oaep.rs
There is little point in having only OAEP test cases in src/key.rs. Move
them to proper module, oaep.rs.
* oaep: mark two functions as private
Currently the crate doesn't mark the oaep module as public. Thus it
makes little sense to mark top-level functions as public. Drop the
modifier.
* feat: traits: add traits for encryption and decryption
Add traits following the signature design for encryption and decryption.
* oaep: add support for new encryption API
Add new EncryptingKey and DecryptingKey structs implementing Encryptor /
Decryptor traits.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
