mirrors/arti.git/crates/tor-llcrypto/src/pk/ed25519.rs, branch arti-v2.2.0

tor-llcrypto: add `Ed25519Identity::from_base64()`

2026-02-10T18:41:01Z

This is intended to be analogous to `RsaIdentity::from_hex()`. I've found myself wanting this a few times, and it makes it easy to grab a `master-key-ed25519` from the consensus and paste it into the code without needing to do extra conversions.

llcrypto: Depend on tor-memquota-cost, not tor-memquota.

2026-02-02T15:02:22Z

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>

tor-llcrypto: fix typo

2025-07-23T15:31:55Z

`tor_llcrypto::pk::ed25519::PublicKey` is based on `ed25519_dalek::VerifyingKey` and not `ed25519_dalek::SigningKey`.

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.

Wrap ed25519-dalek types.

2025-03-18T12:45:28Z

With this change, we'll no longer need to expose the types from dalek-cryptography as part of our API, and we'll have more freedom to switch ed25519 implementations, or to upgrade to a newer `rand` ahead of their schedule. Unlike with x25519-dalek, I had to tweak the API a bit: There's no way to get a &PublicKey out of a Keypair now, and implementing the old ed25519-dalek traits seemed unnecessary.

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

2024-10-16T13:48:29Z

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

2024-10-16T13:48:11Z

It's not documented anywhere ATM. I will do that in a followup MR.

Some HasMemoryCost impls in tor-llcrypto

2024-10-02T18:11:26Z