[TWN team] Recent changes to the wiki pages
Lunar
lunar at torproject.org
Mon Dec 2 17:20:09 UTC 2013
===========================================================================
=== https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2013/22 ===
===========================================================================
version 29
Author: asn
Date: 2013-12-02T16:44:36+00:00
--
--- version 28
+++ version 29
@@ -53,11 +53,11 @@
The new proposal also introduces the possibility of keeping the master
identity key offline (section 1.7).
-The proposal is still unfinished when it comes to scaling Hidden Services
+The proposal is completely unfinished when it comes to scaling Hidden Services
to multiple hosts (section 1.5). There have been discussions on this topic,
but there is no final decision on what the final scheme should be.
The problem with naive scaling schemes is that information about the
-number of Hidden Service nodes might be leaked to adversarial clients
+number of Hidden Service nodes can get leaked to adversarial clients
or Introduction Points
(see [XXX] https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html)
version 28
Author: asn
Date: 2013-12-02T16:43:31+00:00
fix the #8244 paragarph a bit
--- version 27
+++ version 28
@@ -43,17 +43,12 @@
and SHA1 to prefer Ed25519, Curve25519, and SHA256 as the basic crypto
blocks (section 0.3).
-The set of hidden service descriptor directories used to publish a
-descriptor now depends on a “collaboratively generated random value”
-provided by the Tor directory authorities (see proposal 225 for the idea
-[XXX]).
-
-The selection of responsible directories for each hidden service now
-depends on a “collaboratively generated random value” provided by the
-Tor directory authorities so that the responsible directories are not predictable
-(see ticket #8244 [XXX] and proposal 225 for a possible scheme [XXX]).
-This will prevent targeted censorship in the form of denial of
-service attacks.
+The selection of responsible directories for a hidden service now
+depends on a periodic “collaboratively generated random value”
+provided by the Tor directory authorities. This way the directories
+of a hidden service are not predictable in advance which prevents
+targeted denial of service attacks (see ticket #8244 [XXX] and
+proposal 225 for a possible scheme [XXX]).
The new proposal also introduces the possibility of keeping the master
identity key offline (section 1.7).
version 27
Author: asn
Date: 2013-12-02T16:36:31+00:00
paragraph on hs scaling
--- version 26
+++ version 27
@@ -57,6 +57,14 @@
The new proposal also introduces the possibility of keeping the master
identity key offline (section 1.7).
+
+The proposal is still unfinished when it comes to scaling Hidden Services
+to multiple hosts (section 1.5). There have been discussions on this topic,
+but there is no final decision on what the final scheme should be.
+The problem with naive scaling schemes is that information about the
+number of Hidden Service nodes might be leaked to adversarial clients
+or Introduction Points
+(see [XXX] https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html)
In order to move the proposal forward from the current draft, Nick
Mathewson told the readers: “I'd like to know what doesn't make sense,
version 26
Author: lunar
Date: 2013-12-02T16:34:36+00:00
fix misunderstandings with the help of nickm and asn
--- version 25
+++ version 26
@@ -28,10 +28,13 @@
The proposal aims to replace “the current rend-spec.txt [XXX], rewritten
for clarity and for improved design.” The most user visible change
-from the current hidden services is the new address format. The current
-proposal uses a base 32 encoding of the entire 256 bits of the long term
-Ed25519 master identity key (section 1.2). Thus “a new name following
-this specification might look like:
+from the current hidden services is the new address format. In order
+to prevent the enumeration of hidden services, the new protocol uses
+a derives “blinded key” (section 1.3) from Ed25519 master identity
+key. The blinding operation requires to operate on the full key material
+(and not just a truncated hash, as before). With a base 32 encoding of the
+entire 256 bits (section 1.2), “a new name following this specification
+might look like:
a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion”. Other
encoding might still worth consideration as long as they make valid
hostnames.
@@ -40,30 +43,35 @@
and SHA1 to prefer Ed25519, Curve25519, and SHA256 as the basic crypto
blocks (section 0.3).
+The set of hidden service descriptor directories used to publish a
+descriptor now depends on a “collaboratively generated random value”
+provided by the Tor directory authorities (see proposal 225 for the idea
+[XXX]).
+
The selection of responsible directories for each hidden service now
depends on a “collaboratively generated random value” provided by the
-Tor directory authorities so that the responsible directories are not predictable
-(see ticket #8244 and proposal 225 for a possible scheme [XXX]).
-
-Furthermore, a new “blinded signing key” scheme (section 1.3), prevents the
-responsible directory servers of each hidden service from learning its
-onion address and reading its descriptor.
+Tor directory authorities so that the responsible directories are not predictable
+(see ticket #8244 [XXX] and proposal 225 for a possible scheme [XXX]).
+This will prevent targeted censorship in the form of denial of
+service attacks.
The new proposal also introduces the possibility of keeping the master
identity key offline (section 1.7).
-In order to move the proposal forward, Nick Mathewson told the readers:
-“I'd like to know what doesn't make sense, what I need to explain
-better, and what I need to design better. I'd like to fill in the gaps
+In order to move the proposal forward from the current draft, Nick
+Mathewson told the readers: “I'd like to know what doesn't make sense,
+what I need to explain better, and what I need to design better.
+I'd like to fill in the gaps
and turn this into a more full document. I'd like to answer the open
questions. Comments are most welcome, especially if they grow into
-improvements.” The proposal is still sprinkled with TODO items, so feel
-free to jump in!
+improvements.” The document is still sprinkled with many TODO items,
+so feel free to jump in if you want to help!
[XXX] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/001-process.txt
[XXX] https://lists.torproject.org/pipermail/tor-dev/2013-November/005877.html
[XXX] https://blog.torproject.org/category/tags/tor-weekly-news
[XXX] https://gitweb.torproject.org/torspec.git/blob/refs/heads/master:/rend-spec.txt
+ [XXX] https://bugs.torproject.org/8244
[XXX] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/225-strawman-shared-rand.txt
Tor relay operators meeting at 30C3
version 25
Author: asn
Date: 2013-12-02T16:26:16+00:00
change some minor technical details
--- version 24
+++ version 25
@@ -40,11 +40,14 @@
and SHA1 to prefer Ed25519, Curve25519, and SHA256 as the basic crypto
blocks (section 0.3).
-The set of hidden service descriptor directories used to publish a
-descriptor now depends on a “collaboratively generated random value”
-provided by the Tor directory authorities (see proposal 225 for the idea
-[XXX]). Together with the new “blinded signing key” (section 1.3), this
-should prevent future enumeration of hidden services.
+The selection of responsible directories for each hidden service now
+depends on a “collaboratively generated random value” provided by the
+Tor directory authorities so that the responsible directories are not predictable
+(see ticket #8244 and proposal 225 for a possible scheme [XXX]).
+
+Furthermore, a new “blinded signing key” scheme (section 1.3), prevents the
+responsible directory servers of each hidden service from learning its
+onion address and reading its descriptor.
The new proposal also introduces the possibility of keeping the master
identity key offline (section 1.7).
version 24
Author: lunar
Date: 2013-12-02T16:20:53+00:00
fixups
--- version 23
+++ version 24
@@ -14,7 +14,6 @@
Next-Generation Hidden Services reached draft proposal state
------------------------------------------------------------
-
Nick Mathewson has been working on turning a “revamp of the hidden
services protocol” into a formal proposal [XXX]. Last Saturday, Nick
@@ -50,7 +49,7 @@
The new proposal also introduces the possibility of keeping the master
identity key offline (section 1.7).
-In order to move the proposal forward, Nick Mathewson tell the readers:
+In order to move the proposal forward, Nick Mathewson told the readers:
“I'd like to know what doesn't make sense, what I need to explain
better, and what I need to design better. I'd like to fill in the gaps
and turn this into a more full document. I'd like to answer the open
version 23
Author: lunar
Date: 2013-12-02T16:19:50+00:00
write about proposal 224 (and 225 incidently)
--- version 22
+++ version 23
@@ -15,7 +15,54 @@
Next-Generation Hidden Services reached draft proposal state
------------------------------------------------------------
-XXX: placeholder (Draft) Proposal 224: Next-Generation Hidden Services in Tor https://lists.torproject.org/pipermail/tor-dev/2013-November/005877.html
+
+Nick Mathewson has been working on turning a “revamp of the hidden
+services protocol” into a formal proposal [XXX]. Last Saturday, Nick
+blessed the tor-dev mailing list with a post of the current draft for
+proposal 224 [XXX], dubbed “Next-Generation Hidden Services in Tor”.
+
+Nick currently lists 25 different people who made writing new proposal
+possible, and they might be some still missing. We will spare the
+full list to the reader, but Tor Weekly News' archives [XXX] can attest that
+George Kadianakis deserves a special mention for his repeated efforts to
+move things forward.
+
+The proposal aims to replace “the current rend-spec.txt [XXX], rewritten
+for clarity and for improved design.” The most user visible change
+from the current hidden services is the new address format. The current
+proposal uses a base 32 encoding of the entire 256 bits of the long term
+Ed25519 master identity key (section 1.2). Thus “a new name following
+this specification might look like:
+a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion”. Other
+encoding might still worth consideration as long as they make valid
+hostnames.
+
+Less visible changes include the departure from RSA1024, DH1024,
+and SHA1 to prefer Ed25519, Curve25519, and SHA256 as the basic crypto
+blocks (section 0.3).
+
+The set of hidden service descriptor directories used to publish a
+descriptor now depends on a “collaboratively generated random value”
+provided by the Tor directory authorities (see proposal 225 for the idea
+[XXX]). Together with the new “blinded signing key” (section 1.3), this
+should prevent future enumeration of hidden services.
+
+The new proposal also introduces the possibility of keeping the master
+identity key offline (section 1.7).
+
+In order to move the proposal forward, Nick Mathewson tell the readers:
+“I'd like to know what doesn't make sense, what I need to explain
+better, and what I need to design better. I'd like to fill in the gaps
+and turn this into a more full document. I'd like to answer the open
+questions. Comments are most welcome, especially if they grow into
+improvements.” The proposal is still sprinkled with TODO items, so feel
+free to jump in!
+
+ [XXX] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/001-process.txt
+ [XXX] https://lists.torproject.org/pipermail/tor-dev/2013-November/005877.html
+ [XXX] https://blog.torproject.org/category/tags/tor-weekly-news
+ [XXX] https://gitweb.torproject.org/torspec.git/blob/refs/heads/master:/rend-spec.txt
+ [XXX] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/225-strawman-shared-rand.txt
Tor relay operators meeting at 30C3
-----------------------------------
@@ -126,6 +173,4 @@
Possible items:
- * Philipp Winter released a Stem based exit scanner https://lists.torproject.org/pipermail/tor-dev/2013-November/005863.html ; https://github.com/NullHypothesis/exitmap
-
- * Proposal 225: Strawman proposal: commit-and-reveal shared rng https://lists.torproject.org/pipermail/tor-dev/2013-November/005878.html+ * Philipp Winter released a Stem based exit scanner https://lists.torproject.org/pipermail/tor-dev/2013-November/005863.html ; https://github.com/NullHypothesis/exitmap
--
Your friendly TWN monitoring script
In case of malfunction, please reach out for lunar at torproject.org
or for the worst cases, tell weasel at torproject.org to kill me.
More information about the news-team
mailing list