| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We want the ability to send the same handshake request in parallel
on multiple introduce circuits. This implies encoding the client
handshake more than once.
(Sadly we can't _actually_ do this in the protocol as it stands,
since the onion service can use a separate KP_hss_ntor for each
introduction point; I'll add a comment to that effect later.)
|
| | |
|
| |
|
|
| |
This is still not the most beautiful interface, but it'll do for now.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
There were two bugs here that made the behavior unlike that of C
tor: we had swapped the MAC inputs, and we had forgotten to include
the public key X in the input.
|
| |
|
|
| |
We'll want these so we can implement some test vectors.
|
| |
|
|
|
|
|
| |
I think that these Input structs had been defined so that we could
use hs_ntor interchangeably with other handshakes. The trouble is,
though, that it doesn't really work like any other handshakes we
have.
|
| |
|
|
|
|
| |
Note that some of the invocations for this function seem to put the
key and the message in a questionable order. But that's a thing to
figure out later, while debugging.
|
| | |
|
| | |
|
| |
|
|
| |
The `new` function is deprecated in x25519-dalek 2.0.0-rc.2
|
| |
|
|
| |
Fixes #756
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
| |
This is a little tricky, but I think that we're not actually
exposing too much here. I expect we'll need to tweak this stuff
between now and our final version.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |
|
|
|
|
|
| |
This is the hunks from running the rune in maint/adhoc-add-lint-blocks
but which require some subsequent manual fixup: usually, deleting
now-superfluous outer allows, but in some cases manually putting back
lints that the adhoc script deleted.
|
| |
|
|
|
| |
It looks like, despite a few false starts, they've got this warning
right; there weren't any false positives.
|
| |
|
|
|
|
|
|
| |
Everything that is a secret encryption key, or an input that is used
to produce a secret encryption key, has to get zeroized. And that's
all!
Closes #254.
|
| |
|
|
|
|
|
|
|
|
| |
This does not yet make sure that `SecretBuf` is used where it
_should_ be, but at least it ensures that most uses of `SecretBytes`
will indeed act as intended, and make sure that whatever they
contain is zeroized.
It requires some corresponding changes to method calls for
correctness and type conformance.
|
| |
|
|
|
|
|
|
| |
This change was a bit annoying, since most of this code _can't_ fail,
and so the only reasonable response is to wrap the input in an
internal error... except for one case where we're actually encoding
a caller-provided message, so we _do_ want to wrap the EncodeError
from tor_bytes.
|
| |
|
|
|
|
| |
There were only a few of these. Removing it required porting
everything to use `write_and_consume` instead, and handling its
(potential) errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comprises four renames:
```
write_onto -> write_onto_infallible
write_into -> write_into_infallible
write -> write_infallible
writer_and_consume -> write_and_consume_infallible.
```
The rest of this branch will be concerned with replacing these
`_infallible` methods with ones that return a `Result`. This is
part of #513.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements a higher-level API for the ntor v3 handshake, in line
with that exposed by the ntor handshake. It does not, however, use the
existing `ClientHandshake` trait, due to fundamental differences in the
handshakes (namely, that the v3 handshake can include some additional
extra extension data).
Currently, the higher-level API assumes circuit extension, and copies
the (undocumented!) magic verification string from c-tor that indicates
this usage.
A rudimentary set of functions for serializing and deserializing
extensions to be sent with the handshake is also included, implementing
the protocol in proposal 332 § A.2. Currently, it only implements the
congestion control extensions specified in proposal 324 § 10.3.
part of arti#88
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- arti#448 and arti!607 highlight an issue with upgrading `rsa`: namely,
the `x25519-dalek` version previously used has a hard dependency on
`zeroize` 1.3, which creates a dependency conflict.
- However, `x25519-dalek` version `2.0.0-pre.1` relaxes this dependency.
Reviewing the changelogs, it doesn't look like that version is
substantially different from the current one at all, so it should be
safe to use despite the "prerelease" tag.
- The new `x25519-dalek` version also bumps `rand_core`, which means we
don't have to use the RNG compat wrapper in `tor-llcrypto` as much.
closes arti#448
|
| |
|
|
|
|
|
|
|
| |
Some of these were for decoding particular objects (we now say
what kind of objects), and some were unrelated tor_cert errors that
for some reason we had shoved into a tor_bytes::Error.
There is now a separate tor_cert::CertError type, independent from
tor_cert's use of `tor_bytes::Error` for parsing errors.
|
| |
|
|
|
| |
This avoids adding additional information for now; that will come on
the next commits.
|
| |
|
|
|
|
| |
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
|
| |
|
|
|
|
|
|
| |
Now that we require Rust 1.56, we can upgrade to AES 0.8. This
forces us to have some slight API changes.
We require cipher 0.4.1, not cipher 0.4.0, since 0.4.0 has
compatibility issues with Rust 1.56.
|
| |
|
|
|
| |
Remove all `use` statements for `TryFrom` and `TryInto`. These are
now redundant in Rust 2021.
|
| |
|
|
| |
(We'll have a BadChanHandshake soon.)
|
| |
|
|
|
|
|
|
| |
There was only one use of this, and it was in as-yet-unused relay-only
code.
Removing this type required refactoring the relay onion handshake code
to use its own error type, which is probably clever anyway.
|
| | |
|
| | |
|
| |
|
|
|
| |
We generally try to track the latest rust-crypto traits when we can:
fortunately, this upgrade didn't break much, considering.
|
| |
|
|
|
|
|
|
| |
We want to only use TODO in the codebase for non-blockers, and open
tickets for anything that is a bigger blocker than a TODO. These
XXXXs seem like definite non-blockers to me.
Part of arti#231.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather like e8e9699c3c239d6c30f9ad414f15d3bad6ec03fd ("Get rid of
tor-proto's ChannelImpl, and use the reactor more instead"), this
admittedly rather large commit refactors the way circuits in `tor-proto`
work, centralising all of the logic in one large nonblocking reactor
which other things send messages into and out of, instead of having a
bunch of `-Impl` types that are protected by mutexes.
Congestion control becomes a lot simpler with this refactor, since the
reactor can manage both stream- and circuit-level congestion control
unilaterally without having to share this information with consumers,
meaning we can get rid of some locks.
The way streams work also changes, in order to facilitate better
handling of backpressure / fairness between streams: each stream now has
a set of channels to send and receive messages over, instead of sending
relay cells directly onto the channel (now, the reactor pulls messages
off each stream in each map, and tries to avoid doing so if it won't be
able to forward them yet).
Additionally, a lot of "close this circuit / stream" messages aren't
required any more, since that state is simply indicated by one end of a
channel going away. This should make cleanup a lot less brittle.
Getting all of this to work involved writing a fair deal of intricate
nonblocking code in Reactor::run_once that tries very hard to be mindful
of making backpressure work correctly (and congestion control); the old
code could get away with having tasks .await on things, but the new
reactor can't really do this (as it'd lock the reactor up), so has to do
everything in a nonblocking manner.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #163
|
| | |
|
| | |
|
| | |
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
