[TWN team] Recent changes to the wiki pages
Lunar
lunar at torproject.org
Mon Sep 9 16:20:08 UTC 2013
===========================================================================
=== https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2013/10 ===
===========================================================================
version 40
Author: lunar
Date: 2013-09-09T15:34:45+00:00
rework the piece about the new release
--- version 39
+++ version 40
@@ -15,28 +15,43 @@
Tor 0.2.4.17-rc is out
----------------------
-On 5th September, Roger Dingledine announced the release of a new release candidate
-for Tor 0.2.4 series [XXX]. It comes with very handy feature in the current situation [XXX]
-- prioritizing faster and safer circuit-level handshakes "NTor" over "TAP" used by
-0.2.3 clients.
-
-“Relays now process the new "NTor" circuit-level handshake requests with higher
-priority than the old "TAP" circuit-level handshake requests. We still process
-some TAP requests to not totally starve 0.2.3 clients when NTor becomes popular.
-A new consensus parameter "NumNTorsPerTAP" lets us tune the balance later if we
-need to. Implements ticket 9574 [XXX].”
-
-Roger asks relay operators to consider upgrading to 0.2.4.17-rc version due the huge
-circuit overload we see nowadays [XXX]. Upgrading to development branch is surprisingly
-easy using this guide [XXX].
-
+There are now confirmations [XXX] that the sudden influx of Tor clients which
+started mid-August is indeed coming from a botnet. “I guess all that
+work we've been doing on scalability was a good idea” wrote Roger
+Dingledine wrote in a blog post about “how to handle millions of new
+Tor clients” [XXX].
+
+On September 5th, Roger Dingledine announced the release of the third
+release candidate for the tor 0.2.4 series [XXX]. This is an emergency
+release “to help us tolerate the massive influx of users: 0.2.4 clients
+using the new (faster and safer) ‘NTor’ circuit-level handshakes now
+effectively jump the queue compared to the 0.2.3 clients using ‘TAP’
+handshakes” [XXX].
+
+It also contains several minor bugfixes and some new status messages for
+better monitoring of the current situation.
+
+Roger asked relay operators to upgrade to 0.2.4.17-rc [XXX]: “the more
+relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be
+for 0.2.4 users, despite the huge circuit overload that the network is
+seeing.”
+
+For relays running Debian or Ubuntu, upgrading to the development branch
+can be done using the Tor project's package repository [XXX]. New
+versions of the beta branch of the Tor Browser Bundle are also
+available [XXX] since September 6th.
+
+Hopefully, this will be the last release candidate. What looks missing
+at this point to declare the 0.2.4.x series stable is simply enough time
+to finish the release notes.
+
+ [XXX] http://blog.fox-it.com/2013/09/05/large-botnet-cause-of-recent-tor-network-overload/
+ [XXX] https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients
[XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029857.html
- [XXX] https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients
[XXX] https://trac.torproject.org/projects/tor/ticket/9574
[XXX] https://lists.torproject.org/pipermail/tor-relays/2013-September/002701.html
[XXX] https://www.torproject.org/docs/debian.html.en#development
-
- XXX:Expand
+ [XXX] https://blog.torproject.org/blog/new-tor-02417-rc-packages
The future of Tor cryptography
------------------------------
@@ -302,9 +317,6 @@
* Asa's timeline about the rise of new users and events that could have affected Tor https://lists.torproject.org/pipermail/tor-talk/2013-September/029822.html
* George forgot the torrc modification in his howto https://lists.torproject.org/pipermail/tor-relays/2013-September/002691.html
* Karsten's notes on IRC dev-meeting https://lists.torproject.org/pipermail/tor-dev/2013-September/005370.html / Nathan's https://lists.torproject.org/pipermail/tor-dev/2013-September/005371.html
- * Tor 0.2.4.17-rc https://lists.torproject.org/pipermail/tor-relays/2013-September/002701.html https://lists.torproject.org/pipermail/tor-talk/2013-September/029857.html https://blog.torproject.org/blog/new-tor-02417-rc-packages
- * arma's blog post https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients
* another research paper about hidden services https://lists.torproject.org/pipermail/tor-talk/2013-September/029856.html
- * fox-it blog post https://lists.torproject.org/pipermail/tor-talk/2013-September/029862.html http://blog.fox-it.com/2013/09/05/large-botnet-cause-of-recent-tor-network-overload/
* Testing flash proxy infrastructure https://lists.torproject.org/pipermail/tor-dev/2013-September/005402.html
* Quickly testing TOR using Chutney and Fluxcapacitor https://lists.torproject.org/pipermail/tor-dev/2013-September/005403.html
version 39
Author: nickm
Date: 2013-09-09T15:26:16+00:00
nickm explains himself.
--- version 38
+++ version 39
@@ -58,18 +58,23 @@
I want to fix all that in 0.2.5 — see proposal 220 [XXX], and George
Kadianakis’ draft hidden service improvements [XXX,XXX], and so forth.”
Regarding symmetric keys, Nick wrote: “We’re using AES128. I’m hoping
-to move to XSalsa20 or something like it.”
+to move to XSalsa20 or something like it.” In response to a query, Nick
+clarifies that he doesn't think AES is broken: only hard to implement right,
+and only provided in TLS in concert with modes that are somewhat (GCM)
+or fairly (CBC) problematic.
The effort to design better cryptography for the Tor protocols is not
new. More than a year ago, Nick Mathewson presented proposal 202 [XXX]
-outlining two possible new relay encryption protocols for Tor cells.
+outlining two possible new relay encryption protocols for Tor cells. Nick
+mentioned that he's waiting for a promising paper to get finished here
+before implementation.
A third question was raised [XXX] regarding the trust in algorithms
certified by the US NIST [XXX]. Nick speculations put aside, he also
emphasised that several NIST algorithms were “hard to implement
correctly” [XXX].
-Nick’s also plan to move away from NIST algorithms [XXX]: “Over the 0.2.5
+Nick also plans to change more algorithms [XXX]: “Over the 0.2.5
series, I want to move even more things (including hidden services) to
curve25519 and its allies for public key crypto. I also want to add
more hard-to-implement-wrong protocols to our mix: Salsa20 is looking
version 38
Author: lunar
Date: 2013-09-09T15:07:45+00:00
write about Tor crypto
--- version 37
+++ version 38
@@ -37,6 +37,62 @@
[XXX] https://www.torproject.org/docs/debian.html.en#development
XXX:Expand
+
+The future of Tor cryptography
+------------------------------
+
+After the last round of revelations from Edward Snowden, described as
+“explosive” by Bruce Schneier [XXX], several threads started on the
+tor-talk mailing list to discuss Tor cryptography.
+
+A lot of what has been written is speculative at this point. But some
+have raised concerns [XXX] about 1024 bit Diffie-Helmank key exchange [XXX].
+This has already been adressed with the introduction of the “ntor”
+handshake [XXX] in 0.2.4 and Nick Mathewson encourages everybody to
+upgrade [XXX].
+
+Another thread [XXX] prompted Nick to summarize [XXX] its
+views on the future of Tor cryptography. Regarding public keys, “with
+Tor 0.2.4, forward secrecy uses 256-bit ECC, which is certainly
+better, but RSA-1024 is still used in some places for signatures.
+I want to fix all that in 0.2.5 — see proposal 220 [XXX], and George
+Kadianakis’ draft hidden service improvements [XXX,XXX], and so forth.”
+Regarding symmetric keys, Nick wrote: “We’re using AES128. I’m hoping
+to move to XSalsa20 or something like it.”
+
+The effort to design better cryptography for the Tor protocols is not
+new. More than a year ago, Nick Mathewson presented proposal 202 [XXX]
+outlining two possible new relay encryption protocols for Tor cells.
+
+A third question was raised [XXX] regarding the trust in algorithms
+certified by the US NIST [XXX]. Nick speculations put aside, he also
+emphasised that several NIST algorithms were “hard to implement
+correctly” [XXX].
+
+Nick’s also plan to move away from NIST algorithms [XXX]: “Over the 0.2.5
+series, I want to move even more things (including hidden services) to
+curve25519 and its allies for public key crypto. I also want to add
+more hard-to-implement-wrong protocols to our mix: Salsa20 is looking
+like a much better choice to me than AES nowadays, for instance.”
+
+Nick concluded one of his email with “these are interesting times for
+crypto”. It sounds like a good way to put it.
+
+ [XXX] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
+ [XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029917.html
+ [XXX] https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
+ [XXX] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/216-ntor-handshake.txt
+ [XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029930.html
+ [XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029927.html
+ [XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029941.html
+ [XXX] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/220-ecc-id-keys.txt
+ [XXX] https://lists.torproject.org/pipermail/tor-dev/2013-August/005279.html
+ [XXX] https://lists.torproject.org/pipermail/tor-dev/2013-August/005280.html
+ [XXX] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/202-improved-relay-crypto.txt
+ [XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029933.html
+ [XXX] https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology
+ [XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029937.html
+ [XXX] https://lists.torproject.org/pipermail/tor-talk/2013-September/029929.html
Toward a better performance measurement tool
--------------------------------------------
@@ -245,6 +301,5 @@
* arma's blog post https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients
* another research paper about hidden services https://lists.torproject.org/pipermail/tor-talk/2013-September/029856.html
* fox-it blog post https://lists.torproject.org/pipermail/tor-talk/2013-September/029862.html http://blog.fox-it.com/2013/09/05/large-botnet-cause-of-recent-tor-network-overload/
- * Tor encryption vs. latest revelations about NSA https://lists.torproject.org/pipermail/tor-talk/2013-September/029929.html https://lists.torproject.org/pipermail/tor-talk/2013-September/029930.html
* Testing flash proxy infrastructure https://lists.torproject.org/pipermail/tor-dev/2013-September/005402.html
* Quickly testing TOR using Chutney and Fluxcapacitor https://lists.torproject.org/pipermail/tor-dev/2013-September/005403.html
version 37
Author: mparte
Date: 2013-09-09T14:43:02+00:00
ironed out some confusions in "simple ways to contribute" section
--- version 36
+++ version 37
@@ -182,30 +182,32 @@
Simple Ways to Contribute This Week
-----------------------------------
+
Each week will be listed here some simple tasks that people who want to
-begin to hack on Tor could do.
-
-If you're already hacking on Tor and want a ticket featured here, add
-"easy" to the keywords field on Trac.
+begin to hack on the Tor Project could do.
+
+If you're hacking on Tor and want a ticket featured here, add "easy" to
+the keywords field on Trac.
Highlighted this week:
-* Let User's know *who* is making a new control port connection [XXX]
- Why? Let User's know *who* is making a new control port connection so
- they have info to go on to rule out an attack.
- Practice: Navigating C code-base Difficulty: *
-
-* A usability issue with the check.torproject.org page [XXX]
- Why? An unknown percentage of users will believe they are using Tor
- when they are totally unprotected.
- Practice: git, patch, diff Difficulty: *
-
-* Enable Stem to check its capabilities are in line with Tor's [XXX]
- Why? Reduce workload for keeping Stem up to date with changes in Tor.
- Practice: Python, Tor Control Protocol Difficulty: **
+* Let User's know which IP is making a new control port connection [XXX]
+ Why? Let User's know which IP/application is making a new control port
+ connection so they have info to go on to rule out an attack.
+ Practice: C, Network Service Primitives
+
+* Change 'your' to 'this' on check.torproject.org page [XXX]
+ Why? A small percentage of users will misinterpret "your browser" to
+ mean their existing browser with dire consequences.
+ Practice: Git, Patch, Diff
+
+* Add tests to Stem to try and detect new versions of Tor [XXX]
+ Why? Reduce workload for keeping Stem up to date with changes in Tor &
+ making sure programs that rely on Stem are kept closely up to date with
+ Tor.
+ Practice: Python, Tor Control Protocol, Testing
[XXX] https://trac.torproject.org/projects/tor/ticket/9698
- [XXX] https://trac.torproject.org/projects/tor/ticket/9222
[XXX] https://trac.torproject.org/projects/tor/ticket/9631
[XXX] https://trac.torproject.org/projects/tor/ticket/8250
--
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.
UPDATE LAST MAIL DATE
More information about the news-team
mailing list