[pull] master from RustCrypto:master#4
Open
pull[bot] wants to merge 405 commits into
Open
Conversation
Uses `rsa::sha2` to access `Sha256` in the code example, noting the `sha2` feature must be enabled, ala #255
Co-authored-by: Diego Fabregat Traver <diego.fabregat@rwth-aachen.de>
* 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>
Co-authored-by: Diego Fabregat Traver <diego.fabregat@rwth-aachen.de>
Basically all of the `actions-rs/*` actions are unmaintained. See <actions-rs/toolchain#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`.
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>
Bumps [zeroize](https://github.com/RustCrypto/utils) from 1.5.7 to 1.6.0. - [Release notes](https://github.com/RustCrypto/utils/releases) - [Commits](RustCrypto/utils@zeroize-v1.5.7...zeroize-v1.6.0) --- updated-dependencies: - dependency-name: zeroize dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [base64ct](https://github.com/RustCrypto/formats) from 1.5.3 to 1.6.0. - [Release notes](https://github.com/RustCrypto/formats/releases) - [Commits](RustCrypto/formats@base64ct/v1.5.3...base64ct/v1.6.0) --- updated-dependencies: - dependency-name: base64ct dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Implement associated AlgorithmIdentifier traits for PKCS1v15 and PSS keys Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
- Add "RustCrypto:" to crate title - Use badge from buildstats.info that displays downloads
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
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
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>
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`
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>
Adds a `hazmat`-gated method to `RsaPrivateKey` to allow construction of keys with large public exponents, which was removed in #459. These are a potential DoS vector ("RSADoS") hence gating on `hazmat`: https://www.imperialviolet.org/2012/03/17/rsados.html
Upgrades the following dependency requirements: - `crypto-bigint` v0.7.0-rc.25 - `crypto-common` v0.2.0-rc.15 - `digest` v0.11.0-rc.11 - `rand_core` v0.10 - `sha1` v0.11.0-rc.5 - `sha2` v0.11.0-rc.5 - `signature` v3.0.0-rc.10
The guard in validate_private_key_parts used prime < 1 instead of prime <= 1, so it only caught zero but let prime == 1 slip through. A few lines below, NonZero::new(prime - 1).unwrap() panics on zero, exactly as the existing comment warns: "Any primes ≤ 1 will cause divide-by-zero panics later."
`decrypt_inner` took `em` by reference but cloned it via `em.to_vec()` into the returned `CtOption<(Vec<u8>, u32)>`. The caller then allocated again with `out[index..].to_vec()`. Two heap allocations per decryption instead of one. Unlike PKCS#1 v1.5 which takes `Vec<u8>` by value, OAEP was forced to clone due to borrowing. The clone was useless—the caller already had `em`. Changed return type from `CtOption<(Vec<u8>, u32)>` to `CtOption<u32>` (index only). Callers now use `em` directly. One allocation removed; behavior and constant-time properties unchanged.
Also bumps `crypto-primes` to v0.7.0-pre.9
Limit exponentiation to the bit length of e to reduce computation time.
This is safe since e is public.
Improves encrypt/verify performance by over 2x on my laptop.
rsa_2048_pkcsv1_encrypt time: [17.822 µs 17.849 µs 17.877 µs]
change: [-80.899% -80.786% -80.697%] (p = 0.00 < 0.05)
Performance has improved.
rsa_4096_pkcsv1_encrypt time: [149.74 µs 150.04 µs 150.37 µs]
change: [-63.132% -61.496% -60.140%] (p = 0.00 < 0.05)
Performance has improved.
aws_lc_rs_2048_pkcs1_encrypt
time: [10.682 µs 10.714 µs 10.747 µs]
aws_lc_rs_4096_pkcs1_encrypt
time: [31.771 µs 31.826 µs 31.879 µs]
This includes changes to the `Mul` impls to make them behave like `core`, so in `rsa` the previous usages have been changed to `concatenating_mul`. Likewise, `square` was deprecated and replaced with `concatenating_square`. See RustCrypto/crypto-bigint#1208
Based off the one from `crypto-bigint`
Compatibility update for breaking changes in `crypto-bigint`
In #657 we encountered a user with an 8192-bit key who wasn't able to use it due to our maximum modulus size restrictions. This raises the cap on the maximum modulus size to 8192-bits. This should hopefully be enough for most real-world use cases.
These are the final releases of these hash crates. Release PRs: - `sha1`: RustCrypto/hashes#810 - `sha2`: RustCrypto/hashes#806 - `sha3`: RustCrypto/hashes#816
Companion PR to RustCrypto/formats#2305 Bumps `pkcs8` to v0.11.0-rc.12
Includes updates for `pkcs8` v0.11
…#692) Per @tarcieri's reply on #690: > The fix for the logic is there, however it looks like the regression test wasn't carried over and probably should be. > As it were, the entire implementation diverged as we moved from `num-bigint` to `crypto-bigint`. The production fix lives on master already (`validate_private_key_parts` rejects any `prime <= one` with `Error::InvalidPrime`, src/key.rs:760-763). What was missing was the regression test added alongside it in upstream commit `2926c91bef` (PR #624). This PR ports just that test. ## Adaptations vs the original test - **Type swap**: original used `num-bigint::BigUint` constructors (`BigUint::from_u64`, `BigUint::zero()`); ported to `crypto-bigint::BoxedUint::from(u64)` since that's what current master's `from_components` API takes. - **API path**: the original numeric inputs (`n=239, e=185, d=0, primes=[1, 239]`) include an `e` below master's `MIN_PUB_EXPONENT` bound, so the test calls `from_components_with_large_exponent` (gated `#[cfg(feature = "hazmat")]`, matching the existing `test_from_components_with_small_exponent` / `test_from_components_with_large_exponent` neighbors) rather than `from_components`. Ordering inside `validate_skip_exponent_size` -> `validate_private_key_parts` still hits the `prime <= one` check first, so we exercise exactly the path the original test did. - **Assertion**: `Err(Error::InvalidPrime)` (not a panic) — same intent as the original. No production-code changes. Single-file diff in `src/key.rs`. Refs: GHSA-9c48-w39g-hm26, #690, #624, upstream `2926c91bef`. Co-authored-by: vulgraph <vulgraph@users.noreply.github.com>
Explains why there's a maximum pub exponent limit in the first place, notes the particular constant came from *ring*, and lists the APIs that can be used to get around it. See also: #695
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )