| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| | |
Implements proposal 358.
Closes #1946.
|
| | |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
Previously it required the caller to import a whole bunch of stuff.
|
| | |
| |
| |
| | |
It is no longer hs only.
|
| | |
| |
| |
| | |
We're going to use it for ntorv3 extensions as well.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 doesn't make much change yet, but does save us an allocation
when handling SENDMEs.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a more efficient representation for the tag on an
authenticated SENDME message: it comes in at 21 bytes.
Previously, we used Vec<u8>, which has 24 bytes of overhead
(on a 64 bit system), plus malloc overhead, plus 20 bytes of
allocated tag.
We had a similar type to this as
`tor_proto::congestion::sendme::CircTag`,
but it could only accomodate 20-byte values.
I don't expect that we will have enough of these simultaneously that
the memory savings will matter, but the allocation savings could be
significant.
|
| | |
| |
| |
| |
| |
| | |
This lets us use `Aes128Dec` and `Aes128Enc` in place of plain old
`Aes128`, which can be less space-efficient depending on the
back-end.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
tor-proto: New extend() and create_firsthop() to pick between ntor and ntor3
Closes #1970
See merge request tpo/core/arti!2967
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Since we have create_firsthop() and extend(),
we should recommend them in our documentation,
instead of recommending the no-longer-best methods.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We don't want to be thinking about ntor vs ntor3
in circmgr.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the future, when we add more circuit handshakes (PQ anyone?)
we'll want to have the logic for choosing which to use be unified.
Almost nobody calling tor-proto should need to care which circuit
handshake is going to be used.
Closes #1970.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-keymgr: Refactor ItemMetadata to support certificate metadata
Closes #1913
See merge request tpo/core/arti!2921
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
circmgr: Make path module public on "--features=experimental-api"
Closes #1981
See merge request tpo/core/arti!2990
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Back in 4c1eb94173521bc5104449327650e20ffe32afa7, for sensible
reasons, we made `tor_circmgr::path` a crate-private module. But
when we did that, we lost the ability for callers to construct
circuits with custom paths.
This will make it possible for callers to build custom circuits
again, without committing to a very-long-term API for that.
Closes #1981.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
fs-mistrust: fix build on non-unix systems
See merge request tpo/core/arti!2962
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | | |
The TrustAdminOnly enum value is only defined for unix systems.
Consider this fact in mistrust_build function to fix build on
e.g. Windows systems.
|
| | | | |
| | | |
| | | |
| | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2946#note_3192334
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We don't use it outside this branch, so might as well move it there.
|
| | | | |
| | | |
| | | |
| | | | |
We already do this, using `note_conflux_handshake_result`.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Prompted by opara's suggestion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2946#note_3192319
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
