mirrors/arti.git/crates/tor-key-forge/src/macros.rs, branch main

tor-key-forge: add a `secret()` accessor to the derived keypair type

2026-06-25T02:46:15Z

tor-key-forge: for `Curve25519Keypair` public key, add `inner()`

2026-04-14T19:03:01Z

relay: Implement a helper to build RelayIdentities

2026-02-23T20:17:32Z

This required to add a slight helper to our tor-key-forge RSA key d-d macro to access the inner keypair. This avoids a clone. Signed-off-by: David Goulet

Lay foundations for RSA keys in keystore.

2025-09-30T20:00:51Z

This currently can't be used due to upstream limitations in the ssh_key crate, which will be removed likely in the next release. In the meantime, we can put in all the groundwork.

tor-llcrypto: Rename rsa::PrivateKey to rsa::KeyPair.

2025-09-08T21:12:10Z

As discussed with gabi on IRC today.

tor-key-forge: Add RSA key types.

2025-09-08T21:07:35Z

Some things I'm still considering here: * We may want to define a tor_llcrypto::pk::rsa::Signature newtype. * We likely want to rename tor_llcrypto::pk::rsa::PrivateKey to RsaKeypair.

Switch Cargo.toml files to edition 2024.

2025-08-07T15:28:36Z

First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.

Use an EntropicRng trait to enforce key generation rules.

2025-03-24T19:11:48Z

We want to require that whenever we generate a key that's persistent (stored in KeyMgr), it's going to be made from a stronger-than-usual Rng. This trait helps us enforce that. We also add a FakeEntropicRng struct to use for testing. Note that this turned up a case that we'd missed, which required an internal change in tor-hsservice.

squash! Upgrade rand dependency to 0.9.

2025-03-18T16:09:44Z

- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`

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.