| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| |
| |
| | |
hsdesc: Document why enc_key_cert signbit is always zero.
Closes #1221
See merge request tpo/core/arti!1888
|
| | |
| |
| |
| |
| |
| | |
Closes #1221.
See torspec!240 for a corresponding spec change.
|
| |/
|
|
|
| |
(We don't need Fast right now, but we will certainly need it down
the line.)
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1019
|
| |
|
|
|
| |
With this change, we no longer expose the ExpandedSecretKey
unescorted, which makes it harder to misuse the API.
|
| |
|
|
| |
(These types were all already re-exported from pk::ed25519.)
|
| |
|
|
|
|
|
|
|
|
| |
This code was needed with the old version of dalek-cryptography,
which wasn't compatible with up-to-date versions of the `rand`
crate(s). But now that we've upgraded, we can drop this.
(We could have left it around and deprecated it, but we are already
making a breaking change to tor-llcrypto by upgrading
dalek-cryptography.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes that we have to adjust for are as follows:
* In x25519-dalek:
* `StaticSecret` is now behind a feature.
* `StaticSecret::new` is deprecated in favor of
`StaticSecret::random_from_rng`.
* StaticSecret no longer does its own clamping.
* In ed25519-dalek:
* `SecretKey` has (in effect) been renamed to `SigningKey`. The name
`SecretKey` is now an alias for `[u8; 32]`.
* `SigningKey` is effectively a keypair, since it contains a
public key as well.
* `PublicKey` has been renamed to `VerifyingKey`.
* The functions to extract a signing key and verifying key have
been renamed as you might expect.
* `ExpandedSecretKey` has been moved to `hasmat` and no longer
implements `sign`.
* `ExpanededSecretKey` now has as its elements a scalar and a hash
prefix.
* Various functions that took `&[u8]` now take `&[u8; N]`.
* We no longer need a wrapper for older versions of rand.
There is a single test in tor-keymgr that does not pass. I've
marked it as ignore for now, in hopes that @gabi-250 can help me
figure it out.
This closes #808. There are several changes I want to make before
we merge, however. They are marked with TODO DALEK.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Representing the supported HTYPEs as `HandshakeType`s instead of `u32`s
makes it more difficult to pass in wrong/invalid values to
`HsDescBuilder::create2_formats`.
This also fixes a descriptor publisher bug spotted by @jnewsome, where
the advertised CREATE2 HTYPEs included HTYPE `1`, which is actually
supposed to be a reserved value. The publisher now only advertises the
`NTOR` HTYPE (just like C Tor).
|
| | |
|
| | |
|
| |
|
|
|
|
| |
`Bug` wasn't necessarily the right error type here. Plus, with the new
error type adding new errors (i.e. `CertEncodeError` variants), is not a
breaking change.
|
| |
|
|
| |
blinded_id.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
argument.
This will enable us to (eventually) the load the descriptor signing key
cert from the keystore (as opposed to always recomputing it when
building the `HsDesc`).
Part of #1048
|
| | |
|
| | |
|
| |
|
|
| |
This is what the C Tor HsDirs want.
|
| | |
|
| |
|
|
| |
Closes #1039
|
| | |
|
| |
|
|
| |
StaticSecret (fmt).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
StaticSecret.
Previously, when retrieving `KS_hsc_desc_enc` keys (or any other x25519
keys) from the keystore, the keymgr would discard the public part of the
key (SSH private keys contain the public part of the key too). Instead
of discarding the public key and returning just the `StaticSecret`, the
keymgr now returns a `StaticKeypair`. This makes the x25519
`EncodableKey`/`ToEncodableKey` implementation consistent with the
ed25519 one (which retrieves key pairs rather than "unescorted"
secrets).
|
| |
|
|
|
|
| |
This is actually just the start of an existing test case.
tor-hsservice tests will want this in a moment.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously there was no way to construct one of these during
descriptor generation, other than parsing.
A fairly simple builder seems right.
I felt the builder's setter functions for setting keys should be
named precisely after official key names. But the fields weren't,
so for now I have done some builder-level renaming.
|
| |\
| |
| |
| |
| | |
clippy: Suppress needless_pass_by_value in tests
See merge request tpo/core/arti!1535
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
This commit replaces `tor_netdoc::hsdesc::inner::IntroPointDesc` with
the (almost identical) `tor_netdoc::hsdesc::IntroPointDesc`.
The only difference between the two structs is that
`inner::IntroPointDesc` wraps a `Vec<LinkSpec>` instead of a
`Vec<EncodedLinkSpec>`. Since `EncodedLinkSpec` can be derived from
`LinkSpec` (and vice-versa), and since `hsdesc::inner::IntroPointDesc`
never made it in our public API, this commit also removes
`hsdesc::inner::IntroPointDesc` in favour of `hsdesc::IntroPointDesc`.
|
| |\
| |
| |
| |
| | |
Explain the code for the #952 fix.
See merge request tpo/core/arti!1391
|
| | |
| |
| |
| |
| | |
Let's explain what Trinity did in its fix for #952, so that we know
why this code is here the next time we find it.
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-netdoc: Handle anomalous numbers of introduction points
See merge request tpo/core/arti!1332
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
None of the existing NetdocErrorKinds seemed right.
|
| |/
|
|
|
| |
I was going to add a comment about "doing this if we need the voting
period anywhere else" but it turns out that we also use it in dirmgr.
|
| |
|
|
|
| |
Fixes a warning with
cargo clippy --locked --offline --workspace --all-targets
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
=========================
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 <[email protected]>
|