| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
The privateness of the keys is encoded in their name.
|
| | |
|
| | |
|
| |
|
|
| |
And add a TODO about the error type.
|
| | |
|
| |
|
|
|
| |
Nightly rustdoc now warns if you have a link that isn't necessary,
and if you have a link that might refer to two different things.
|
| |
|
|
| |
This comment will form the basis for the protocol name registry.
|
| |
|
|
|
|
|
|
|
|
| |
The `KeypairData` type from [ssh-key] at some point leaked into the
keymgr API (via the `EncodableKey` trait). Instead of re-exporting just
`KeypairData`, let's re-export the entire `ssh_key` crate
(`EncodableKey` implementors would need additional types from `ssh_key`
to construct a `KeypairData` object anyway).
[ssh-key]: https://crates.io/crates/ssh-key
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This helper is no longer needed (the logic from
`parse_ssh_format_erased` changed).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 `"[email protected]"`).
Closes #936
[custom algorithm names]: https://github.com/RustCrypto/SSH/pull/136
|
| |
|
|
| |
This brings in the changes from #936.
|
| |
|
|
|
|
|
|
| |
According to the `ErrorKind` lumping guidelines, `KeystoreFsPermissions`
should be lumped with `FsPermissions`: they represent the same type
of error, and their "location" is the same ("Host").
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1315#note_2916455
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This function isn't actually needed (it's not the responsibility of
`KeyType` to encode keys).
This commit also rewrites `ArtiNativeKeystore::insert` to use the new
`as_ssh_keypair_data` function instead of `to_ssh_format`.
|
| |
|
|
|
|
|
|
|
|
|
| |
The `EncodableKey::to_bytes` function didn't make much sense, because
not all keys have a canonical byte representation.
This commit replaces `EncodableKey::to_bytes` with
`EncodableKey::as_ssh_keypair_data`. In the future, `EncodableKey` will
grow functions for encoding keys in other storage formats too.
Closes #965
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This will enable us to test the parts of `ArtiNativeKeystore::insert`
that _are_ implemented (such as the part where it creates the missing
directories).
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Keymgr api updates minor fixes
See merge request gabi-250/arti!1
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Trying to use a keystore that doesn't exist is `bad_api_usage!`.
|
| | |
| |
| |
| |
| |
| | |
This also removes the corresponding
`KeyMgrError::UnsupportedKeystoreSelector` error, because it's not
needed anymore.
|
| | |
| |
| |
| | |
keys from." (fmt)
|
| |/
|
|
|
|
|
|
|
| |
keys from."
This reverts commit 38a6c74c7894dc96b16c9039cacc2a4023977b05.
This also updates some tests to make them compile with the reverted
version of the code.
|
| |
|
|
|
| |
As with `KeyMgr::insert`, only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported.
|
| | |
|
| |
|
|
| |
We'll need this to implement `Keystore::insert`.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This refactoring will make more sense later, when we give
`KeyMgr::get` an extra parameter that specifies which keystore to
retrieve the key from.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The concept of a "key bundle" would introduce a lot of complexity while
providing little to no gain.
Some context:
```
Originally, "key bundles" were meant to be the answer to the question
"which keystore should insert place keys in?":
https://gitlab.torproject.org/tpo/core/arti/-/blob/36606a66ddca9abd1595d13c9397bc812bf24cb5/crates/tor-keymgr/src/mgr.rs#L60-69
However, I'm not so sure anymore that "key bundles" are the answer. I
don't think there is any way we can "guess" where a key should go. When
inserting/generating a new key, we should either:
always write to the same, primary key store, OR require the user to be
explicit about which key store the new key should go in (by assigning an
ID to each key store and expecting the user to provide it when
inserting/generating new keys)
I prefer the latter option, because it provides more flexibility, which
we're going to need when implementing the key management CLI (which I
think should allow users to generate keys anywhere they want, e.g. arti
keymgr generate <key type> --keystore hsm ...)
```
For more details, see the discussion on #903.
Closes #903
|
| |
|
|
|
|
|
|
|
|
| |
The caller uses `KeystoreSelector` to specify which keystore to insert
the new key into (only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported for `insert`).
The ability to insert keys in a particular keystore will come in handy
when we implement the key management CLI (the CLI will have an option
for specifying the keystore to access/modify).
|