17d965e894
Previously, the Arti key store would store x25519 secret keys as ed25519 OpenSSH keys, which it would convert to x25519 upon loading (using the conversion function added in !1297 (merged)). This approach isn't good enough though: most people will probably want to bring their existing x25519 keys, and in order to store those in OpenSSH format, we'd need convert them to ed25519, which is impossible (because the secret part of an x25519 key contains a SHA512'd secret, whereas the corresponding, "un-expanded", ed25519 secret key contains the secret itself rather than the SHA). Now that `ssh-key` has support for ssh keys with [custom algorithm names], we can store x25519 in OpenSSH format directly. This commit changes the storage format used by the keymgr for x25519 client auth keys (from ed25519-ssh to our own custom key type with an algorithm name of `"x25519@torproject.org"`). Closes #936 [custom algorithm names]: https://github.com/RustCrypto/SSH/pull/136 |
||
|---|---|---|
| .. | ||
| src | ||
| testdata | ||
| Cargo.toml | ||
| README.md | ||
| semver.md | ||
README.md
tor-keymgr
Code to fetch, store, and update keys.
Overview
This crate is part of Arti, a project to implement Tor in Rust.
Likely to change
The APIs exposed by this crate (even without the keymgr feature)
are new and are likely to change rapidly.
We'll therefore often be making semver-breaking changes
(and will update the crate version accordingly).
Key stores
The [KeyMgr] is an interface to one or more key stores. The key
stores are types that implement the [Keystore] trait.
This crate provides the following key store implementations:
- Arti key store: an on-disk store that stores keys in OpenSSH format.
- (not yet implemented) C Tor key store: an on-disk store that is backwards-compatible with C Tor (new keys are stored in the format used by C Tor, and any existing keys are expected to be in this format too).
In the future we plan to also support HSM-based key stores.
Key specifiers and key types
The [Keystore] APIs expect a "key specifier" (specified for each supported key
type via the [KeySpecifier] trait), and a [KeyType].
A "key specifier" identifies a group of equivalent keys, each of a different type (algorithm). It is used to determine the path of the key within the key store (minus the extension).
[KeyType] represents the type of a key (e.g. "Ed25519 keypair").
[KeyType::arti_extension] specifies what file extension keys of that type are
expected to have (when stored in an Arti store).
The [KeySpecifier::arti_path] and [KeyType::arti_extension] are joined
to form the path of the key on disk (relative to the root dir of the key store).
This enables the key stores to have multiple keys with the same role (i.e. the
same KeySpecifier::arti_path), but different key types (i.e. different
KeyType::arti_extensions).
KeySpecifier implementers must specify:
arti_path: the location of the key in the Arti key store. This also serves as a unique identifier for a particular instance of a key.ctor_path: the location of the key in the C Tor key store (optional).
Feature flags
Additive features
(None yet.)
Experimental and unstable features
Note that the APIs enabled by these features are NOT covered by semantic versioning1 guarantees: we might break them or remove them between patch versions.
keymgr-- build with full key manager support. Disabling this feature causestor-keymgrto export a no-op, placeholder implementation.
-
Remember, semantic versioning is what makes various
cargofeatures work reliably. To be explicit: if you wantcargo updateto only make safe changes, then you cannot enable these features. ↩︎