aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-relay-crypto/src
Commit message (Collapse)AuthorAgeFilesLines
* tor-checkable: Rename `TimeBound::check_valid_*` to `if_valid_*`Ian Jackson2026-07-231-1/+1
| | | | | | | I find these names confusing. To my mind "check" implies a function returning `Result<(), _>`. Some other APIs use `unwrap` here but I think `if` is good.
* Use new TimeBound name throughout the treeIan Jackson2026-07-161-1/+1
|
* add_warning: add reference to arti#2556Jim Newsome2026-07-151-1/+1
|
* Removed unnecessary lintpryty262026-07-151-1/+1
| | | | Removed unnecessary lint
* maint: Run maint/add_warning to deny string slicesClara Engler2026-06-091-0/+1
| | | | | | | | | | | | This commit executes maint/add_warning with the just added change to deny string slices except in tests. I recommend auditing this by checking out the previous commit followed by running the script yourself and then verifying that the diff is identical to this commit. This commit makes cargo clippy fail. We will add exceptions in the next commit.
* tor-cert: Ed25519CertBuilder: do builder fn renameIan Jackson2026-04-291-3/+3
| | | | | | Change all call sites. This completes the rename.
* relay: Modify RelayNtorKeys to use a constructorDavid Goulet2026-04-211-25/+14
| | | | | | | | | | | | Because of the sorting requirement and the fact that a `KeyMgr` can have multiple Ntor keys, the caller now explicitly extract the two Ntor keys it wants from the `KeyMgr` and then creates a `RelayNtorKeys` object with them. Future changes (#2495) will move this into a view and warn if there are more than 2 keys. Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Add RelayNtorKeys struct holding both Ntor keysDavid Goulet2026-04-211-0/+48
| | | | Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Add new RelayNtor key wrapperGabriela Moldovan2026-04-091-1/+6
|
* arti-relay: Move all key specifiers to a new keys moduleGabriela Moldovan2026-04-011-315/+0
| | | | | | | | | | | This extracts the key specifier types out of `tor-relay-crypto`, which * makes the code layout consistent with the hidden service crates (the key specifiers are defined in a `keys` module in `tor-hsservice`, while the key wrapper types live in `tor-hscrypto::pk`) * helps reduce the API surface: the key specifiers are only used in `arti-relay`, so we can move them there and make them `pub(crate)` instead of `pub`
* relay-crypto: Make the certs module non-pubGabriela Moldovan2026-04-011-1/+1
| | | | This doesn't really need to be public.
* proto: Add key specifier types for the ntor keysGabriela Moldovan2026-04-011-0/+31
| | | | Part of #2451
* tor-relay-crypto: port to web-time-compatNick Mathewson2026-03-262-5/+4
|
* relay: Rewrite the rotation key logic in the crypto taskDavid Goulet2026-03-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | This is almost a full rewrite of the crypto task which was needed in order to support our relay signing certificate to be put in the keystore which will be needed for the offline key feature. Instead of having rotate_key() do all the things, we now instead do two pass: 1. Remove all expired keys and certs. 2. Generate any missing keys. This still results in using the minimum valid_until of all our keys for the task sleep time. We can know cleanup the local trait used for this gymnastic and trade it for some more KeyMgr gymnastic. Fixes #2404 Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Add test for cert specifier patternsGabriela Moldovan2026-03-121-1/+8
| | | | | | For relays these are pretty basic (they have no globbing components), because relay certs don't have specifiers (their `ArtiPath`s are identical to the `ArtiPath` of the subject key).
* relay-crypto: Use the new CertSpecifier macroGabriela Moldovan2026-03-121-4/+12
| | | | | This enables the `experimental-api` feature in `tor-keymgr` because `CertSpecifier` is experimental.
* keymgr: Abolish KeyCertificateSpecifier::signing_key_specifier()Gabriela Moldovan2026-03-121-12/+0
| | | | | | | We need to be able to parse KeyPaths into KeyCertificateSpecifier, and we can't do that if the signing key is part of the cert specifier (because the signing key doesn't get encoded in the key path, unlike the subject key, which does)
* relay-crypto: Move comments above [derive] to be consistent accross codebaseDavid Goulet2026-02-231-7/+7
| | | | Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Fix the gen relay signing keypair typoDavid Goulet2026-02-231-3/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Add gen_tls_cert() helper functionDavid Goulet2026-02-232-1/+18
| | | | Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Add missing helper functionsDavid Goulet2026-02-231-0/+13
| | | | Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Add link signing key specifierDavid Goulet2026-02-231-0/+32
| | | | Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Add a certificate specifier for KP_relaysign_ed (fmt)Gabriela Moldovan2026-02-171-4/+1
|
* relay-crypto: Add a certificate specifier for KP_relaysign_edGabriela Moldovan2026-02-171-0/+68
|
* relay-crypto: Derive Copy and Clone for the relay key specifiersGabriela Moldovan2026-02-171-5/+5
|
* Allow clippy::collapsible_if to triggerGabriela Moldovan2026-02-161-0/+1
| | | | | | | | | `clippy::collapsible_if` started triggering after bumping the MSRV to 1.88. Since this triggers from a lot of places, and since there even are a couple of instances where we explicitly allow `clippy::collapsible_ifs`, I've opened #2342 for deciding what to do about it.
* maint/add_warning: Run script to add new warningGabriela Moldovan2026-01-271-0/+1
| | | | This adds the lint to all our crates.
* Fix name of clippy lint to unchecked_time_subtraction (2)Ian Jackson2025-11-062-2/+2
| | | | Run maint/add_warning
* tor-relay-crypto: Fix KP_relayid_rsa typo.Wesley Aptekar-Cassels2025-10-021-1/+1
|
* Lay foundations for RSA keys in keystore.Wesley Aptekar-Cassels2025-09-301-4/+24
| | | | | | 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.
* Remove "doc_auto_cfg" incantation from all crates.Nick Mathewson2025-09-291-1/+1
| | | | This feature has been removed from nightly, in favor of doc_cfg.
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-072-5/+5
| | | | | | | | | | | | | | 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.
* Temporarily suppress mismatched_lifetime_syntaxes.Gabriela Moldovan2025-07-071-0/+1
| | | | See #2060.
* tor-relay-crypto: Remove TODO about validating cert extensions.Gabriela Moldovan2025-01-131-2/+0
| | | | | | | There is no need for validation here. If any validation is required, it will be handled by the calling code. Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2672?commit_id=10845d5e6a06d4d9548d536846eb470128d8a7d4#note_3147517
* tor-relay-crypto: Use the new cert_type() function to get the cert type.Gabriela Moldovan2025-01-131-2/+8
|
* tor-relay-crypto: Use the high-level cert types instead of EncodedEd25519Cert.Gabriela Moldovan2025-01-131-2/+4
| | | | | | | This will come in handy later on, when we start using these function in conjunction with `KeyMgr::get_or_generate_key_and_cert`, which expects the `make_certificate` callback to return a type that implements `ToEncodableCert`.
* tor-relay-crypto: Implement ToEncodableCert for the relay cert types.Gabriela Moldovan2025-01-131-0/+90
| | | | Closes #1777
* tor-relay-crypto: Add high-level cert types.Gabriela Moldovan2025-01-132-1/+41
| | | | | | These will be the `ToEncodableCert`s we write to the keystore. Part of #1777
* clippy: deny `mod_module_files`Steven Engler2025-01-061-0/+1
| | | | | | Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
* add_warnings, *: Allow clippy::needless_lifetimesNick Mathewson2024-12-031-0/+1
| | | | | | | | In 1.83, this warning triggers on many of our crates. We're thinking of fixing them all, but for now, we're going to disable the warning. This is part of #1765.
* tor-relay-crypto: Rename RelaySigningKeypairSpecifier's timestamp to ↵Gabriela Moldovan2024-10-311-3/+9
| | | | | | | valid_until. 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.Gabriela Moldovan2024-10-311-0/+54
|
* tor-relay-crypto: Add a denotator to RelaySigningKeypairSpecifier.Gabriela Moldovan2024-10-311-8/+60
| | | | | | | 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.Gabriela Moldovan2024-10-311-0/+9
| | | | | | | 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.Gabriela Moldovan2024-10-311-1/+1
|
* tor-relay-crypto: Use the KS_ prefix for RelayIdentityKeySpecifier.Gabriela Moldovan2024-10-311-3/+3
| | | | | | | | | | 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.Gabriela Moldovan2024-10-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 depsSteven Engler2024-09-181-1/+1
| | | | | | | | | 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 keypairDavid Goulet2024-09-181-6/+12
| | | | Signed-off-by: David Goulet <[email protected]>
* relay-crypto: Initial import of new tor-relay-crypto crateDavid Goulet2024-09-183-0/+123
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 <[email protected]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:42:18 +0000