[pull] master from RustCrypto:master #4
Conversation
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
dingelish
force-pushed
the
master
branch
2 times, most recently
from
bdfc1ca to
6447161
Compare
Depends: - zkcrypto/ff#126 - zkcrypto/ff#127 This is to provide an `ecdsa::SigningKey::try_from_rng` API (RustCrypto/signatures#915)
New trait for customized hash function with variable output `CtVariableCoreWrapper` like Blake2 to implement the `CustomizedInit` trait.
This change automates Cargo.lock updates.
Tests the inout methods and moves test vector code outside of the macro.
This fixes an invariant violation where you could create a secret key from an all-zero scalar and convert it to a non-zero scala. Fixes: #1607
The `digest-io` crate is added in RustCrypto/utils#1172
Together with #1799 users would need to implement `AssociatedOid` manually for created newtypes. Also replaces `feature = "const-oid"` with `feature = "oid"`.
The flag is passed automatically by docs.rs.
Includes update to `rand_core` v0.10.0 prereleases
This notably switches to `EagerHash` for the digest bound
The change forbids seeking to the last keystream block and its application. Additionally, unchecked methods added as an escape hatch.
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`)
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 : )