Tor Specifications issueshttps://gitlab.torproject.org/tpo/core/torspec/-/issues2024-02-08T21:08:57Zhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/216Write a "sendme windows cover everything" proposal2024-02-08T21:08:57ZNick MathewsonWrite a "sendme windows cover everything" proposalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/214Write a proposal about converging hs_ntor and ntor_v3.2023-09-19T12:36:00ZNick MathewsonWrite a proposal about converging hs_ntor and ntor_v3.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/202Formalize toggle override for non-Tor applications that follow RFC 76862023-12-20T17:52:29ZomniFormalize toggle override for non-Tor applications that follow RFC 7686Suggestion to formalize environment variable name `ALLOW_DOT_ONION` (or other) to be set to toggle and enable DNS lookup of the .onion TLD where an application otherwise would block such DNS lookup.
This would be useful in transparent p...Suggestion to formalize environment variable name `ALLOW_DOT_ONION` (or other) to be set to toggle and enable DNS lookup of the .onion TLD where an application otherwise would block such DNS lookup.
This would be useful in transparent proxy setups where you don't want to or cannot do SOCKS proxying.
[RFC 7686](https://www.rfc-editor.org/rfc/rfc7686) states that:
> Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup.
An example of a common application that refuse to resolve the .onion TLD is curl, since [0ae0abb](https://github.com/curl/curl/commit/0ae0abbe72514a75c10bfc4108d9f254f594c086) and even earlier, if built with `--enable-ares`, since [c-ares 955df98](https://github.com/c-ares/c-ares/commit/955df983d7f643d1b00aa433f31ca3ec7f86b4bd). Currently no override is available for curl or c-ares.
An example of an application that refuse to resolve the .onion TLD _by default_ is Firefox, where it is available as a toggle in `about:config` by setting the `network.dns.blockDotOnion` boolean to **false**.https://gitlab.torproject.org/tpo/core/torspec/-/issues/201Lack of INTRODUCE2_ACK2023-06-13T17:01:44ZIan Jacksoniwj@torproject.orgLack of INTRODUCE2_ACKSeen from the POV of an HS client trying to connect to a service:
When you send INTRODUCE1 the IP sends you INTRODUCE_ACK. It sends INTRODUCE2 on to the service. The service responds by connecting to your RP. But there is no INTRODUC...Seen from the POV of an HS client trying to connect to a service:
When you send INTRODUCE1 the IP sends you INTRODUCE_ACK. It sends INTRODUCE2 on to the service. The service responds by connecting to your RP. But there is no INTRODUC2_ACK that goes via the IP. So if you get INTRODUCE_ACK but nothing tickles the RP you don't know if it was the (paths to the) IP, or the (paths to the) RP, or the service, that's faulty.
This doesn't seem desirable. In particular, the client would like to know whether trying a different IP is likely to help.
Perhaps if the protocol had an INTRODUCE2_ACK that would enable some kind of attack? That would be a good reason for this omission. It ought to be written down somewhere, then.
(Such a message could be sent by the HS after receiving the INTRODUCE2, or after reaching or failing to reach the RP. These would have different implications for who would learn what.)
CC @dgoulethttps://gitlab.torproject.org/tpo/core/torspec/-/issues/192Inconsistent representation and specification of onion key types2023-03-08T16:10:50ZIan Jacksoniwj@torproject.orgInconsistent representation and specification of onion key typesOnion keys (the intermediate-lifetime circuit keys, eg `KP_ntor`) have a type; in the past, and perhaps in the future, there were multiple algorithms supported.
These types are represented, at least, in the following ways:
* An integer...Onion keys (the intermediate-lifetime circuit keys, eg `KP_ntor`) have a type; in the past, and perhaps in the future, there were multiple algorithms supported.
These types are represented, at least, in the following ways:
* An integer field `ONION_KEY_TYPE` in an INTRODUCE1/2 message (rend-spec-v3 \[PROCESS_INTRO2]
* A string value in a hidden service descriptor inner document (rend-spec-v3 2.5.2.2 `onion-key` keyword)
* The difference between the `onion-key` and `ntor-onion-key` keywords in a router descriptor (tor-spec 2.1.1)
These things should be cross-referenced. There should be one table of key types, with consistent naming both for the types themselves, and for the enum of types of which the individual types are variants.
Also the router descriptor format is needlessly different, and worse, and should probably be fixed if we were to get the chance to overhaul it.https://gitlab.torproject.org/tpo/core/torspec/-/issues/188HS dir hashing is illogical2023-02-08T18:22:35ZIan Jacksoniwj@torproject.orgHS dir hashing is illogicalAmongst the strangenesses:
* `replicanum` is defined to be a value in the range 1..16 but is hashed as a 64-bit integer.
* `period_length` is represented in minutes; there is no reason not to use seconds
* `period_num` and `period_len...Amongst the strangenesses:
* `replicanum` is defined to be a value in the range 1..16 but is hashed as a 64-bit integer.
* `period_length` is represented in minutes; there is no reason not to use seconds
* `period_num` and `period_length` are in opposite orders in the two hashes (!)
Improving this would be an incompatible change.https://gitlab.torproject.org/tpo/core/torspec/-/issues/187netdoc keywords should be the names of the items (eg keys)2023-02-07T10:51:37ZIan Jacksoniwj@torproject.orgnetdoc keywords should be the names of the items (eg keys)The keywords found in netdoc documents are, in a very real sense, names for the information they denote. They often end up in variable names, etc., and need to be referenced elsewhere.
There is no good reason for these keywords not to ...The keywords found in netdoc documents are, in a very real sense, names for the information they denote. They often end up in variable names, etc., and need to be referenced elsewhere.
There is no good reason for these keywords not to be *the actual names* for the things. (There is a sad reason, which is that they're this way already, and changing these keywords is a lot of work, with a tiresome transition.)
Two examples from rend-spec-v3:
1.
```
"enc-key" SP "ntor" SP key NL
[Exactly once per introduction point]
The key is a base64 encoded curve25519 public key used to encrypt
the introduction request to service. (`KP_hs_intro_ntor`)
```
Should be:
```
"KP_hs_intro" SP "ntor" SP key NL
```
2.
```
"create2-formats" SP formats NL
```
But these aren't formats, they are `HSTYPE`s as per !112. So this should be
```
"hstypes" SP hstypes NL
```
(If "hstypes" is a bad name for this thing, it should be changed everywhere, to one same name.)https://gitlab.torproject.org/tpo/core/torspec/-/issues/185prop342: Make SRV interval explicit too?2023-04-03T12:28:32ZNick Mathewsonprop342: Make SRV interval explicit too?See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/987#note_2872871:
Right now in prop342, we have a bunch of tacit knowledge embedded in the document that requires clients and services to make assumptions ab...See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/987#note_2872871:
Right now in prop342, we have a bunch of tacit knowledge embedded in the document that requires clients and services to make assumptions about SRV lifetimes. It may be cleaner to simply have the SRV lifetime interval be declared: either as a consensus parameter, or as part of the SRV line, or as a related line someplace. (That way the client would no longer have to know that one SRV lifetime is exactly 24 voting intervals, and we could change these frequencies in the future.)
My suggestion would be to have the SRV lifetime be a consensus parameter, and declare its default to be 24 voting periods. I would also change the time-period offset so that it was equal to 1/2 of the SRV lifetime. (This would always be the same under current implementations, and no C Tor client change would be needed as long as authorities behave as they do today.)
@dgoulet, what would you think of that?
cc @dizietNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/184INT_N notation is confusing2023-01-27T16:17:21ZIan Jacksoniwj@torproject.orgINT_N notation is confusingIn the virtual pub with a friend last night I asked "what do you think INT_8 means in the Tor protocol specifications?"
Even primed by context that the answer was not going to be the obvious one, my friend thought for a minute and then ...In the virtual pub with a friend last night I asked "what do you think INT_8 means in the Tor protocol specifications?"
Even primed by context that the answer was not going to be the obvious one, my friend thought for a minute and then said "no, I can't think of any other plausible meaning than an 8-bit integer of doubtful signedness".
When we wish to talk about an unsigned 64-bit integer, we should write `uint64` (adjust capitalisation to taste).
Also the definition of this notation (including the endianness convention) is in `rend-spec-v3` but it should probably be in some central place.https://gitlab.torproject.org/tpo/core/torspec/-/issues/183ISOTime inconsistent naming2023-01-27T16:17:29ZIan Jacksoniwj@torproject.orgISOTime inconsistent naming`control-spec.txt` defines:
* `ISOTime`: `2012-01-11 12:15:33`
* `ISOTime2`: `2012-01-11T12:15:33`
* `ISOTime2Frac`: `2012-01-11T12:15:33.51`
This is confusing because it is `ISOTime` which produces two arguments when used as a netdo...`control-spec.txt` defines:
* `ISOTime`: `2012-01-11 12:15:33`
* `ISOTime2`: `2012-01-11T12:15:33`
* `ISOTime2Frac`: `2012-01-11T12:15:33.51`
This is confusing because it is `ISOTime` which produces two arguments when used as a netdoc keyword parameter, not `ISOTime2`. Presumably we should be deprecating `ISOTime` for new protocol elements.
`proposals/342-decouple-hs-interval.md` refers to `IsoTimeNospace` which is not defined anywhere.
`proposals/239-consensus-hash-chaining.txt` refers to `ISOTIME`.
Most of the rest of the documents write out `YYYY-MM-DD SP HH:MM:SS` or `YYYY-MM-DDTHH:MM:SS` or whatever, ad hoc.
It is anomalous to have the specification of these elements in the control port protocol spec, when they're used.
I suggest:
* Rename `ISOTime2` to `ISOTimeNew`
* Rename `ISOTime` to `ISOTimeOld` or `ISOOldDateTimePair` or something
* Reference the correct name in prop 342.
* Change `ISOTIME` in prop 239 to `ISOTimeNew` (NB this may need to be checked against any implementation that may exist)
* Move the definitions to a central file of definitions.
* Replace `YYYY-MM-DD SP HH:MM:SS` and `YYYY-MM-DDTHH:MM:SS` with references to the new definition.https://gitlab.torproject.org/tpo/core/torspec/-/issues/182Inconsistent terminology wrt voting periods / intervals / times2023-01-27T16:18:48ZIan Jacksoniwj@torproject.orgInconsistent terminology wrt voting periods / intervals / timesI have been trying to make sense of the HS hash rings and time periods. I observe at least the following terms in use to talk about times in `dir-spec` and `rend-spec-v3`:
* "voting period"
* "Interval"
* "interval"
* "time period"
...I have been trying to make sense of the HS hash rings and time periods. I observe at least the following terms in use to talk about times in `dir-spec` and `rend-spec-v3`:
* "voting period"
* "Interval"
* "interval"
* "time period"
* "consensus time"
* "current"
* "measurement period"
* "period"
* "hsdir-interval"
* "time period length"
* "period length"
* "bridge-stats-*"
* "measurement interval"
* "publication time"
* "published"
Sometimes the same words mean different things, depending on context. Sometimes different words are used to refer to the same thing. Generally, when concepts defined elsewhere are used a vague reference is made in prose to another part of the protocol, rather than giving the section number and the precise term from the definition.
This is all extremely confusing. I think these things ought to be defined and referred to consistently. If a fixed phrase ("hsdir time period", say) is too long, it should have a consistent abbreviation ("hsdir TP" maybe). When a reference is made to something which is found in a netdir document, perhaps the document keyword or syntactic metavariable should be used consistently.
I don't yet understand all this well enough yet to even enumerate the time periods/intervals/instants in the protocol, let alone suggest names for them.https://gitlab.torproject.org/tpo/core/torspec/-/issues/175See if we can have 512-byte cells again2023-04-13T19:07:03ZNick MathewsonSee if we can have 512-byte cells againConcurrently with proposal 340, it could be nice to reduce cell length to 512 bytes again. (It increased to 514 bytes when we added support for 32-bit circuit IDs.) See discussions on #174 for a bit of motivation from @mikeperry and @d...Concurrently with proposal 340, it could be nice to reduce cell length to 512 bytes again. (It increased to 514 bytes when we added support for 32-bit circuit IDs.) See discussions on #174 for a bit of motivation from @mikeperry and @dgoulet.
This is a nontrivial change, however. Unlike with proposal 340, we can't make this change only apply at the client and the exit: it needs support from the intermediate relays on the circuit as well.
To get 512-byte cells, we need to answer a few questions:
* What does relay crypto look like with this change? Where do we negotiate the cell length with the intermediate hops? Do we have to negotiate the same cell length with every hop, or can we somehow support mixed-cell-length circuits[^1]? If we need the same cell length with every hop, how do we handle the migration period?
* What does the channel protocol look like with this change? Assuming that the same channels need to hold 514-byte cells and 512-byte cells, do we need an extra byte per cell to tell which kind is which? And how do we eventually throw out that byte?
The very easiest way to build this change would probably be as follows:
* Channels use the high bit of the channel command to distinguish cell length (for now).
* Circuits must be all-512-byte or all-514-byte. The format is determined by an ntor3 parameter.
* We use a consensus parameter to tell clients that it is okay to start using 512-byte circuits. We do this once at least 85% of the relays on the network support all-512-byte circuits. (This change is necessary, or else these circuits will be so rare that they will be easy to trace)
* Once 100% of the relays are upgraded, we tell clients to stop using the 514-byte protocol.
* Once 100% of the relays are upgraded, we use a new channel protocol to un-reserve the high bit of the channel command.
I can _probably_ design something like this, but the clunky migration suggests that maybe we should do it at another time when we have a change that would plausibly need whole-circuit support. Maybe this would be good to bundle with an enhanced relay crypto? (We don't strictly need whole-circuit support for that, but it would make the analysis simpler at the expense of making security benefits slower to roll out.)
Since this is a trickier rollout than the other cell changes, I would also like to ask: How confident are we that this change will give real benefits? What amount of performance improvement would we expect here?
[^1]: I think that generalized mixed-cell-length circuits are _probably_ too hard to do safely, but I'm open to ideas. My first few designs were vulnerable to interesting padding attacks.
cc @dgoulet @mikeperryhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/165Clock jump heuristics might fail to cope with "suspend"2022-07-18T17:53:10ZIan Jacksoniwj@torproject.orgClock jump heuristics might fail to cope with "suspend"In `proposals/324-rtt-congestion-control.txt`:
> If the new RTT is either 5000 times larger than the EWMA
If the Tor client is suspended (for example, because a laptop is suspended), it might experience long RTT estimates, if the monot...In `proposals/324-rtt-congestion-control.txt`:
> If the new RTT is either 5000 times larger than the EWMA
If the Tor client is suspended (for example, because a laptop is suspended), it might experience long RTT estimates, if the monotonic timer advances during suspend (which some will do). Supposing an RTT of 1s, many plausible suspension durations might be much shorter than the 5000 figure. I think the result would be an RTT estimate that would be badly skewed, upwards.
AFAICT from the rest of the congestion control docs, this would result in sending too much data.
I feel I may well be missing something so please forgive me if I have the wrong end of the stick(s).https://gitlab.torproject.org/tpo/core/torspec/-/issues/120netflow channel padding keepalive maximum2023-06-26T10:05:59ZIan Jacksoniwj@torproject.orgnetflow channel padding keepalive maximumIn https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813638 @nickm points out that C Tor imposes a maximum value of 60s for the channel padding timeout parameters (`nf_ito_*`)
This (or some other sensible value) oug...In https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813638 @nickm points out that C Tor imposes a maximum value of 60s for the channel padding timeout parameters (`nf_ito_*`)
This (or some other sensible value) ought to be in the spec.https://gitlab.torproject.org/tpo/core/torspec/-/issues/114Incorrect introduction point auth key location2022-05-23T20:30:11ZAAraniafshin@arani.devIncorrect introduction point auth key locationQuoting from rend-spec-v3:
> "auth-key" NL certificate NL
> [Exactly once per introduction point]
> The certificate is a proposal 220 certificate wrapped in "-----BEGIN
> ED25519 CERT-----" cross-certi...Quoting from rend-spec-v3:
> "auth-key" NL certificate NL
> [Exactly once per introduction point]
> The certificate is a proposal 220 certificate wrapped in "-----BEGIN
> ED25519 CERT-----" cross-certifying the introduction point
> authentication key using the descriptor signing key. The introduction
> point authentication key is included in the mandatory signing-key
> extension. The certificate type must be [09].
This is wrong because the introduction point authentication key is actually located in the CERTIFIED_KEY portion of the certificate and not in the extension.https://gitlab.torproject.org/tpo/core/torspec/-/issues/80Y2038 problem in NETINFO cell2023-11-28T18:47:44ZNick MathewsonY2038 problem in NETINFO cellThe NETINFO cell includes a 4 byte timestamp counted in seconds; we should fix that to be an 8 byte timestamp before it is too late.
The easy way to do this would be to add a new link handshake version, and change the NETINFO cell in th...The NETINFO cell includes a 4 byte timestamp counted in seconds; we should fix that to be an 8 byte timestamp before it is too late.
The easy way to do this would be to add a new link handshake version, and change the NETINFO cell in that version to have an 8 byte timestamp. (But if we do this, Arti won't benefit from it until it also implements the connection padding required in link protocol 5 and later: arti#62)
The harder kludgier way to do that would be to optionally insert the high bytes of the timestamp cell at the end of the end of the NETINFO cell, after the MYADDR stuff.
A bad kludge (IMO) would to specify that parties should interpret the timestamp as having whatever high bytes would make it closest to their current time.
Implementation breakdown, if prop338 is accepted
* In tor:
* [ ] Add version 6 to accepted versions list
* [ ] Add support for netinfo cell with 8 byte time.
* [ ] Change format of netinfo cell depending on protocol version
* [ ] Unit tests for all of the above
* [ ] Integration testing with old/new clients, old/new relays
* In arti:
* [ ] Add version 6 to accepted versions list (dup)
* [ ] Add support for netinfo cell with 8 byte time. (dup)
* [ ] Change format of netinfo cell depending on protocol version (dup)
* [ ] Unit tests for all of the above (dup)
* [ ] Integration testing with old/new clients, old/new relays (dup)
* [ ] Add support for parsing channel cells differently depending on link protocol versionNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/79proposal for new AEAD+SPRP relay cell protocol2022-05-23T23:28:51Zdynproposal for new AEAD+SPRP relay cell protocolCf. prop202; see also https://lists.torproject.org/pipermail/tor-dev/2012-March/003347.html
Advertised as a new Relay subprotocol and negotiated with a new HTYPE, in this new dual-cipher scheme, the relay cell is initially encrypted wit...Cf. prop202; see also https://lists.torproject.org/pipermail/tor-dev/2012-March/003347.html
Advertised as a new Relay subprotocol and negotiated with a new HTYPE, in this new dual-cipher scheme, the relay cell is initially encrypted with an AEAD cipher for its final destination, then the outer layers of encryption use a length-preserving SPRP.
A single circuit may include a mix of this new relay cell crypto scheme for some hops, and the legacy AES-CTR cipher for other hops.
In the forward direction, when receiving a relay cell an OR performs trial decryption with the AEAD cipher. Successful decryption proves the cell was destined for the OR; on a failure, the OR decrypts it with the SPRP cipher and forwards it along the circuit, or tears down the circuit if the OR is the last hop.
In the backward direction, when receiving a relay cell, for each hop in the circuit (assuming all hops support the new crypto), the OP attempts decryption with that hop's AEAD key, and on a failure, decrypts it instead with that hop's SPRP key and repeats the trial decryption process with the next hop's keys. If the last hop's AEAD key fails to decrypt the relay cell, the OP tears down the circuit.
## Relay cell payload
Using an AEAD cipher means allocating part of the 509 bytes of the relay cell's encrypted payload to a 16-byte authentication tag. However, 8 bytes of overhead can also be ripped out from the current payload: the Recognized field, the Digest field, and even the Length field can all go away.
Similar to how TLS 1.3 uses the ContentType byte to mark where the record-layer padding ends and the data begins, a relay cell can use the Relay command as a nonzero byte to separate padding from data, eliminating the need for an explicit length field:
Zeros [PLAINTEXT_PAYLOAD_LEN - 3 - len(Data) bytes]
Relay command [1 byte]
StreamID [2 bytes]
Data [PLAINTEXT_PAYLOAD_LEN - 3 - len(Zeros) bytes]
For this relay cell layout, PLAINTEXT_PAYLOAD_LEN is 493 bytes long, which wrapped in an AEAD cipher becomes 509 bytes of ciphertext. The maximum amount of useful data per cell is 490 bytes, 8 less than the current 498 bytes maximum.
## AEAD cipher choice: AEAD_CHACHA20_POLY1305
Standardized in RFC 8439, widely deployed in TLS ciphersuites, it's fast and has constant-time software implementations without any specialized CPU instructions or hardware support. ChaCha20-Poly1305 is faster than AES-GCM on platforms that lack specialized AES instructions (like many smartphones do), and slower than AES-GCM on platforms that do have those instructions.
Benchmarks from 2014 https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html show about a 3x speed advantage on the sampled mobile chipsets, while it's half the speed of AES on an Intel chip with AESNI.
## SPRP cipher choice: HBSH construction (Adiantum or HPolyC)
https://eprint.iacr.org/2018/720
HPolyC is HBSH mode instantiated with two invocations of [Poly1305](https://docs.rs/poly1305/latest/poly1305/), one of [XChaCha12](https://docs.rs/chacha20/0.9.0/chacha20/type.XChaCha12.html), and a single AES block encryption/decryption of the last 16 bytes.
HPolyC is almost identical to but simpler than Adiantum, which is implemented in the Linux kernel and is widely deployed for disk encryption on smartphones launched with Android 10 or later. Using a SPRP construction that has more than just a single niche user seems like a plus.
Benchmarks on a Raspberry Pi (which lacks specialized AES instructions) in https://github.com/raspberrypi/linux/issues/3648 show speeds of `256.6 MiB/s` for adiantum and `71.0 MiB/s` for aes-xts.
## Bonus stuff
While updating the Relay crypto scheme, maybe we also want a new KeyUpdate relay message, like they have in TLS 1.3?https://gitlab.torproject.org/tpo/core/torspec/-/issues/78proposal for a new hash in authenticated SENDMEs2022-05-23T20:30:09Zdynproposal for a new hash in authenticated SENDMEsVersion 1 SENDME cells' reuse of the SHA-1 rolling hash calculated for the 'Digest' field in RELAY cells creates an interdependency between the definitions of RELAY cells and SENDME cells, which makes it more difficult to eventually migr...Version 1 SENDME cells' reuse of the SHA-1 rolling hash calculated for the 'Digest' field in RELAY cells creates an interdependency between the definitions of RELAY cells and SENDME cells, which makes it more difficult to eventually migrate away from the Relay protocol's current bespoke MAC-then-encrypt construction in the future.
A new SENDME cell version could have an independent, self-contained definition like:
* "When constructing a SENDME cell to send to an OR, the DIGEST must contain a *[pick an algorithm]* hash over the unencrypted payloads of all RELAY_DATA cells received from the OR since the previous SENDME was triggered, or, if this is the first SENDME, of all RELAY_DATA cells received from the OR so far. In other words, every RELAY_DATA cell is included in exactly one SENDME cell's hash."
The new hash should be one that's much faster to calculate than SHA-1.
## Candidate: BLAKE2
BLAKE2 is the fast, standard [generic hash](https://libsodium.gitbook.io/doc/hashing/generic_hashing) used by libsodium and defined in RFC 7693.
OpenSSL [added](https://github.com/openssl/openssl/pull/566) `EVP_blake2b512()` in 1.1.0, released in 2016.
NSS technically added an implementation in 2017, but [exposing BLAKE2 in the public api](https://bugzilla.mozilla.org/show_bug.cgi?id=1397282) was blocked until it was standardized as a mechanism in PKCS \#11. It's since been standardized as `CKM_BLAKE2B_512` [in v3.0](https://bugzilla.mozilla.org/show_bug.cgi?id=1603628).
## Candidate: BLAKE3
BLAKE3 is faster than BLAKE2, partly because it uses only 7 rounds instead of 10. It's also much, much newer and is not as widely implemented.
## Candidate: Poly1305
Poly1305 is a MAC rather than a hash, and is fast, but technically it doesn't seem to be designed for collision resistance. It was [added](https://github.com/openssl/openssl/issues/304) to OpenSSL in 1.1.0.https://gitlab.torproject.org/tpo/core/torspec/-/issues/77Leakiness of hidden service presence due to startup circuits2022-02-21T19:12:26ZIan Jacksoniwj@torproject.orgLeakiness of hidden service presence due to startup circuitsIn `path-spec.txt` we have:
> Specifically, on startup Tor tries to maintain one clean fast exit circuit that allows connections to port 80, and at least two fast clean stable internal circuits in case we get a resolve request or hidden...In `path-spec.txt` we have:
> Specifically, on startup Tor tries to maintain one clean fast exit circuit that allows connections to port 80, and at least two fast clean stable internal circuits in case we get a resolve request or hidden service request (at least three if we _run_ a hidden service).
Doesn't this mean our guard can see if we run a hidden service? But is that true anyway? Do we care? (Is this in fact true of the C implementation? What should we do in Arti?)
@nickm says the guard will probably be able to figure out if we are running an onion service anyway, based on timing and suggested @mikeperry would have good insight on this issue.https://gitlab.torproject.org/tpo/core/torspec/-/issues/76stream close reasons should distinguish DNS failure from nonexistent host2022-02-21T19:12:26ZIan Jacksoniwj@torproject.orgstream close reasons should distinguish DNS failure from nonexistent hostWhen we next revamp the spec, we should arrange that the `RELAY_END` reason bytes (spec 6.3) distinguish the two fundamentally different kinds of DNS failure.
Currently, `REASON_RESOLVEFAILED` seems to do double duty for all of:
1. The...When we next revamp the spec, we should arrange that the `RELAY_END` reason bytes (spec 6.3) distinguish the two fundamentally different kinds of DNS failure.
Currently, `REASON_RESOLVEFAILED` seems to do double duty for all of:
1. The DNS worked properly and told us that the host definitely doesn't exist (`NXDOMAIN`) or that this isn't a hostname we can use (`NODATA` pseudo-rcode)
2. The DNS isn't working properly and we weren't able to find out about this host.
3. The question we asked the DNS server was invalid (eg, wrong hostname syntax, name too long, etc.)
I don't think we absolutely need to distinguish 3; it can be lumped in with 1, and it shoudl be rare. But we should distinguish 1 from 2. They correspond, from (say) a Tor Browser user's pov, "this website cannot be reached due to some network or computer not working right" and "you have a wrong (or out of date) URL".