| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Log conventions
Closes #1906
See merge request tpo/core/arti!2966
|
| | | | | |
|
| | | |/
| |/| |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Replace signal-hook-async-std with async-signal to fix RUSTSEC-2024-0384
Closes #1867
See merge request tpo/core/arti!2960
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Change "release" to optimize for peformance.
Closes #1954
See merge request tpo/core/arti!2959
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
(Previously, it was optimized for size, leading to problems like
\#1336.)
For any purposes that need the old optimize-for-size behavior,
I've added a new "release-small" target. I've also moved the
"strip=debuginfo" behavior from maint/binary_size to this new target,
since cargo started supporting "strip" in 1.59.
Closes #1954.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
ci: Upgrade shadow version to get TCP FIN fix
See merge request tpo/core/arti!2958
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
tor-proto: Prevent congestion control extension during ntor-v3 extend
See merge request tpo/core/arti!2957
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
This was missed in commits ccb65961 and eeda643f. While
`params.ccontrol.is_enabled()` should always be false because of those
earlier commits which ensure we don't enable congestion control, we were
missing the defense-in-depth conditions here that would alert us if we
accidentally did enable congestion control.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Implement congestion control handshake negotiation
Closes #1817
See merge request tpo/core/arti!2932
|
| | |
| |
| |
| |
| | |
This means that even with the "flowctl-cc" feature enabled, we shouldn't
try to negotiate congestion control.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Congestion control is not completely working correctly, and is not fully
implemented (XON/XOFF). This commit adds a new experimental "flowctl-cc"
feature to enable the congestion control extension during the ntor-v3
handshake.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
We use this method to decide whether to allow receiving stream SENDMEs,
and also whether we should send stream SENDMEs.
|
| | |
| |
| |
| |
| |
| |
| | |
`OpenStreamEnt::put_for_incoming_sendme()` calls
`StreamSendFlowControl::put_for_incoming_sendme()`, which returns an
error if the `StreamSendFlowControl` is in XON/XOFF mode. So we don't
need this extra check.
|
| | |
| |
| |
| |
| | |
Congestion control tells us whether we should use stream or XON/XOFF
flow control.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Previously new stream entries required a `StreamSendWindow`, but to
support other flow control algorithms, we want new stream entries to
take a `StreamSendFlowControl` instead.
This also deduplicates the `StreamSendWindow` creation code.
|
| | |
| |
| |
| |
| |
| |
| | |
This doesn't do anything yet, so is effectively like not having stream
flow control.
This should be implemented as part of arti#534.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Also add one for the sendme_inc validity function.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Circuit handshake negotiation for congestion control has been added in
previous commit so stop pinning the algorithm.
This commit marks the start of congestion control usage by arti client.
Closes #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we ever receive a stream-level SENDME from the Exit while the circuit
is under congestion control (Vegas), it is a protocol violation so close
the circuit.
This is important in order to avoid yet another side channel with cells
that would be essentially ignored silently.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds a new function to the CongestionControl object that returns
true or false on if stream level SENDMEs are allowed by the underlying
algorithm.
Congestion control Vegas doesn't allow them as in it retires them and so
we avoid sending them for that algorithm.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| | |
These pass through congestion control state to the reactor, and aren't
actually hooked up to the congestion control code yet.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This puts in, based on the circuit parameters, the CC extension request
in the CREATE and EXTEND requests.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Congestion control can change the circuit parameters if the relay we are
negotiating with doesn't support FlowCtrl=2.
This commit adds a function in the circuit builder that will apply any
changes to the circuit parameters of the hop based on the hop protocol
values. For now, only congestion control applies.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids cloning the object and instead allows us to have a
CircParameters per hop on the circuit path. This will come handy with
congestion control where each hop might have different congestion
control parameters.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CircParameters is built before path selection and thus once we start
building the hops, we can't access the consensus values that were used
to build it in the first place.
For congestion control, we require a fallback algorithm in case the hop
doesn't support FlowCtrl=2.
This commit adds a "fallback_alg" to the CC parameters which will be
used for this exact case.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When receiving the congestion control response extension, evaluate our
state and set the sendme_inc if valid in our circuit parameters.
For this, a series of helper functions is needed.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is required because circuit ntor v3 handshake can negotiate circuit
level parameters and thus able to change any values.
Needed for congestion control ntorv3 handshake extension for which the
sendme increment is negotiated.
Part of #1817
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| | |
| | |
| | |
| | | |
various crates: MSRV TODO standardization and cleanup of an old TODO
See merge request tpo/core/arti!2945
|