| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The term “X509 certificate” actually only describes one part of the
format. Be more explicit to mean DER encoded certificates (in contrast to
PEM encoded certifcates).
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
Closes #16227
|
| | |
| |
| |
| |
| |
| | |
This version matches the implementation submitted for review.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following changes were made:
* Randomize second and third guard layers.
* Fold in my comments about using disjoint sets ("buckets") for the
third level guard.
* Make the paremeter discussion subsection its own section, and include tables
with far more detail for the Sybil success rates.
* Changed the default parameters based on these tables, and based on my own
intuition about Tor's performance properties.
* Move the load balancing, torrc, and other performance considerations to
their own section (Section 5).
* Move "3.2. Distinguishing new HS circuits from normal HS circuits" to
section 4.1.
* Fold in some of "3.3. Circuit nodes can now be linked to specific hidden
services" into 4.1. Some of it I just removed, though, because I did not find
it credible.
* Added Roger's concerns about guard linkability to Section 4.2.
* Added a denial of service subsection to Section 4.3.
* Try to make a coherent threat model and specify its assumptions
* Put the rotation period in a separate subsection from the number of guards
* Switch to using min(X,X) and max(X,X) for the distribution for the
second and third layer guard lifespans, respectively. Add a subsection
describing this distribution (3.2.3)
* Include python functions for the min and max probability distributions.
* Mention that third nodes can probe to see if they are one of the current
RPs.
* Provide CDF for rotation functions for Sybil runtime expecations.
* Add s7r's DoS points.
* Add notes from Thursday dev meeting discussion.
* Address Aaron's mailinglist comments (except for the CDF).
* Add discussion items from the dev meeting.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Each replicas uses one of multiple blinded keys (and a different
descriptor signing key) to avoid HSDirs being able to locate other
replicas of the service.
In combination with the changes to the salt and revision-counter,
this also makes it difficult to link descriptors from the same
service at all.
If descriptors for different replicas cannot be linked, then it
becomes much harder for a malicious HSDir to discover other
replicas and attept to DoS them.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use a different salt for each descriptor replica and upload,
to avoid matching encrypted blobs, which could be used to
link other replicas of the service.
If descriptors for different replicas cannot be linked, then it
becomes much harder for a malicious HSDir to discover other
replicas and attept to DoS them.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Randomise revision-counter start value and increment to avoid
leaking:
* the descriptor validity start time,
* the age of new hidden services,
* the stability of a hidden service,
* a value that could be used to link other replicas of the service.
If descriptors for different replicas cannot be linked, then it
becomes much harder for a malicious HSDir to discover other
replicas and attept to DoS them.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If multiple replicas want to use the same HSDir, give it to the
lower-numbered replica, and have the higher-numbered replica(s)
ignore it when counting nodes.
This avoids services choosing the same HSDir for multiple
replicas / spreads, and therefore losing redundancy.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Exposing raw random bytes from a PRNG has broken Dual EC:
http://projectbullrun.org/dual-ec/ext-rand.html
Based on ioerror's feedback on prop250, make similar changes:
https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some hashes were missing distinguishing values, even though other
hashes had them, and the "Cryptographic building blocks" section
appears to require them:
"all signatures are generated not over strings themselves, but over
those strings prefixed with a distinguishing value"
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
An updated and expanded version of "Direct Onion Services:
Fast-but-not-hidden services”.
Also borrows heavily from "Single Onion Services" (Proposal #252).
|
| | |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
- Remove majority requirement for commitments.
- Remove conflict detection.
- Remove the need for SR keys.
- Don't use signatures in commits.
- Simplify persistent state logic.
- Change the protocol starting time from 12:00UTC to 00:00UTC.
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This attempts to make it clear that PTs are not just for Tor, and can
be used by any project, and should be sufficient documentation for
writing the PT glue code both for Tor and other projects.
TODO: Fold in the implemented parts of prop 196/217. I'll do this when
I have time, since statistics are useful for everybody.
Fixes: #13369, #15545
Completes: #16754
|
| |\ \ |
|
| |/ / |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ / |
|
