Yes, it's 50 kilobytes, not 50 kibibytes. I double-checked this with
the C implementation and with param-spec.txt's documentation for
`HSV3MaxDescriptorSize`.
This previously just re-exported `ssh_key::Algorithm`.
However, we will need to support x25519 keys (which aren't supported by
the `ssh_key` crate), so we define our own enum for the key algorithm.
In addition to the `Algorithm` variants from `ssh_key`, our enum also
has an `X25519` variant.
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>
1. Fix a use of 10ms that should have been TIMEOUT_SLOP.
2. Increase BODGE_YIELD by a factor of 5.
Now this test should tolerate being hung up for 125ms. I am hoping
that this will fix the CI failure
https://gitlab.torproject.org/Diziet/arti/-/jobs/302457
which fails at the line comparing circuit1 with circuit2a.
(I can't repro that locally.)
The provided impl for Mutex is hopeless: it prints just some internal
flags and doesn't acquire the mutex for printing purposes.
At some point we might want to factor this out as a general function
on `Arc<Mutex<...>>` but not now.
Actually, never mind about adding an accessor here: this value was
set incorrectly and didn't match its documentation. As such it's
basically useless, and we might as well throw it out.
gabi-250
Alexander Færøy
Nick Mathewson
pinkforest
Saksham Mittal
Ian Jackson