This removes the `# Availability` section from the
`convert_ed25519_to_curve25519_private` and
`convert_curve25519_to_ed25519_private` docs.
We don't generally have this sort of section anywhere else in the
codebase (we use unstable cargo-docs features to make sure items are
annotated correctly).
The `convert_curve25519_to_ed25519_private` and
`convert_ed25519_to_curve25519_private` functions are now exported by
`tor-llcrypto` if the `cvt-25519` feature is enabled.
This adds a TODO explaining how convert_ed25519_to_curve25519_private
will need to be audited when we upgrade to the latest x25519-dalek.
This also adds a `debug_assertions` and a test that ensures
`StaticSecret::from` is clamping the input (when we bump x25519-dalek,
the assertions will fail, as the latest version doesn't do clamping in
StaticSecret::from).
In `ArtiNativeKeyStore`, private keys are stored in OpenSSH format.
However, `ssh-key` (the crate we use for parsing OpenSSH keys) doesn't
support x25519 keys. As a workaround, this type of key will stored
as ed25519 and converted to x25519 upon retrieval.
This commit implements the `convert_ed25519_to_curve25519_private`
conversion function (needed by `ArtiNativeKeyStore` to support x25519
keys).
Part of #900
=========================
Notes from nickm:
(This differs from pinkforest's original MR: It removes the
Cargo.lock changes and the version bump on tor-llcrypto.)
Minimal Cargo.lock changes from downgrade.
(These are exactly those changes generated by running "build" and
"test".)
There are several reasons to do this:
* It's best to bump all of our dalek dependencies at once to rc.3
or later, rather than the piecemeal approach we've been stuck
with so far.
* We don't want to do this bump right now, since there are some
tricky questions about clamping we need to figure out (see
#808), and we need to make sure we get them right, and we're in
a distracted this week.
* We _do_ need to move away from 2.0.0-rc.2 right now, since
it was causing a failure in `cargo install arti`, and then it
got yanked.
Thanks to pinkforest for helping us out here and explaining all of
this!
Fixes#926.
Commit-edited-by: Nick Mathewson <nickm@torproject.org>
This is mostly code movement; you may want to review it with
`--color-moved`.
I'm doing this so we can also use the function in netdoc for
looking up hsdesc authentication.
Per #798, we want to make sure that we never pass around an
`ed25519::SecretKey`; only an `ed25519::Keypair` (or
`ExpandedKeypair`). This is because, when you're computing an
ed25519 signature, you have to use the public key as one of your
inputs, and if you ever use a mismatched public key you are
vulnerable to a nonce reuse attack.
(For more info see
https://moderncrypto.org/mail-archive/curves/2020/001012.html )
This is like an `ed25519::Keypair`, except that instead of a
`SecretKey` it contains an `ExpandedSecretKey`.
We'll be using this to implement #798, where we impose a rule that
there must be no "unescorted" ed25519 secret keys.
This does the following:
- Gives every crate a `full`.
- Cause every `full` to depend on `full` from the lower-level
crates.
- Makes every feature listed _directly_ in `experimental` depend
on `__is_experimental`.
This upgrades us to 2.0.0-rc.2, which is the latest in the
not-quite-done-yet 2.0 series.
The only code change that's absolutely needed is opting into the
static_secrets feature.
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
Unhelpfully, the spec uses the variable name `h` and the phrase
"blinding factor" for both the unclamped and clamped value. The
clamped value is internal to the algorithm.
In our code:
* Don't ever use the word "parameter" or variable name `param`.
This doesn't appear in the spec anywhere.
* Use `h` for the unclamped blinding factor, and `blinding_factor` for the
clamped blinding factor.
* Rename `blinding_factor` function to `clamp_blinding_factor`, since
in the spec's terminology it takes an (unclamped) "blinding factor"
and returns a (clamped) "blinding factor".
* State explicitly what thing in the spec the `h` parameters are.
Hidden services use blinded singing keys derived from the identity key
to sign descriptor signing keys.
Before this patch, the hidden descriptor builder represented its blinded
signing keys (`blinded_id`) as plain `ed25519::Keypair`s. This was not
ideal, as there was nothing preventing the caller from accidentally
initializing `blinded_id` with an unblinded keypair.
This introduces a new `HsBlindKeypair` type to represent blinded
keypairs.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This introduces the `NetdocBuilder` trait described in
`netdoc-builder.md` and a new `tor-netdoc::doc::hsdesc::build` module,
which exports the `HsDescBuilder`. Hidden services will use
`HsDescBuilder` to build and encode hidden service descriptors.
There are several TODOs in the code that I'm planning to address
separately.
Partially addresses #745.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
The derive_hash_xor_eq lint was renamed in 1.68, but we can't use
it under its new name, since we still need to support back to 1.60.
Instead, we suppress the warning about the lint being renamed.
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes#748.