summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell
Commit message (Collapse)AuthorAgeFilesLines
* fix: fix typosDimitris Apostolou2025-01-061-1/+1
|
* PoW: Consolidate feature flags into a single flag.Wesley Aptekar-Cassels2024-11-251-1/+1
| | | | | | | | | | | | | | | | | This replaces the hs-pow, hs-pow-full, hs-pow-v1, pow-v1, and pow-full features with a single hs-pow-full feature. It's possible that in the future we will want to split different schemes into different features, but we can do that when it comes up. For now, having this as a single flag makes it clearer what's going on, since the previous thing was not actually expressive enough to capture some things we care about (like "at least one pow scheme is enabled" that works in a future-compatible way). This change is not semver breaking since it's a experimental feature. Related: #1751
* tor-cell: add clippy allowsSteven Engler2024-11-201-0/+1
|
* hs-pow: Clarify a confusing comment in ProofOfWorkV1.Wesley Aptekar-Cassels2024-10-091-1/+1
| | | | Co-authored-by: Micah Elizabeth Scott <[email protected]>
* hs-pow: Rename seed to seed_head.Wesley Aptekar-Cassels2024-10-091-3/+3
| | | | | | Feedback from the hs-pow code review, the internal seed heading member should be seed_head instead of seed, for consistency. Very low impact change since the field name is not public.
* hs-pow: Refactor to prefer stub types rather than cfg sprawl.Wesley Aptekar-Cassels2024-10-094-29/+90
| | | | | | | | | | | | | | | | | | | | | | In this design, the thin multiplexing layer between PoW types is always available when onion services are in use, but the specific pow schemes (and their dependency libraries) are gated by crate features everywhere. There are now no new cfg() gates. When the pow-v1 scheme is disabled, we can parse `pow-params v1` lines into an empty type (so clients know a PoW scheme exists that might be supported if they were configured differently). We currently don't save the contents of unknown hsdesc items. On the relaycell side, the hs ext module already sets a strong precedent for keeping unrecognized data as a byte vec, and it doesn't provide a good way to signal soft parse errors like unrecognized optional extensions. There, the `v1` type is completely optional, and services lacking a pow scheme suggested by a client would see one of these 'unrecognized' blobs. This isn't necessarily helpful but it fits the rest of the design. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-hspow: Big refactor, dissolve this crateWesley Aptekar-Cassels2024-10-093-48/+61
| | | | | | | | | | | | | | | | | My previous strategy here was to try and centralize hspow in one crate, writing it like a self-contained feature. That introduced friction in the data types, prompting the use of simplistic types at the netdoc/cell layers and full-featured types in the optional modules. This changes tactics, dissolving the low-level parts of tor-hspow into tor-hscrypto and the high-level parts into hsclient/hsservice. Full featured types are used everywhere now, but the tradeoff is that compile-time configurability is a lot more pervasive. Anything that knows about PoW types at all needs to be fully configured out. I took this opportunity to try a more complete set of crate features, allowing users to configure individual PoW schemes. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-cell: Support encoding proofs-of-work in intro_payloadWesley Aptekar-Cassels2024-10-093-4/+111
| | | | | | | | | Like parameters, PoW solutions are versioned to account for multiple algorithms over time. A single solution of a specific version may accompany an INTRO1/2 as part of the encrypted extensions section. Its encoding may depend on the version. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-memquota: Explain choice of boundsIan Jackson2024-10-021-0/+2
| | | | | Properted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2459#note_3086841
* Revert "tor-cell: Use HasMemoryCostStructural, rather than Copy"Ian Jackson2024-10-021-1/+2
| | | | This reverts commit def8810156f8c2bf8f18ef9ad75a61601f6fea78.
* tor-cell: Use HasMemoryCostStructural, rather than CopyIan Jackson2024-10-021-2/+1
| | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2459#note_3086839
* Some HasMemoryCost impls in tor-cellIan Jackson2024-10-025-40/+100
|
* tor-cell: impl Eq, PartialEq, Hash for est_intro::DosParamsIan Jackson2024-02-211-1/+1
| | | | | | 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.)
* tor_cell: never construct empty DATA messages.Nick Mathewson2024-02-131-3/+28
| | | | | | | We never actually constructed these before, but now we enforce it at the API level. Part of #1269.
* tor_cell: Reject empty DATA messagesNick Mathewson2024-02-131-0/+3
| | | | | | | | | | | 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.
* educe: Use std's default for enums where default variant is unitIan Jackson2024-02-121-4/+2
| | | | | | | | | | | | | 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.
* tor-cell: Remove a now-unneeded allow(unused).Nick Mathewson2023-12-121-1/+0
|
* NtorV3Extension set encoding/decoding: include n_extensionsJim Newsome2023-12-071-7/+17
| | | | | | | | | | 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.
* 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-6/+12
|
* Add more reference links.Nick Mathewson2023-11-201-1/+5
|
* Improve documentation in/around DosParams extensionNick Mathewson2023-11-201-1/+11
| | | | | | 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.
* tor-cell: Remove unused by_type() functionNeel Chauhan2023-10-131-10/+0
|
* tor-cell: Add accessors for Begin.Nick Mathewson2023-09-271-0/+15
|
* cell: Add accessors to IntroduceHandshakePayloadNick Mathewson2023-08-161-0/+15
|
* cell: Add accessors to Introduce2.Nick Mathewson2023-08-161-0/+17
|
* cell: Add code to iterate over IntroEstablished extensionsNick Mathewson2023-08-151-1/+7
|
* cell, docs: Clarify what we mean by "Unrecognized".Nick Mathewson2023-08-151-2/+3
|
* cell: make establish_intro accept impl<Into<HsMacKey>>Nick Mathewson2023-08-141-15/+14
| | | | | | | | | | | 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.
* Fix typosDimitris Apostolou2023-07-221-1/+1
|
* tor-cell: Downgrade 2 TODO-HS to TODO-HSSNick Mathewson2023-06-162-2/+2
|
* tor-cell: HasRetryTime for IntroduceAckStatus: Confirm re CANT_RELAY (fmt)Ian Jackson2023-06-141-1/+1
| | | | | rustdoc insisted on misindenting this before, and now it insists on un-mis-indenting it.
* tor-cell: HasRetryTime for IntroduceAckStatus: Confirm re CANT_RELAYIan Jackson2023-06-141-1/+1
| | | | | Remove this todo as per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1246#note_2912104
* tor-cell: Add a doc comment for impl tor_error::HasRetryTime for ↵Ian Jackson2023-06-141-0/+4
| | | | IntroduceAckStatus
* tor-cell: impl HasRetryTime for IntroduceAckStatusIan Jackson2023-06-141-0/+14
|
* Merge branch 'tor-cell-todos' into 'main'Nick Mathewson2023-06-135-51/+8
|\ | | | | | | | | Resolve most TODO HS comments in tor-cell See merge request tpo/core/arti!1245
| * cell: Downgrade a couple more TODO HS comments.Nick Mathewson2023-06-131-2/+2
| |
| * cell: Remove relaycell::restrictNick Mathewson2023-06-131-34/+0
| | | | | | | | | | This module didn't have anything in it; nonetheless, removing it does count as an API break since it was public.
| * cell: Remove some TODOsNick Mathewson2023-06-133-10/+2
| | | | | | | | | | Yes, we still will need more accessors for onion services, but we can add them as we find the need.
| * cell: remove/localize "allow(dead-code)"Nick Mathewson2023-06-133-5/+4
| |
* | tor-cell: IntroduceAck: Add .success() function to give a ResultIan Jackson2023-06-131-0/+16
|/ | | | | | The type is a bit odd but this is a result of the underlying protocol. I don't feel like inventing `IntroduceAckSuccess` that contains only the extensions.
* proto: Convert MsgHandler API to expect a message, not a cell.Nick Mathewson2023-06-121-1/+15
| | | | Closes #887.
* cell: Add an accessor for the body of a Rendezvous2.Nick Mathewson2023-06-121-0/+6
|
* cell: Make EstablishRendezvous contain a RendCookie.Nick Mathewson2023-05-231-5/+2
|
* cell: Make Introduce2::new testing-only.Nick Mathewson2023-05-171-1/+6
| | | | | | We never want to create one of these from its parts except when we are testing it; we only want to forward an Introduce1 message with a new command on it.
* cell: Record the text of an INTRODUCE2 headerNick Mathewson2023-05-171-9/+39
| | | | | We'll need to store this so that it can later on be used to complete the hs_ntor handshake.
* cell: extract introduce headers into a new type.Nick Mathewson2023-05-171-20/+42
| | | | | | | | We'll want this because our hs_ntor handshake requires access to an encoded version of the header independent from the actual encrypted message. part of #866.
* Change CircTarget::linkspecs() to return an encoded list.Nick Mathewson2023-05-101-3/+3
| | | | | | | | 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.
* Rename UnparsedLinkSpec => EncodedLinkSpecNick Mathewson2023-05-101-3/+3
|
* Move responsibility for linkspec sorting to CircTarget.Nick Mathewson2023-05-101-3/+1
| | | | | | This change is necessary so that we can build Extend2 messages that have their LinkSpecs appear in a verbatim order as provided in an INTRODUCE2 message or in a HS descriptor.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 22:39:21 +0000