| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
`OutboundRelayLayer::decrypt_outbound()` is for decrypting cells moving
*away* from the client (in the "forward direction").
|
| |
|
|
|
|
|
|
|
| |
When we want to send Replace padding (that is, padding that should
only be sent if nothing else is queued) to hop 1, we can allow it to
be replaced by cells from _any_ circuit being sent over the same
channel. (Nobody but hop 1 can tell the difference.)
Closes #2169
|
| | |
|
| |
|
|
|
|
|
| |
Replaced use of [`static_assertions::const_assert`] with the newly
available "assert in const" pattern.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
|
|
| |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| | |
|
| |
|
|
|
|
|
| |
- Made an equality assertion between two constants compile-time, resolving a
TODO.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See torspec#332.
|
| |
|
|
| |
Implements part of proposal 358.
|
| |
|
|
| |
This required some renaming, so that the types and their codes matched.
|
| |
|
|
|
|
|
| |
This type will, because of prop358, be shared by ntorv3,
hs-ntor, and probably other future handshakes.
There will also be a CircResponseExt type.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now instead of using CryptState for everything, we have specific
types for each role and direction of crypto.
This turned up a harmless-so-far bug in our onion service code: as
an onion service, we were using _client_ crypto layers to respond to
a client request. That's not correct, and wouldn't have worked
with CGO. Instead, we need to use relay crypto layers, wrapped
as client layers.
Closes #1975.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of the trait was to parameterize the tor1 cell crypto
on the different possible relay cell layouts.
It made sense to have this trait when we thought we would implement
the new cell layout for prop340 (packed-and-fragmented) well before
we implemented CGO.
But it now appears all but certain that CGO will land long before
we make any more headway on prop340. Therefore,
it doesn't make sense to carry the ability to customize `tor1`
for other relay cell layouts.
Removing this trait saves a fair bit of complexity.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the code to copy a SendmeTag rather than returning a
slice. This isn't actually a big change: sending a slice already
required 16 bytes (on 64-bit platforms), so sending a SendmeTag
around isn't a big deal.
We rely extensively on the compiler's ability to optimize away
all the checking in code like this:
```
let slice: &[u8];
let a: [u8;N] = slice[0..N].try_into().expect("Nope");
```
I've spot-checked it somewhat with "cargo-show-asm", but
it could use more thorough checking.
Closes #1956.
|
| |
|
|
|
|
| |
This lets us use `Aes128Dec` and `Aes128Enc` in place of plain old
`Aes128`, which can be less space-efficient depending on the
back-end.
|
| |
|
|
| |
(The u8 code was written before RelayCellFormat::V1 was introduced.)
|
| | |
|
| |
|
|
|
|
| |
See discussion at torspec#328: it's important that our
SENDME authentication tag always be taken based on the
_encrypted_ cell.
|
| | |
|
| |
|
|
|
|
|
|
| |
This provides all the operations from proposal 359,
along with the necessary integration and unit tests to make sure
that they are behaving properly.
Closes #1943
|
| | |
|
| |
|
|
|
|
|
| |
These are a tweakable block cipher, and a pseudorandom byte stream.
This commit includes test vectors, which were generated from the
Python reference implementation and confirmed with a less optimized
Rust implementation.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
(We'll need these tags both to implement authenticated SENDMES
at the relay side, and also to make sure that cgo is generating them
correctly.)
|
| |
|
|
|
|
| |
CGO will need this argument so that it can authenticate
the command as part of its crypto operations.
(Trying to meddle with RELAY vs RELAY_EARLY will no longer work!)
|
| |
|
|
|
|
| |
It seems very likely that, as with client crypto,
we'll want relay crypto to separable into "forward" and "reverse"
objects, so that the two can be used more or less independently.
|
| |
|
|
|
|
|
|
|
|
| |
This makes the behavior of "originate" match the behavior of
OutboundClientLayer::originate_for, which creates the message
_and_ encrypts it. This will be necessary for CGO, where
"originate" and "encrypt" are not easily separated operations.
(Nothing uses this trait yet, since relay circuits aren't yet a thing,
so it's a good time to get it right.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Since we're about to have a second kind of relay cell crypto,
it makes sense to move this module.
This change is pure code movement.
|
| |
|
|
| |
(Also note a couple of other CGO-related issues)
|
| |
|
|
| |
ntor v3 is now always enabled.
|
| |
|
|
| |
- `try_fill_bytes()` is no longer a member of RngCore.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| | |
|
| | |
|
| | |
|
| | |
|
