[pull] master from RustCrypto:master#4
Open
pull[bot] wants to merge 1873 commits intomesalock-linux:masterfrom
Open
[pull] master from RustCrypto:master#4pull[bot] wants to merge 1873 commits intomesalock-linux:masterfrom
pull[bot] wants to merge 1873 commits intomesalock-linux:masterfrom
Conversation
dingelish
force-pushed
the
master
branch
2 times, most recently
from
bdfc1ca to
6447161
Compare
Adds support for generating `SecretKey` and `NonZeroScalar` using the system's cryptographically secure random number generator. Notably this renames the former `SecretKey::random` and `NonZeroScalar::random` methods to `SecretKey::generate` and `NonZeroScalar::generate`, which take no parameters and are infallible. This avoids the need for the user to import an `OsRng` type, or worry about the generation failing (which it won't on most notable modern OSes). If a user still wants to handle RNG errors, the `try_from_rng` method still exists, and they can pass `OsRng` if they'd like.
Has people use either the `generate` or `try_from_rng` methods instead.
Switches (hopefully temporarily) to our forks of the `ff` and `group` crates containing updates to `rand_core` v0.10.0 prereleases, which allows us to cut crate releases of `elliptic-curve` and all of its dependent crates
Ensures the `BasepointTable` type is documented
Replaces all of the previous RNG functionality with a `Generate` trait
which has the same basic shape as the existing methods, but allows types
to impl only `try_from_rng` and receive provided versions of all of the
other methods:
- `generate`: infallible generation using system RNG with panic on error
- `try_generate`: fallible version of above with RNG error `Result`s
- `from_rng`: infallible generation with RNG parameter that panics on
error
The `generate` and `try_generate` methods are available when the
`getrandom` feature is enabled.
Impls are provided for `hybrid_array::Array<u8, U>`.
With this approach we can generate things like symmetric keys and IVs
like:
type Aes256CbcEnc = cbc::Encryptor<aes::Aes256>;
let key = Key::<Aes256CbcEnc>::generate();
let iv = Iv::<Aes256CbcEnc>::generate();
The trait is also intended to be impl'd by consuming crates for other
key generation use cases, e.g. `RsaPrivateKey`, `dsa::SigningKey`,
`ecdsa::SigningKey`, or KEM decapsulation keys.
Replaces them with the `Generate` trait introduced in #2096. Moves documentation about generating random nonces to the `Nonce` type.
Adds a trait providing fallible key initialization, similar to the existing `KeyInit` trait, but designed to handle the case that not all bytestrings of a given length represent valid keys. This is primarily useful in the context of public-key cryptography, e.g. scalars representing elliptic curve private keys. The API and method names are duplicated from `KeyInit`. It is assumed that `KeyInit` and `TryKeyInit` have an either-or relationship, i.e. types will not impl both `KeyInit` and `TryKeyInit`, and consumers of code which is generic over these traits will not be attempting to abstract over the `KeyInit`/`TryKeyInit` distinction, but one or the other will make sense in a given context (e.g. symmetric cryptography uses `KeyInit`, ECC uses `TryKeyInit`)
The encoding types in this crate are designed around the PHC String Format which uses "B64", a.k.a. unpadded non-URL-safe Base64. The `Encoding` type was designed to make it possible to use alternative encodings from Modular Crypt Format (MCF), but that doesn't actually make sense because PHC Strings mandate "B64". The `Encoding` type has since been extracted into the `mcf` crate as `mcf::Base64`: RustCrypto/formats#1918
Extracts all functionality related to the Password Hashing Competition (PHC) string format into a `phc` submodule. The longer-term goal would be to extract this into its own crate, however that will need some trait redesign, which can be better accomplished by first adding a `phc` feature and feature-gating the relevant functionality. This is just an initial step to begin isolating the relevant code.
This change puts the traits front-and-center in the library's implementation, which is what you'd expect for a crate in the "traits" repository
Splits out `PasswordHasher::hash_password_customized` into its own separate `CustomizedPasswordHasher` trait. This trait retains the associated `Params` type since that's used as a method argument. This also adds a type alias `Version` for `u32` to use in place of `Decimal` (also a `u32` alias) for the `Version` parameter to `hash_password_customized`, and changes the `salt` parameter to be `&'a str`, which removes any PHC-related types as input arguments to the method. However, there is still a dependency on `ParamsString` and `PasswordHash`, which still needs to be addressed to fully decouple the trait from PHC types.
Uses core traits to handle string serialization, rather than relying on types in `password_hash::phc`
`Ident` is a short string with a max length of 32-bytes. Instead of having a lifetime, we can simply store the 32-bytes as an owned type. This is an incremental step towards removing the lifetime from the `phc::PasswordHash` type. The implementation makes the previous `Buffer` (now `StringBuf`) type used for `Params` const generic around a particular size, and adds some basic const init functionality, as well as checks for arithmetic overflow.
Note: lint config was added in #2270
The crate is now generic around password hash string formats, so having an MCF-specific trait like this doesn't make sense. The functionality for upgrading MCF hashes to PHC hashes using algorithm-specific rules is worth retaining, but we can probably move this trait or add a similarly shaped one to e.g. the `mcf` crate which is better equipped to deal with MCF-specific concerns.
Fixes a TODO by adding a specific error variant for RNG failures
## Added - Generic `H` param to traits to support multiple string formats e.g. PHC, MCF (#2110) - Implement `From<phc::Error>` for `Error` (#2124) - `rand_core` feature (#2126) - Salt generating helper functions `(try_)generate_salt` (#2128) - `Error::RngFailure` variant (#2337) ## Changed - Edition changed to 2024 and MSRV bumped to 1.85 (#1759) - Extract `CustomizedPasswordHasher` trait (#2105) - Bump `getrandom` to v0.4 (#2258) ## Removed - `Encoding` enum (#2102) - PHC types moved to the `phc` crate, which is re-exported as `password_hash::phc` when the `phc` crate feature is enabled (#2103, #2116): - `Ident` - `Output` - `ParamsString` - `PasswordHash` - `PasswordHashString` - `Salt` - `SaltString` - `Value` - `McfHasher` trait (#2334)
NOTE: this is a breaking change! We are doing it in spite of `digest` having a stable release as the downstream crates that depend on this functionality have not yet had stable releases, so it should only impact people who are currently relying on prereleases
Note: v0.11.1 was yanked because v0.11.2 introduces minor breaking changes affecting only pre-release versions of downstream crates. ### Changed - Do not implement `Clone` as part of `(Reset)MacTraits` in the `buffer_fixed!` macro ([#2341]) - `EagerHash` trait to be a sub-trait of `Clone` ([#2341]) [#2341]: #2341
This clears the security audit
This release is effectively a complete rewrite of the `kem` crate. Any similarities between trait names in this release and previous releases is coincidental. The log below highlights some of the new parts of the API but will provide an incomplete picture of changes. ## Added - `Encapsulate` and `Decapsulate` traits (#1509) - `getrandom` feature (#2140) - Re-exports from `crypto-common` (#2222) - re-exports `crypto-common` itself as `common` - re-exports `KeyInit`, which is useful for seeds - re-exports `Key` as the type for representing serialized encapsulation and decapsulation keys - re-exports `InvalidKey` as the error when `TryKeyInit` fails - `TryDecapsulate` trait (#2220, #2235) - `Kem` trait for the whole algorithm type family (#2243) - `FromSeed` trait and `Seed` type alias (#2284) ## Changed - `Decapsulator` trait replaced with new implementation (#2282) ## Removed - Previous implementation (#1509)
…2370) Changes the `TryFrom` bound for constructing `T::Params` to accept a full `phc::PasswordHash` as the input type, rather than just its `phc::ParamsString`. This is actually how it used to work in prior releases, but regressed: https://docs.rs/password-hash/0.5.0/src/password_hash/traits.rs.html#63 This is needed so the params can include the output size for the hash. This is unfortunately a breaking change, but fortunately we haven't yet released any password hash crates, so it will only impact prerelease users. Closes #2352.
## Changed - [BREAKING] `PasswordVerifier` blanket impl bounds for `phc::PasswordHash` (#2370)
These notably include the workarounds to make wNAF work
Includes preliminary support for wNAF
Adds a trait with an associated `BASEPOINT_TABLE` constant which provides a place to access a particular curve group's `BasepointTable` from a generic context.
Uses the same strategy as our existing `BasepointTable` type, i.e. using either `std::sync::LazyLock` if `std` is available, or if not optionally falling back on `once_cell` with the `critical-section` feature enabled, to enable a lazily computed basepoint table with a `const fn new` constructor that is backed by `WnafBase`. Like `BasepointTable` it requires the `basepoint-table` feature (which cannot be enabled unless one of `critical-section` or `std` is enabled so we have a `LazyLock` type available), but also additionally requires the `alloc` feature as it's needed for `group::WnafBase`. The type has a single method `VartimeBasepointTable::mul` that performs a scalar multiplication by the provided `Point::Scalar`.
As suggested in #2377, this follows precedent from `crypto-bigint` and makes `*Vartime` a suffix in trait and type names, so we can use `*_vartime` method names and they will be consistent with the trait names.
Adds a variable-time equivalent of the `Mul` trait with a corresponding `mul_vartime` method. This provides a place to plug in wNAF which is otherwise always available (and can fall back on constant-time operations if the `alloc` feature isn't enabled). The trait has been added to the bounds for `CurveArithmetic::Scalar`, with requirements to support variable-time multiplication for affine and projective points.
- Adds `MulVartime` to `AffinePoint` and `ProjectivePoint` bounds - Adds boilerplate `MulVartime` impls to `scalar_mul_impls!` - Uses `scalar_mul_impls!` for `MockCurve`
Closes #2375 We now have variable-time precomputed basepoint tables that use wNAF when the `basepoint-table` and `alloc` features are enabled, which can be opportunistically used when these features are enabled to accelerate this operation. We use `Group::mul_by_generator` for the constant-time basepoint tables, however for an extension trait this is captured as `MulByGeneratorVartime::mul_by_generator_vartime`. As discussed in the above issue, and inspired by `curve25519-dalek`'s `EdwardsPoint::vartime_double_scalar_mul_basepoint` function, this adds `MulByGeneratorVartime::mul_by_generator_and_mul_add_point_vartime` as a provided method. This function is the core of many signature algorithms, and when the basepoint tables and alloc are unavailable it can fall back to a linear combination and still provide better performance than the naive constant time version.
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
8 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 : )