mirrors/arti.git/crates/tor-llcrypto/src/util, branch arti-v1.8.0

Merge branch 'bug2172' into 'main'

2025-11-24T15:09:00Z

tor-llcrypto: Stop deriving Deref in CtByteArray Closes #2172 See merge request tpo/core/arti!3432

tor-llcrypto: Stop deriving Deref in CtByteArray

2025-11-24T15:08:59Z

Fix name of clippy lint to unchecked_time_subtraction (2)

2025-11-06T11:28:22Z

Run maint/add_warning

tor-(hs|ll)crypto: export cteq macros correctly

2025-09-23T19:52:04Z

The macros to deftly derive `ConstantTimeEq` and `PartialEq` (for `ConstantTimeEq`) are now only defined in `tor-llcrypto` and exported. The macro to deftly derive `ConstantTimeEq` is now struct only and uses `subtle::Choice::from(1)` for improved clarity. Signed-off-by: hashcatHitman <3924-hashcatHitman@gitlab.torproject.org>

tor-llcrypto: unconditionally use derive_deftly

2025-09-23T09:43:02Z

I didn't even realize I was still conditionally using it on a feature. That's what I get for always testing with all-features. Signed-off-by: hashcatHitman <3924-hashcatHitman@gitlab.torproject.org>

tor-(hs|ll)crypto: deftly derive ConstantTimeEq

2025-09-23T08:25:49Z

This is my initial attempt at deriving ConstantTimeEq and PartialEq. This includes the previously missed HsSvcNtorKeypair and HsClientDescEncKeypair types. In tor-llcrypto, a few implementations still had to be done by hand, and some types which previously derived normal PartialEq now derive it with ConstantTimeEq. I could not figure out how to properly set up the macros such that they could be used both in the current crate and in others, so for the moment they are duplicated. Just so I can get feedback. Ideally, this will be replaced with a better solution before merge. Signed-off-by: hashcatHitman <3924-hashcatHitman@gitlab.torproject.org>

Use CautiousRng for keys going into the KeyMgr.

2025-03-24T19:10:21Z

squash! Upgrade rand dependency to 0.9.

2025-03-18T16:09:44Z

- The Rng::gen() functions have been renamed to Rng::random().

llcrypto: add an rng compatibility shim for dalek-crypto

2025-03-18T16:09:44Z

dalek-cryptography is still on rand 0.8, so we need a compatibility shim for the Rng. Fortunately, since we merged interface-abstraction-of-the-daleks (!2868), we no longer need to propagate this compatibility layer throughout our codebase.

Rename "memquota" feature to "memquota-memcost" when it's just HasMemoryCost (fmt)

2024-10-16T13:48:29Z