mirrors/arti.git/crates/tor-relay-crypto/src, branch arti-v1.3.1

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

relay-crypto: Initial import of new tor-relay-crypto crate

2024-09-18T13:24:04Z

This adds a new crate called tor-relay-crypto which is responsible for declaring the relay keys and certificate that will be used by a relay and stored in a KeyMgr. This is in its own crate and considered pretty low level so other crates can use it to access the relay keys, like tor-proto, for cryptographic actions like channel authentication or descriptor signing. The lower level cryptographic keys are wrapped in a higher level object in this crate, using tor-key-forge crate, so we can have proper semantic and strong type check on those keys so they are not misused or confused with other keys. At this point, the key declaration might change once the KeyMgr supports attaching a certificate to a key. We are likely going to see more code related to certificate creation in this crate in the future. Part of #1604 Signed-off-by: David Goulet