| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This lets us paramaterize types and functions by a particular relay cell
format. We use this e.g. to statically parameterize the cell crypto
functions, thereby removing some run-time branching in the hot path.
|
| |
|
|
|
| |
Different formats will use different ranges for the `recognized` and
`digest` fields.
|
| | |
|
| |
|
|
|
|
| |
The semantics of such a function that supports both the legacy V0 format
and the V1 packing and fragmentation format are a bit tricky. Since it's
not used outside of its module, we can simply remove it.
|
| |
|
|
|
|
|
|
|
|
|
| |
Prop 340:
https://spec.torproject.org/proposals/340-packed-and-fragmented.html
This updates the decoding API to support multiple versions of the relay
cell encoding, including the new encoding proposed in prop340 that
supports relay message packing and fragmentation.
This commit doesn't actually add support for that new encoding yet.
|
| |
|
|
|
| |
For consistency with the terminology proposed in
https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We only need Eq and PartialEq but given those we should have Hash too.
(We're going to want to be able to compare parameters for equality.)
|
| |
|
|
|
|
|
| |
We never actually constructed these before, but now we enforce it at
the API level.
Part of #1269.
|
| |
|
|
|
|
|
|
|
|
|
| |
If we don't reject these, they are a way to inject an undetected
traffic signal. (This is LOW severity, since we only accept DATA
when a stream is open, since DATA messages are rate-limited,
and since using length==1 is nearly as effective.)
Closes #1269.
This is TROVE-2024-001.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rust 1.66, std's default works properly for enums, provided that
the default variant is a unit.
Review all uses of `#[educe(default)]` on enums and replace them with
std where possible, which is most of them.
In 1.66 and later, std's `#[derive(Default)]` doesn't infer any
generic bounds on the derived impl, where it's an enum - since the
unit variant can always be constructed. So this change doesn't add
any generic bounds and is not API-visible.
|
| | |
|
| |
|
|
|
|
|
| |
When using the `arti-client` crate in other contexes, the Rust compiler
sometimes has difficulties with determining the current type in this
particular case, due to a collision with the popular serde json crate,
which also provides an implementation for converting u8.
|
| | |
|
| |
|
|
|
| |
We should remove these once we do our final renaming here,
but for now we may as well avoid a breaking change.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is pure renaming, done automatically with rust-analyzer.
Comment fixes and other cleanups will be in the subsequent commits.
We're doing this renaming because we need a name for
the combination of a `RelayMsg` and an `Option<StreamId>`
that we use when we have a `RelayMsg`
we intend to route to a given stream or circuit internally.
Previously we called this a `RelayCell`,
but that name was already somewhat inaccurate,
and will become _very_ inaccurate with the arrival of prop340,
which breaksthe 1:1 relationship between relay cells
and relay messages.
(If we didn't do this renaming now, we'd soon be making
the relationship between `UnparsedRelayCell`and `RelayCell`
many-to-many, which would be ridiculous and confusing.)
The `RelayMsgOuter` name is a placeholder:
We expect that we'll want to rename this type,
and may also want to rename `RelayMsg`,
and unify our vocabulary in other areas too.
But such a renaming will have to wait
for a larger discussion affecting the specifications,
so that we can use the same vocabulary everywhere.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
An encoded set of extensions in the ntorv3 handshake includes a header
with the number of extensions. This change adds that header.
It also changes `write_many_onto` to take a slice instead of an
iterator, since we need to know the number of extensions up-front. In
principle we could take a clonable iterator instead and use
Iterator::count, but it's probably not worth the extra complexity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes that we have to adjust for are as follows:
* In x25519-dalek:
* `StaticSecret` is now behind a feature.
* `StaticSecret::new` is deprecated in favor of
`StaticSecret::random_from_rng`.
* StaticSecret no longer does its own clamping.
* In ed25519-dalek:
* `SecretKey` has (in effect) been renamed to `SigningKey`. The name
`SecretKey` is now an alias for `[u8; 32]`.
* `SigningKey` is effectively a keypair, since it contains a
public key as well.
* `PublicKey` has been renamed to `VerifyingKey`.
* The functions to extract a signing key and verifying key have
been renamed as you might expect.
* `ExpandedSecretKey` has been moved to `hasmat` and no longer
implements `sign`.
* `ExpanededSecretKey` now has as its elements a scalar and a hash
prefix.
* Various functions that took `&[u8]` now take `&[u8; N]`.
* We no longer need a wrapper for older versions of rand.
There is a single test in tor-keymgr that does not pass. I've
marked it as ignore for now, in hopes that @gabi-250 can help me
figure it out.
This closes #808. There are several changes I want to make before
we merge, however. They are marked with TODO DALEK.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It does not help that C tor has a set of parameters and a set of
configuration options with exactly the same names which configure
the same thing in two slightly different ways.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This changes the internal representation to be `NonZeroU32` instead of
just `u32`.
Various places where a circuit ID is optional now use `Option<CircId>`.
Fixes a bug in `CircIdRange::sample` that would previously return a
circuit ID of 0, when the rng returned 0x8000_0000 for a low range.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Write more of IptEstablisher.
See merge request tpo/core/arti!1510
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
doc: fix malformatted comment in SliceWriterError
See merge request tpo/core/arti!1503
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
This allows us to allow passing in opaque HsMacKey objects,
rather than untyped byte slices.
Additionally, we now check both MAC and signature unconditionally,
to avoid the large timing side-channel. The small timing
side-channel of combining booleans with `&` is considered safe.
Part of #993.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| | |
|
| | |
|
| |
|
|
|
| |
rustdoc insisted on misindenting this before, and now it insists on
un-mis-indenting it.
|
| |
|
|
|
| |
Remove this todo as per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1246#note_2912104
|
| |
|
|
| |
IntroduceAckStatus
|
| | |
|
