| Commit message (Collapse) | Author | Age |
| ... | |
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
* THANKS TO Mr. George Costanza for pointing out the ambiguity.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The original was incorrect to say
"You may do A if B, C otherwise."
but it seems less clear to say
"You MUST do A if B, C otherwise."
than it is to say
"If A, you MUST B. If not A, you MUST C."
Closes ticket 22951
|
| | |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is only used in TAP and old-style hidden services, and it's
half malleable. I've clarified how the code behaves by adding the
change suggested in #22987. I've also noted:
I've also noted that we don't actually reach case 1 with any usage
of this algorithm.
I've also replaced Roger's note that someday we'll add a MAC with
an admonition not to use this hybrid encryption approach for
anything new. We're not planning to add a MAC; we've migrated to
ntor instead.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Fixes bug 22862; based on patch from Teor.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Section 3.3.2 is showing the layout of an INTRODUCE1 cell but was missing a
field that we need to do the MAC computation.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes #22993
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This clause was added in...
https://gitweb.torproject.org/torspec.git/commit/?id=5c82d5e
Commit message and ticket make no mention of 'GETINFO sr/current' go I suspect
Daniel meant for this to concern his addition. However, if that's the case then
according to the ticket it should be 0.3.1.1-alpha.
Just gonna drop this clause since it's probably wrong.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fields used 'NUM', 'num', 'N', and in one case had a 'nul' typo. I'm not
entirely clear what formally indicates 'non-negative integer' but at least
we can standardize this.
Back in May I reached out to Mike to confirm padding-counts are and will
always be integers, so specifying that.
|
| | | |
| | |
| | |
| | | |
Closes ticket 22742.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
Specifies ticket 22684.
|
| |/ / / |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We don't need KH anymore since we do a MAC check anyway.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Also simplify that part of the spec sincedgoulet felt it was too obscure
and people might miss it or consider it a side note.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
See review point:
https://gitlab.com/dgoulet/tor/merge_requests/27#note_27696937
|
| |/ / / |
|
| |\ \ \ |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
we stopped requiring it sometime between 2003 and now, and also we
stopped adding it sometime between 2003 and now. closes ticket 6879.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
See https://lists.torproject.org/pipermail/tor-dev/2017-May/012263.html .
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
i don't think i broke anything, but it would be worth somebody
looking over it to be sure.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
please do feel free to look through and make sure i didn't break anything
though :)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
the only exciting one is that we don't use guards to defend against
"enumeration attacks" -- i'm not quite sure what an enumeration attack
is, but it sounds like something where the guard is able to make a list
of users, and where having that list is bad news in itself. that's not
quite what guards are for.
|
| | | | | |
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | | |
Mike informs me that prop151 got merged into path-spec and 161 got
split into dir-spec and a spec file in the bwauth code.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
According to Karsten, 121 has long been merged into rend-spec.txt,
and 155 is implementation-specific stuff that doesn't affect the
protocol itself.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|