| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
- 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()`
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduce the new constructor and call it at the error generation
sites. But there is still not yet any functional change.
Change the type of Truncated's field to be Sensitive.
The original reason for not doing this no longer applies, since we
don't generally want to open-code construction of this variant.
Conveniently, changing the type means we get to find all the sites
where one *is* constructed and adjust them.
In reader.rs and tor-proto we can just call incomplete_error.
In tor-cell, there's a call site where we previously provided an
underestimate, and where the Reader isn't available. We adjust that
ad-hoc but this is fine because the error variant will
change. (relaycell is using a Reader from from_slice.)
|
| | |
|
| |
|
|
| |
This will allow us to fix #1592, but it doesn't do so yet.
|
