mirrors/arti.git/crates/tor-relay-crypto/src/pk.rs, branch arti-v1.5.0

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.

tor-relay-crypto: Rename RelaySigningKeypairSpecifier's timestamp to valid_until.

2024-10-31T14:34:51Z

As per our discussion in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2577#note_3099356

tor-relay-crypto: Add tests for relay key specifier serialization.

2024-10-31T14:34:51Z

tor-relay-crypto: Add a denotator to RelaySigningKeypairSpecifier.

2024-10-31T14:34:51Z

This will enable us to store more than one `K_relaysign_ed` in the keystore. Closes #1692

tor-relay-crypto: Add a specifier for the public part of the identity keypair.

2024-10-31T14:34:01Z

We'll eventually need this specifier (for example, if the `KS_relayid_ed` private key stored offline, the public part of the keypair will be stored in the online keystore, and will be retrievable using the new `RelayIdentityPublicKeySpecifier` specifier).

tor-relay-crypto: Fix typo in doc comment.

2024-10-31T14:29:30Z

tor-relay-crypto: Use the KS_ prefix for RelayIdentityKeySpecifier.

2024-10-31T14:29:30Z

According to its docs, `RelayIdentityKeySpecifier` was meant to be the key specifier for the relay identity keypair, so its role prefix should be `KS_`. This also renames `RelayIdentityKeySpecifier` to `RelayIdentityKeypairSpecifier` for clarity (we're about to add another specifier here, for the public relay identity key).

tor-relay-crypto: Temporarily comment out RelaySigningKeySpecifier.

2024-10-14T17:50:48Z

The `RelaySigningKeySpecifier` is currently defined as: ```rust #[non_exhaustive] #[derive(Deftly, PartialEq, Debug, Constructor)] #[derive_deftly(KeySpecifier)] #[deftly(prefix = "relay")] #[deftly(role = "KP_relaysign_ed")] #[deftly(summary = "Relay medium-term signing keypair")] /// The key sepcifier of the relay medium-term signing key (RelaySigningKeypair) pub struct RelaySigningKeySpecifier; ``` This means there can only be a single `relaysign_ed` key with an `ArtiPath` of the form `relay/KP_relaysign_ed`. This is a problem, because relays storing their identity key offline will want to generate a number of `relaysign_ed` keys ahead of time, so we need the keystores to be able to contain multiple such keys. We will need their `ArtiPath` to encode a variable component (for example, a timestamp). We also need to teach `KeyMgr` to retrieve such keys (`KeyMgr::get` should return the first key that has a valid and timely certificate). This will involve extending the `KeySpecifier` trait with a function for obtaining the `KeySpecifier` of the certificate of the key, if there is one. For now, let's comment it out and rethink its `ArtiPath` as part of #1692.

tor-key-forge: encapsulate `define_ed25519_keypair` macro deps

2024-09-18T19:27:33Z

This re-exports the types/traits needed by the `define_ed25519_keypair` macro so that the macro caller doesn't need to import a bunch of extra packages in its Cargo.toml that it doesn't use, and so that the caller doesn't need a `use prelude::*` before invoking the macro. This makes the macro nicer to use for the caller, and should prevent the macro from causing "cannot find ... in this scope" errors.

key-forge: Support extra docs and attributes to ed25519 keypair

2024-09-18T13:24:04Z

Signed-off-by: David Goulet