| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes #222; see arti#1031
|
|
(Also note that the current design is a little ugly)
|
|
State rounding convention for shared random disaster minutes
See merge request tpo/core/torspec!108
|
|
Document an onionbalance (?) behavior wrt missing newlines.
See merge request tpo/core/torspec!152
|
|
C Tor tolerates this; Arti didn't (until arti!1389).
Also see !109, where we noted a different occurrence of this
problem.
|
|
|
|
This adds a paragraph describing the checks hidden service directories
are supposed to perform before accepting a descriptor upload.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
|
|
rend-spec: document MAC_KEY_LEN=32.
See merge request tpo/core/torspec!141
|
|
rend-spec: Clarify that "exactly the same contents" means "exactly".
Closes #189
See merge request tpo/core/torspec!120
|
|
We use this constant in various places throughout the document
but we never say what it is.
|
|
These layers use SHA3 instead of SHA1 and AES256 instead of AES128.
Their SENDME tags are made with SHA3 too, but they are truncated to
20 bytes.
Closes #204.
|
|
These were generated using a patched Tor with extra logging info.
I've used them to validate (and find bugs in) the arti hs-ntor
implementation. (See arti!1189.)
|
|
Specifically, you can look at the directory to see if somebody is
lying about a relay (mismatched IDs, etc), but you can't modify
the list of linkspecs.
|
|
We can make these non-mandatory in the future if we want, using a
consensus flag.
|
|
This resolved "problem 2" from torspec#193.
|
|
We were previously a bit unclear on how to handle multiple linkspecs
of type ed25519, and our spec didn't actually permit Tor's current
behavior.
Now we say that both Ed25519 ID and Legacy ID linkspecs MUST appear
at most once in a list of linkspecs, and that parties SHOULD
enforce this.
This is "problem 1" on torspec#193.
|
|
When an INTRODUCE1 cell is retransmitted as an INTRODUCE2 cell, the
contents are bytewise identical.
Closes #189.
|
|
|
|
Really, AUTH_KEY in the display ought to be KP_IPT_SID, to get rid of
a layer of terminological indirection.
|
|
The previous wording implied that SIG_LEN was also signed, which
it isn't.
|
|
|
|
|
|
|
|
|
|
|
|
These new names are the ones used in arti's hsdir_ring.rs and make a
lot more sense than calling one of them the "directory" index and
the other just the "index".
In C Tor these are calculated by functions called
hs_build_hs_index
hs_build_hsdir_index
That might be a reason *not* to accept this change. Or it might be a
reason to change the C Tor code.
If we don't change the names in the spec the Arti function names
should change.
|
|
It was never implemented, is not specified, and neither dgoulet nor
I can quite remember how it was supposed to work.
|
|
By our current logic, it needs to have `hs` in it.
|
|
It has no independent existence outside of the encryption algorithm
of 2.5.3.
|
|
|
|
These names are slightly shorter and a bit more descriptive IMO, and
now (when they are still fresh) is the best time to rename these
keys.
`hs_intro_tid` becomes `hs_ipt_sid`: It is a _session identifier_
key used with an _introduction point_. Using `ipt` here emphasizes
that it is not part of the introduction _handshake_.
`hs_intro_ntor` becomes `hss_ntor`. The extra "s" means it is owned
by the service. Renaming "intro" here removes the implication that
it is held by or used by the introduction point.
`onion_ntor` becomes `ntor`: There is no such thing as an ntor key
that is not an onion key.
|
|
Fix terminology for handshake type
See merge request tpo/core/torspec!112
|
|
|
|
Use the phrase which is used elsehwer, and enumerate them again since
this is where one would expect to find that enumeration.
|
|
We're not the code, we're the spec. We can define things, not
recognise them.
|
|
|
|
The phrase "format number" is not defined anywhere. I think it means
an HTYPE value.
|
|
|
|
Proposed by @nickm in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/999/diffs#50f9790ab3f0a65f7ac3e4f413c84f51fae1f855_0_26
(I think the spec is not 100% clear that hs_y and hs_Y are *this* key,
rather than some other possible ephemeral keypair the HS might have,
so please would the reviewer check that this is actually true.)
|
|
(See text for more info!)
|
|
The spec says "exactly once", but that only refers to the ntor
variant.
|
|
|
|
It looks like C tor doesn't include a final newline in the middle
layer of its onion service descriptors. That made arti reject them
the first time I tried to parse one! Here I document this behavior,
and tell other implementations what to do.
|
|
|
|
Based on this email thread with dgoulet:
https://lists.torproject.org/pipermail/tor-dev/2023-January/014808.html
|
|
As per review comments
|
|
|
|
|
|
This reverts commit 81c1be641557d1cd3fb6d9195de08e9f411be517.
|
