summaryrefslogtreecommitdiff
path: root/crates/tor-cell/tests
Commit message (Collapse)AuthorAgeFilesLines
* relay-cell: Update relay cell decoding API for prop340Jim Newsome2024-03-121-5/+7
| | | | | | | | | | | 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.
* Rename UnparsedRelayCell -> UnparsedRelayMsgJim Newsome2024-03-121-2/+2
| | | | | For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
* tor_cell: never construct empty DATA messages.Nick Mathewson2024-02-131-1/+1
| | | | | | | We never actually constructed these before, but now we enforce it at the API level. Part of #1269.
* clippy: consequential rustfmtIan Jackson2024-01-021-2/+1
|
* clippy: Use infallible callsIan Jackson2024-01-021-2/+1
| | | | Resolves clippy complaints about needless fallible conversions.
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-141-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove RngCompatExt.Nick Mathewson2023-11-291-2/+2
| | | | | | | | | | This code was needed with the old version of dalek-cryptography, which wasn't compatible with up-to-date versions of the `rand` crate(s). But now that we've upgraded, we can drop this. (We could have left it around and deprecated it, but we are already making a breaking change to tor-llcrypto by upgrading dalek-cryptography.)
* Convert to the latest versions of dalek-cryptographyNick Mathewson2023-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use HandshakeType in Extend2 and CircuitExtender::beginJim Newsome2023-11-271-2/+3
|
* Add a caret_int HandshakeType for HTYPE constantsJim Newsome2023-10-261-3/+8
|
* Change `CircId` to never be zeroJim Newsome2023-10-251-9/+9
| | | | | | | | | | 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.
* Convert StreamId to NonZeroU16Jim Newsome2023-10-251-11/+10
|
* cell: Make EstablishRendezvous contain a RendCookie.Nick Mathewson2023-05-231-1/+1
|
* Change CircTarget::linkspecs() to return an encoded list.Nick Mathewson2023-05-101-1/+5
| | | | | | | | If we didn't do this, we would need to transfrom `EncodedLinkSpec`s into a `LinkSpec::Unrecognized`, which is not semantically right. What's more, every user of this API wants to consume encoded link specifiers, so encoding them early saves a little effort.
* linkspec: Make LinkSpecType public.Nick Mathewson2023-05-101-4/+7
| | | | | This lets us check the type of an `EncodedLinkSpec` as well, and lets us remove an interface that took a raw u8.
* Rename UnparsedLinkSpec => EncodedLinkSpecNick Mathewson2023-05-101-4/+4
|
* tor-cell: Add code for the payload of an hs-ntor handshake.Nick Mathewson2023-03-061-0/+48
| | | | | | (This is the encrypted information inside the INTRODUCE2 cell; it's used by the client to tell the service where to find its rendezvous point.)
* tor-cell: Rename EstablishIntro{Body => Details}Nick Mathewson2023-03-011-4/+4
|
* tor-cell: Make EstablishIntro do signaturesNick Mathewson2023-03-011-22/+72
| | | | | | | | | | | | | | | | The old code parsed and encoded a signature and a mac... but there was no way to actually set them properly. Now EstablishIntro is built around an EstablishIntroBody, and has the ability to check signatures and macs. Because there is no way to handle one of these messages if we can't check the signature, we no longer accept unrecognized `auth_key` types in this message. I've added a test to make sure that we can validate a message from the C tor implementation, and a test to make sure we can validate our own cells. I also had to modify the previous tests so that their keys were well-formed.
* Change several cfgs to refer to new feature names.Nick Mathewson2023-02-281-4/+4
|
* Mark new tests as onion-service-onlyNick Mathewson2023-02-281-0/+3
|
* tor-cell: Support extensions in INTRODUCE{1,2}Nick Mathewson2023-02-281-12/+4
|
* tor-cell: Implement IntroduceAck and IntroEstablishedNick Mathewson2023-02-281-0/+19
| | | | | These are fairly simple, since the bulk of them is just an extension list with no supported extensions.
* tor-cell: Implement rendezvous1 and rendezvous2.Nick Mathewson2023-02-281-0/+22
|
* Rename onion-* cargo features to hs-* in tor-* cratesIan Jackson2023-02-281-4/+4
| | | | Fixes #756
* Merge branch 'hs-cells-1' into 'main'Nick Mathewson2023-02-161-26/+18
|\ | | | | | | | | Start refactoring hs cell implementations See merge request tpo/core/arti!1020
| * tor-cell: Use a more generic mechanism for managing extensionsNick Mathewson2023-02-151-23/+15
| | | | | | | | | | | | | | | | | | | | Several HS message types have an extension list type. They all use the same framing for extensions, but each of them has separate extension types and separate extension namespaces. This commit simplifies establish_intro a little, and adds support for maintaining unrecognized extension types--at the expense of some new internal code.
| * tor-cell: Extract establish-intro into its own module.Nick Mathewson2023-02-151-1/+1
| | | | | | | | | | | | | | Some of the HS message types have a lot of dependent types, like extensions and options for those extensions, and so on. Except when those extensions are portable across cell types, it makes sense to put them in their own modules.
| * tor-cell: rename onion_service module to hsNick Mathewson2023-02-151-4/+4
| |
* | tor-cell: Add a new UnparsedRelayCellNick Mathewson2023-02-151-2/+14
| | | | | | | | | | | | We'll use this to router relay messages on a circuit to the appropriate stream, and hand them to that stream, without parsing the message until the stream has been determined.
* | tor-cell: Refactor relay cells to copy much lessNick Mathewson2023-02-151-2/+2
|/ | | | | | | | | | | | | We now manipulate raw relay cell bodies as (an alias for) `Box<[u8;509]>` rather than as (an alias for) `[u8;509]`. This enables us to do much less copying. It will become more important soon, as we defer parsing relay cell bodies even longer. Related to #7. We also use SliceWriter to avoid allocating a Vec<> for every relay message we want to encode, and instead encode directly into the cell.
* Change tor_bytes::Error::BadMessage to a Cow.Nick Mathewson2023-02-093-12/+17
| | | | | | | | | | Actually, to avoid making a breaking change, I'm deprecating BadMessage and creating a new InvalidMessage variant that takes a Cow. This way I don't need to track every crate that re-exposes tor_bytes::Error and call this a breaking change in those. Making this change will allow tor_bytes errors to be much more helpful.
* cell: Parameterize ChannelCodec::decode and encode.Nick Mathewson2023-02-091-5/+6
| | | | | | | This change lets us use ChannelCodec to encode and decode any restricted channel message type we want. (Later on, we'll turn the related Codec class in tor-proto into a more type-restricted version of this.)
* tor-cell: Rename RelayMsg and RelayCell-related types.Nick Mathewson2023-02-072-20/+20
| | | | Thanks to rust-analyzer for making this simple.
* tor-cell: Rename ChanMsg and ChanCell-related types.Nick Mathewson2023-02-072-14/+14
|
* tor-cell: Remove RelayMsg methods that are duplicated in RelayMsgClass.Nick Mathewson2023-02-072-2/+2
|
* tor-cell: Remove ChanMsg methods that are duplicated in ChanMsgClass.Nick Mathewson2023-02-072-10/+6
|
* tor-cell: Use macro to generate ChanMsg too.Nick Mathewson2023-02-071-2/+2
|
* tor-cell: Change all variants of RelayMsg to have a body.Nick Mathewson2023-02-071-3/+3
| | | | | Previously, there were some unit variants, but that makes things quite awkward for #525.
* Disable clippy::unlinlined-format-argsNick Mathewson2023-01-274-0/+6
| | | | | | | | This warning kind of snuck up on us! (See #748) For now, let's disable it. (I've cleaned it up in a couple of examples, since those are meant to be more idiomatic and user-facing.) Closes #748.
* msg::{CreateFast/CreatedFast}: Rename accessor to (into_)body()Neel Chauhan2022-12-181-2/+2
|
* tor-cell: Rename for_client and for_relayEmil Engler2022-10-211-5/+5
| | | | | | | This commit renames the for_client and for_relay functions to from_client and from_relay respectively, in order to indicate their origin, as the term "for" is more likely to indicate a destination, which is not true in that situation.
* Fix various typos (using typos tool and hand-inspection)Nick Mathewson2022-10-181-2/+2
|
* Implement Introduce2 tor cellYuan Lyu2022-09-211-1/+3
| | | | | Reuse the same Introduce inner body implementation of Introduce1.
* Implement onion service Introduce1Yuan Lyu2022-09-081-5/+56
|
* Clean up EstablishIntro cellYuan Lyu2022-08-251-0/+68
|
* tor-cell: PaddingNegotiate::start: take IntegerMillisecondsIan Jackson2022-08-171-1/+3
|
* chancell: PaddingNegotiate: Provide two constructors, not oneIan Jackson2022-08-161-1/+7
| | | | | | | | We don't really want the caller to pass ignored timeout parameters. And this makes more semantic sense. The stop constructor uses zero, which is what C Tor does. See https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/76
* Implement establish rendezvous cellYuan Lyu2022-08-051-0/+38
|
* tor-cell: Make encoding method signatures fallible.Nick Mathewson2022-07-113-5/+11
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:42:50 +0000