| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
An encoded set of extensions in the ntorv3 handshake includes a header
with the number of extensions. This change adds that header.
It also changes `write_many_onto` to take a slice instead of an
iterator, since we need to know the number of extensions up-front. In
principle we could take a clonable iterator instead and use
Iterator::count, but it's probably not worth the extra complexity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It does not help that C tor has a set of parameters and a set of
configuration options with exactly the same names which configure
the same thing in two slightly different ways.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows us to allow passing in opaque HsMacKey objects,
rather than untyped byte slices.
Additionally, we now check both MAC and signature unconditionally,
to avoid the large timing side-channel. The small timing
side-channel of combining booleans with `&` is considered safe.
Part of #993.
|
| | |
|
| | |
|
| |
|
|
|
| |
rustdoc insisted on misindenting this before, and now it insists on
un-mis-indenting it.
|
| |
|
|
|
| |
Remove this todo as per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1246#note_2912104
|
| |
|
|
| |
IntroduceAckStatus
|
| | |
|
| |\
| |
| |
| |
| | |
Resolve most TODO HS comments in tor-cell
See merge request tpo/core/arti!1245
|
| | | |
|
| | |
| |
| |
| |
| | |
This module didn't have anything in it; nonetheless, removing it
does count as an API break since it was public.
|
| | |
| |
| |
| |
| | |
Yes, we still will need more accessors for onion services, but we
can add them as we find the need.
|
| | | |
|
| |/
|
|
|
|
| |
The type is a bit odd but this is a result of the underlying protocol.
I don't feel like inventing `IntroduceAckSuccess` that contains only
the extensions.
|
| |
|
|
| |
Closes #887.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We never want to create one of these from its parts except when we
are testing it; we only want to forward an Introduce1 message with a
new command on it.
|
| |
|
|
|
| |
We'll need to store this so that it can later on be used to complete
the hs_ntor handshake.
|
| |
|
|
|
|
|
|
| |
We'll want this because our hs_ntor handshake requires access to an
encoded version of the header independent from the actual encrypted
message.
part of #866.
|
| |
|
|
|
|
|
|
| |
If we didn't do this, we would need to transfrom
`EncodedLinkSpec`s into a `LinkSpec::Unrecognized`, which is not
semantically right. What's more, every user of this API wants to
consume encoded link specifiers, so encoding them early saves a
little effort.
|
| | |
|
| |
|
|
|
|
| |
This change is necessary so that we can build Extend2 messages
that have their LinkSpecs appear in a verbatim order as provided
in an INTRODUCE2 message or in a HS descriptor.
|
| |
|
|
|
| |
This version of bitflags now requires us to explicitly list the
traits that we want to derive for our bit-flags structs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
(This is the encrypted information inside the INTRODUCE2 cell; it's
used by the client to tell the service where to find its rendezvous
point.)
|
| |\
| |
| |
| |
| | |
tor-cell: Rename Rendezvous*::message to handshake_info.
See merge request tpo/core/arti!1045
|
| | |
| |
| |
| | |
Follow-up from !1038
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old code parsed and encoded a signature and a mac... but there
was no way to actually set them properly. Now EstablishIntro is
built around an EstablishIntroBody, and has the ability to check
signatures and macs.
Because there is no way to handle one of these messages if we can't
check the signature, we no longer accept unrecognized `auth_key` types
in this message.
I've added a test to make sure that we can validate a message from the
C tor implementation, and a test to make sure we can validate our
own cells. I also had to modify the previous tests so that their
keys were well-formed.
|
| | |
|
| | |
|
