Skip to content

Conversation

@pull
Copy link

@pull pull bot commented Oct 3, 2019

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

baloo and others added 23 commits February 22, 2025 22:47
Factors apart the detached methods of `AeadInPlace` into a separate
`AeadInPlaceDetached` trait, which itself can now more easily be further
refactored (by adding e.g. `inout` support).

Also adds a `PostfixTagged` trait which is used to gate the blanket
impls.
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.
Renames `AeadInPlaceDetached` to `AeadInOut`, and changes the type
signature so the provided `buffer` is now an `InOutBuf`
This change automates Cargo.lock updates.
The module contents do not need to be defined in `aead` and can be moved
to the `aead-stream` crate.
tarcieri and others added 30 commits October 30, 2025 12:04
This is auto-populated to point at docs.rs
Encourages the use of these traits for initializing decapsulators that
impl the `Decapsulate` type.

(This is effectively #2056 without the supertrait bound)
Access to typenum constants is needed to impl `KeySizeUser`
Otherwise there's no way to generically access one from the other
Replaces usages of `OsRng` with `getrandom`, and `OsError` with
`getrandom::Error`.

In `rand_core` v0.10 prereleases, `OsRng` has been moved to the `rand`
crate (at least for now). The `rand` crate also depends on `chacha20`,
so if we were to depend on `rand` it would create a circular dependency.
We can avoid this circular dependency by using `getrandom` directly.

By changing the feature name back to `getrandom`, it also matches the
existing feature name in stable releases, which is one less thing people
need to change in updates.

Since `aead` was consuming `OsRng` via `crypto-common`, the latter has
been changed to re-export `getrandom`.

See also: #1379, #1746, #2063
Includes update to `rand_core` v0.10.0 prereleases
Renames the (seemingly broken?) `os_rng` feature back to `getrandom` and
actually activates the corresponding feature in `crypto-common`
It seems it was never properly converted to `os_rng`.

Adds (back) a `getrandom` feature and a way to generate `SaltString`s
using the system random number generator.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

⤵️ pull merge-conflict Resolve conflicts manually

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants