| Age | Commit message (Collapse) | Author |
|---|
|
param-spec: Document the vanguard params.
See merge request tpo/core/torspec!258
|
|
Slight clarifications about hsv3 relay crypto
See merge request tpo/core/torspec!261
|
|
cert-spec: Put backticks around SIGNATURE
See merge request tpo/core/torspec!263
|
|
See !259
|
|
Rename "text vectors" to "test vectors" for correctness.
See merge request tpo/core/torspec!260
|
|
There was a missing link at one point, and another point where we
should have said what cryptography we were using.
|
|
|
|
Prompted by https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/258#note_3011734
|
|
|
|
This documents the 3 [vanguard-related parameters] currently supported
by C Tor.
Note: Arti will support full vanguards too, so we may want to also add
parameters for configuring the third layer of guards.
[vanguard-related parameters]: https://gitlab.torproject.org/tpo/core/tor/-/blob/2d19050ef9f2612aab826fe2973dd9fab1df8438/src/feature/client/entrynodes.c#L4126-4159
|
|
Clarifications about INTRODUCE1/2 extensions
See merge request tpo/core/torspec!255
|
|
|
|
|
|
|
|
I got the answer to this question from
proposals/324-rtt-congestion-control.txt
(This thing should have a proper identifier, not merely a descriptive
phrase, but that may be controversial.)
|
|
This sentence seems stray in this section. The information is alreayd
present with the wording
The same rules for multiplicity, ordering, and handling unknown types
apply to the extension fields here as described \[EST_INTRO\] above.
which appears earlier, for each of the two sections.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The text uses "scheme" and "version" a couple of times. The formal
protocol says "type". The terminology should be consistent. IMO
"scheme" is the best word to use. "version" is particularly bad.
Change all references to "type" and "version" to "scheme".
|
|
There were two different versions of this description in the doc, and
they were both wrong in different ways. One was newer and implied the
extension was encoded outside the encrypted section (it's inside). The
other was older and had some outdated references and recommendations
from when this was still a proposal, but it was in the correct location.
I consolidated the two and made the correct location of the extension
explicit.
|
|
Replace "payload" with "body"
See merge request tpo/core/torspec!248
|
|
Clarify rend-point behavior with relay cells
Closes #254
See merge request tpo/core/torspec!250
|
|
|
|
Previously, we didn't actually say that relay cells got
retransmitted; we only said that the circuits were "joined".
Closes #254 by clarifying that RELAY_EARLY cells are retransmitted
as RELAY cells.
|
|
|
|
|
|
|
|
|
|
This will get us some horizontal space.
|
|
Formerly it didn't have conflux, HS, or padding commands.
|
|
We had used these terms inconsistently; "payload" was far less
common.
Part of #253.
|
|
|
|
document stream dos network params
See merge request tpo/core/torspec!173
|
|
There is no `pr` line (anymore) and `p` is only available at most once.
Closes: #255.
|
|
Done by grepping for "cell" and making sure it was accurate in every
place where it occurs. In tor-spec, I also searched for "message".
Part of #253.
|
|
Part of #253.
|
|
rend-spec: Note that the subject key in enc-key-cert always has sign=0.
See merge request tpo/core/torspec!240
|
|
Correct the start time for the OPE-based RC algorithm
Closes #250
See merge request tpo/core/torspec!241
|
|
Misc clarifications around CONNECTED and BEGIN behavior
See merge request tpo/core/torspec!237
|
|
We need to start counting from the beginning of the SRV
protocol run, not from the beginning of the time period:
Otherwise, we would have to encode negative numbers.
|
|
|
|
This behavior is incorrect from the POV of preserving the key as a
signing key, but it is what C Tor does. See
`setup_desc_intro_point`, which has:
```
ed25519_public_key_from_curve25519_public_key(&ed25519_pubkey,
&ip->enc_key_kp.pubkey,
0);
```
The "incorrectness" doesn't matter in practice: since we have
the subject and signing keys inverted in this certificate, we
never have to actually verify anything using this public key.
Found while investigating arti#1221.
|
|
I think "Locating, uploading, and downloading hidden service
descriptors" was supposed to be a section header rather than a text
block.
|
|
|
|
Otherwise e.g. `16903*1440*60` is rendered as `16903144060` (with 1440
italicized).
|
|
|
