summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell
Commit message (Collapse)AuthorAgeFilesLines
* tor-cell: add `Xon`/`Xoff` cellsSteven Engler2025-06-092-0/+175
|
* arti, cell, dirclient: Use expect instead of unwrap.Nick Mathewson2025-05-291-2/+3
| | | | | | Clippy nightly detects this problem, though earlier clippy verisons haven't. The common element here is applying unwrap() to the result from a write!().
* cell: fix warning from nightly about unused function.Nick Mathewson2025-05-291-0/+1
|
* Add methods for getting proof-of-work extension from intro request.Wesley Aptekar-Cassels2025-05-272-1/+10
|
* cell: Teach extlist definition macro to make conditional extensionsNick Mathewson2025-05-072-1/+7
| | | | | We need the macro to propagate only certain #[meta] values to all places where a case is used.
* cell: Implement SubprotocolRequest extension from prop346.Nick Mathewson2025-05-071-1/+138
| | | | Part of #1945.
* cell: Unify HS-ntor and ntor-v3 extensions.Nick Mathewson2025-05-076-32/+22
| | | | | | Implements proposal 358. Closes #1946.
* cell,proto: Split request/response extensions into seprate typesNick Mathewson2025-05-071-21/+44
| | | | Implements part of proposal 358.
* cell: Use ExtList to implement CircRequestExt.Nick Mathewson2025-05-072-105/+100
| | | | This required some renaming, so that the types and their codes matched.
* Rename NtorV3Extension to CircRequestExtNick Mathewson2025-05-071-18/+19
| | | | | | | This type will, because of prop358, be shared by ntorv3, hs-ntor, and probably other future handshakes. There will also be a CircResponseExt type.
* cell: Make decl_extension_group macro more self-contained.Nick Mathewson2025-05-074-14/+21
| | | | Previously it required the caller to import a whole bunch of stuff.
* cell: Clarify documentation in extlist.rs.Nick Mathewson2025-05-071-11/+10
| | | | It is no longer hs only.
* cell: move ExtList module out of hs module.Nick Mathewson2025-05-075-7/+5
| | | | We're going to use it for ntorv3 extensions as well.
* proto: Use SendmeTag in place of CircTagNick Mathewson2025-05-061-4/+2
| | | | | This doesn't make much change yet, but does save us an allocation when handling SENDMEs.
* tor-cell: define a new SendmeTag typeNick Mathewson2025-05-061-9/+149
| | | | | | | | | | | | | | | | 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.
* cell, proto: Use correct Data sizes for v1 relay cellsNick Mathewson2025-04-162-7/+29
| | | | | | | | | | | | Since v1 cells have a longer tag, they can fit less data into a single cell. Ah well, that's the cost of improved security. The code in data.rs is a little wonky, in that it currently requires its buffer to be exactly the maximum size for a data cell. We have a TODO about fixing that in the future, but for now I've moved it to use a boxed slice rather than a boxed array. Part of #1944.
* cell: Remove the deprecated Data::split_from().Nick Mathewson2025-04-161-14/+0
|
* Note some places where we need updates for #1944.Nick Mathewson2025-04-162-0/+8
| | | | (Also note a couple of other CGO-related issues)
* tor-cell: Make conflux::V1Nonce opaque, add constructor.Gabriela Moldovan2025-04-081-7/+30
| | | | We will soon need to construct `V1Nonce`s.
* tor-cell: Copy ConfluxSwitch::seqno in getter.Gabriela Moldovan2025-04-081-0/+1
| | | | `u32` is `Copy`, so the getter doesn't need to return a ref.
* Merge branch 'interface-abstraction-of-the-daleks' into 'main'Nick Mathewson2025-03-181-1/+0
|\ | | | | | | | | Wrap x25519-dalek and ed25519-dalek types. See merge request tpo/core/arti!2868
| * Wrap ed25519-dalek types.Nick Mathewson2025-03-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | With this change, we'll no longer need to expose the types from dalek-cryptography as part of our API, and we'll have more freedom to switch ed25519 implementations, or to upgrade to a newer `rand` ahead of their schedule. Unlike with x25519-dalek, I had to tweak the API a bit: There's no way to get a &PublicKey out of a Keypair now, and implementing the old ed25519-dalek traits seemed unnecessary.
* | tor-cell: Implement RelayMsg for all conflux message types.Gabriela Moldovan2025-03-171-1/+1
| |
* | tor-cell: Add setters for the V1LinkPayload seqnos.Gabriela Moldovan2025-03-131-0/+10
| |
* | tor-cell: Make V1_LINK_NONCE_LEN pub.Gabriela Moldovan2025-03-131-1/+1
| |
* | tor-cell: Add constructors for the conflux cell types.Gabriela Moldovan2025-03-131-0/+46
| | | | | | | | We will soon need these in the circuit reactor.
* | tor-cell: Add type alias for the V1LinkPayload nonce.Gabriela Moldovan2025-03-131-1/+4
|/
* tor-cell: Add encodable conflux relay message types.Gabriela Moldovan2025-02-182-0/+214
| | | | | | | This adds support for encoding and decoding `RELAY_CONFLUX_LINK`, `RELAY_CONFLUX_LINKED`, and `RELAY_CONFLUX_SWITCH` cells. Closes #1852
* 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 08:17:41 +0000