- tor-dev - lists.torproject.org

Tor metrics: Questionable relays-by-platform accounting
by Fabian Keil 09 Jan '16

09 Jan '16

Looking at "Tor metrics - Relays by platform" [0] one could think that the number of "FreeBSD" relays is only slightly lower than the number of "Windows" relays. It also looks like the number of "other" platforms is constantly zero while the number of "Darwin" relays is unclear (but potentially zero as well). Obviously that's incorrect: fk@r500 ~ $sudo -u _tor grep platform /usr/jails/tor-jail/var/db/tor/cached-descriptors | cut -w -f 5 | sort | uniq -c | sort -rn 6662 Linux 555 Windows 286 FreeBSD 83 OpenBSD 25 Darwin 10 NetBSD 4 SunOS 4 ElectroBSD 4 Bitrig 2 DragonFly 1 GNU/kFreeBSD 1 CYGWIN_NT-10.0-WOW Is it possible that the "Tor metrics" count everything but "Linux" and "Windows" as FreeBSD? Fabian [0] https://metrics.torproject.org/platforms.html

3 6

Proposal: Stop giving Exit flags when only unencrypted traffic can exit
by Tom van der Woerdt 08 Jan '16

08 Jan '16

I've had this on my todo list for a while, finally wrote it down. Honestly, it's a minor change, but something that imho needs to be done. Torspec branch: https://github.com/TvdW/torspec/commits/exit-flag-not-all-plaintext Full text below, tldr first: replace [80,443,6667] with [80,443,5222] for Exit flagging. =================== Filename: 264-exit-flag-not-all-plaintext.txt Title: Stop giving Exit flags when only unencrypted traffic can exit Author: Tom van der Woerdt Created: 2016-01-05 Status: Open 1. Introduction Tor's Exit flags are assigned to relays that have an exit policy that allows exiting to at least two out of three pre-defined ports: 80, 443 and 6667. Since 80 and 6667 (resp. http and irc) are generally used for unencrypted traffic, an attacker could construct an exit policy that relays only unencrypted data. 2. Changes 2.1. Exit flagging By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to unencrypted ports. 2.2. dir-spec.txt A change to dir-spec.txt will be needed to change port 6667 to 5222. 3. Migration This change only needs to be rolled out to directory authorities. Since the flagging system is simple, no special migration is needed for this change, and it will take effect as soon as the deployment of the change has reached a sufficient number of directory authorities. 4. Other considerations While it would have been ideal to drop the port 80 condition as well, in the current state of the internet this is not likely to be a good idea. Too much websites still use unencrypted connections. However, this may be worth reconsidering every few years. XMPP was chosen to replace IRC because nowadays unencrypted XMPP is rare, and because the XMPP protocol is slowly gaining popularity within the communities on the internet. Other popular ports have been considered, such as 22 (SSH), 465 (SMTP), or 995 (POP3), but these are unlikely to be good candidates because of wide spread bruteforce attacks on these ports. =================== Tom

8 16

Proposal 264: Putting version numbers on the Tor subprotocols
by Nick Mathewson 08 Jan '16

08 Jan '16

Filename: 264-subprotocol-versions.txt Title: Putting version numbers on the Tor subprotocols Author: Nick Mathewson Created: 6 Jan 2016 Status: Open 1. Introduction At various points in Tor's history, we've needed to migrate from one protocol to another. In the past, we've mostly done this by allowing relays to advertise support for various features. We've done this in an ad-hoc way, though. In some cases, we've done it entirely based on the relays' advertised Tor version. That's a pattern we shouldn't continue. We'd like to support more live Tor relay implementations, and that means that tying "features" to "tor version" won't work going forwards. This proposal describes and alternative method that we can use to simplify the advertisement and discovery of features, and the transition from one set of features to another. 1.1. History: "Protocols" vs version-based gating. For ages, we've specified a "protocols" line in relay descriptors, with a list of supported versions for "relay" and "link" protocols. But we've never actually looked at it, and instead we've relied on tor version numbers to determine which features we could rely upon. We haven't kept the relay and link protocols listed there up-to-date either. Clients have used version checks for three purposes historically: checking relays for bugs, checking relays for features, and implementing bug-workarounds on their own state files. In this design, feature checks are now performed directly with subprotocol versions. We only need to keep using Tor versions specifically for bug workarounds. 2. Design: Advertising protocols. We revive the "Protocols" design above, in a new form. "proto" Entries NL Entries = Entries = Entry Entries = Entry SP Entries Entry = Keyword "=" Values Values = Value Values = Value "," Values Value = Int Value = Int "-" Int Int = NON_ZERO_DIGIT Int = Int DIGIT Each 'Entry' in the "proto" line indicates that the Tor relay supports one or more versions of the protocol in question. Entries must be sorted by keyword. Values must be numerically ascending within each entry. (This implies that there are no overlapping ranges.) Ranges must be represented as compactly as possible. Ints must be no more than 2^32 - 1. The semantics for each keyword must be defined in a Tor specification. Extension keywords are allowed if they begin with "x-" or "X-". Keywords are case-sensitive. During voting, authorities copy these lines immediately below the "v" lines. When a descriptor does not contain a "proto" entry, the authorities should reconstruct it using the approach described below in section A.1. They are included in the consensus using the same rules as currently used for "v" lines, if a sufficiently late consensus method is in use. 2.1. An alternative: Moving 'v' lines into microdescriptors. [[[[[ Here's an alternative: we could put "v" and "proto" lines into microdescriptors. When building microdescriptors, authorities could copy all valid "proto" entries verbatim if a sufficiently late consensus method is in use. When a descriptor does not contain a "proto" entry, the authorities should reconstruct it using the approach described below in section A.1. Tor clients that want to use "v" lines should prefer those in microdescriptors if present, and ignore those in the consensus. (Existing maintined client versions can be adapted to never look at "v" lines at all; the only versions that they still check for are ones not allowed on the network. The "v" line can be dropped from the consensus entirely when current clients have upgraded.) ]]]]] [I am rejecting this alternative for now, since proto lines should compress very well, given that the proto line is completely inferrable from the v line. Removing all the v lines from the current consensus would save only 1.7% after gzip compression.] 3. Using "protos" and "v" lines Whenever possible, clients and relays should use the list of advertised protocols instead of version numbers. Version numbers should only be used when implementing bug-workarounds for specific Tor versions. Every new feature in tor-spec.txt, dir-spec.txt, and rend-spec.txt should be gated on a particular protocol version. 4. Required protocols The consensus may contain three lines: RequiredRelayProtocols, RecommendedClientProtocols, and RequiredClientProtocols. Each has the same format as the "protos" line. To vote on these entries, a protocol/version combination is included only if it is listed by a majority of the voters. When a relay lacks a protocol listed in RequiredRelayProtocols, it must not attempt to join the network. When a client lacks a protocol listed in RecommendedClientProtocols, it should warn the user that the client is obsolete. When a client lacks a protocol listed in RequiredClientProtocols, it must not use the corresponding feature. If the corresponding feature is required to operate a Tor client, the client must must log an error message and shut down without connecting to the network, even if the cached consensus is out-of-date. This implements a "safe forward shutdown" mechanism for zombie clients. The above features should be backported to 0.2.4 and later. 5. Current protocols (See "6. Maintaining the protocol list" below for information about how I got these, and why version 0.2.4.19 comes up so often.) 5.1. "Link" The "link" protocols are those used by clients and relays to initiate and receive OR connections and to handle cells on OR connections. The "link" protocol versions correspond 1:1 to those versions. Two Tor instances can make a connection to each other only if they have at least one link protocol in common. The current "link" versions are: "1" through "4"; see tor-spec.txt for more information. All current Tor versions support "1-3"; version from 0.2.4.11-alpha and on support "1-4". Eventually we will drop "1" and "2". 5.2. "LinkAuth" LinkAuth protocols correspond to varieties of Authenticate cells used for the v3+ link protocools. The currrent version is "1". 5.3. "Relay" The "relay" protocols are those used to handle CREATE cells, and those that that handle the various RELAY cell types received after a CREATE cell. (Except, relay cells used to manage introduction and rendezvous points are managed with the "HSMid" protocols.) "1" -- supports the TAP key exchange, with all features in Tor 0.2.3. Support for CREATE and CREATED and CREATE_FAST and CREATED_FAST and EXTEND and EXTENDED. "2" -- supports the ntor key exchange, and all features in Tor 0.2.4.19. Includes support for CREATE2 and CREATED2 and EXTEND2 and EXTENDED2. 5.3. "HSMid" The "HSMid" protocols are those that handle introduction points and rendezvous points. "1" -- supports all features in Tor 0.2.4.19 5.4. "DirCache" The "DirCache" protocols are the set of documents available for download from a directory cache via BEGIN_DIR, and the set of URLs available to fetch them. (This excludes URLs for hidden service objects.) "1" -- supports all features in Tor 0.2.4.19. 5.5. "HSDir" The HSDir protocols are the set of hidden service document types that can be uploaded to, understood by, and downloaded from a tor relay, and the set of URLs available to fetch them. "1" -- supports all features in Tor 0.2.4.19. 5.6. "Desc" Describes features present or absent in descriptors. Most features in descriptors don't require a "Desc" update -- only those that need to someday be required. For example, someday clients will need to understand ed25519 identities. "1" -- supports all features in Tor 0.2.4.19. "2" -- cross-signing with onion-keys, signing with ed25519 identities. 5.7. "Microdesc" Describes features present or absent in microdescriptors. Most features in descriptors don't require a "MircoDesc" update -- only those that need to someday be required. These correspond more or less with consensus methods. "1" -- consensus methods 9 through 20. "2" -- consensus method 21 (adds ed25519 keys to microdescs). 5.8. "Cons" Describes features present or absent in consensus documents. Most features in consensus documents don't require a "Cons" update -- only those that need to someday be required. These correspond more or less with consensus methods. "1" -- consensus methods 9 through 20. "2" -- consensus method 21 (adds ed25519 keys to microdescs). 6. Maintaining the protocol lists What makes a good fit for a "protocol" type? Generally, it's a set of communications functionality that tends to upgrade in tandem, and in isolation from other parts of the Tor protocols. It tends to be functionality where it doesn't make sense to implement only part of it -- though omitting the whole thing might make sense. (Looking through our suite of protocols, you might make a case for splitting DirCache into sub-protocols.) We shouldn't add protocols for features where others can remain oblivious to their presence or absence. For example, if some directory caches start supporting a new header, and clients can safely send that header without knowing whether the directory cache will understand it, then a new protocol version is not required. Because all relays currently on the network are 0.2.4.19 or later, we can require 0.2.4.19, and use 0.2.4.19 as the minimal version so we we don't need to do code archeology to determine which number Adding new protocol types is pretty cheap, given compression. A.1. Inferring missing protos lines. The directory authorities no longer allow versions of Tor before 0.2.4.8-alpha. But right now, there is no version of Tor in the consensus before 0.2.4.19. Therefore, we should disallow versions of Tor earlier than 0.2.4.19, so that we can have the protocol list for all current Tor versions include: DirCache=1 HSDir=1 HSMid=1 Link=1-4 LinkAuth=1 Relay=1-2 For Desc, Tor versions before 0.2.7.stable should be taken to have Desc=1 and versions 0.2.7.stable or later should have Desc=1-2. For Microdesc and Cons, Tor versions before 0.2.7.stable should be taken to support version 1; 0.2.7.stable and later should have 1-2. A.2. Initial required protocols For clients we will Recommend and Require: DirCache=1 HSDir=1 Desc=1 Cons=ANYOF(9-20) Microdesc=ANYOF(9-20) HSMid=1 Link=4 LinkAuth=1 Relay=2 For relays we will Require: DirCache=1 HSDir=1 Desc=1 Cons=ANYOF(9-20) Microdesc=ANYOF(9-20) HSMid=1 Link=3-4 LinkAuth=1 Relay=1-2 A.3. Example integration with other open proposals In this appendix, I try to show that this proposal is viable by showing how it can integrate with other open proposals to avoid version-gating. I'm looking at open/draft/accepted proposals only. 140 Provide diffs between consensuses This proposal doesn't affect interoperability, though we could add a DirCache protocol version for it if we think we might want to require it someday. 164 Reporting the status of server votes Interoperability not affected; no new protocol. 165 Easy migration for voting authority sets Authority-only; no new protocol. 168 Reduce default circuit window Interoperability slightly affected; could be a new Relay protocol. 172 GETINFO controller option for circuit information 173 GETINFO Option Expansion Client/Relay interop not affected; no new protocol. 177 Abstaining from votes on individual flags Authority-only; no new protocol. 182 Credit Bucket No new protocol. 188 Bridge Guards and other anti-enumeration defenses No new protocol. 189 AUTHORIZE and AUTHORIZED cells This would be a new protocol, either a Link protocol or a new LinkAuthz protocol. 191 Bridge Detection Resistance against MITM-capable Adversaries No new protocol. 192 Automatically retrieve and store information about bridges No new protocol. 195 TLS certificate normalization for Tor 0.2.4.x Interop not affected; no new protocol. 201 Make bridges report statistics on daily v3 network status requests No new protocol. 202 Two improved relay encryption protocols for Tor cells This would be a new Relay protocol. 203 Avoiding censorship by impersonating an HTTPS server Bridge/PT only; no new protocol. 209 Tuning the Parameters for the Path Bias Defense Client behavior only; no new protocol. 210 Faster Headless Consensus Bootstrapping Client behavior only; no new protocol. 212 Increase Acceptable Consensus Age Possibly add a new DirCache protocol version to describe the "will hold older descriptors" property. 219 Support for full DNS and DNSSEC resolution in Tor New relay protocol, or new protocol class (DNS=2?) 220 Migrate server identity keys to Ed25519 Once link authentication is supported, that's a new LinkAuth protocol version. No new protocol version is required for circuit extension, since it's a backward-compatible change. 224 Next-Generation Hidden Services in Tor Adds new HSDir and HSMid protocols. 226 "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS" No new protocol. 229 Further SOCKS5 extensions Client-only; no new protocol. 233 Making Tor2Web mode faster No new protocol. 234 Adding remittance field to directory specification Could be a new protocol; or not. 237 All relays are directory servers No new protocol. 239 Consensus Hash Chaining No new protocol. 242 Better performance and usability for the MyFamily option New Desc protocol. 244 Use RFC5705 Key Exporting in our AUTHENTICATE calls Part of prop220. Also adds another LinkAuth protocol version. 245 Deprecating and removing the TAP circuit extension protocol Removes Linkauth protocol 1. Removes a Desc protocol. 246 Merging Hidden Service Directories and Introduction Points Possibly adds a new HSMid protocol. 247 Defending Against Guard Discovery Attacks using Vanguards No new protocol. 248 Remove all RSA identity keys Adds a new Desc protocol version and a new Cons protocol version; eventually removes a version of each. 249 Allow CREATE cells with >505 bytes of handshake data Adds a new Link protocol version for CREATE2V. Adds a new Relay protocol version for new EXTEND2 semantics. 250 Random Number Generation During Tor Voting No new protocol. 251 Padding for netflow record resolution reduction No new protocol. 252 Single Onion Services No new protocol. 253 Out of Band Circuit HMACs New Relay protocol. 254 Padding Negotiation New Link protocol, new Relay protocol. 255 Controller features to allow for load-balancing hidden services No new protocol. 256 Key revocation for relays and authorities New Desc protocol. 257 Refactoring authorities and taking parts offline No new protocol. 258 Denial-of-service resistance for directory authorities No new protocol. 259 New Guard Selection Behaviour No new protocol 260 Rendezvous Single Onion Services No new protocol 261 AEZ for relay cryptography New Relay protocol version. 262 Re-keying live circuits with new cryptographic material New Relay protocol version 263 Request to change key exchange protocol for handshake New Relay protocol version.

2 1

[Win32] test_util.c + test_checkdir.c
by Gisle Vanem 07 Jan '16

07 Jan '16

The src/test/test_util.c have this statement: #ifdef _WIN32 #define UTIL_TEST_NO_WIN(n, f) { #n, NULL, TT_SKIP, NULL, NULL } #define UTIL_TEST_WIN_ONLY(n, f) UTIL_TEST(n, (f)) #define UTIL_LEGACY_NO_WIN(n) UTIL_NO_WIN(n) But I fail to see where 'UTIL_NO_WIN(n)' is defined. Should not the above read: --- a/test/test_util.c 2016-01-05 13:19:07 +++ b/test/test_util.c 2016-01-05 14:36:52 @@ -4676,7 +4676,7 @@ #ifdef _WIN32 #define UTIL_TEST_NO_WIN(n, f) { #n, NULL, TT_SKIP, NULL, NULL } #define UTIL_TEST_WIN_ONLY(n, f) UTIL_TEST(n, (f)) -#define UTIL_LEGACY_NO_WIN(n) UTIL_NO_WIN(n) +#define UTIL_LEGACY_NO_WIN(n) { #n, NULL, TT_SKIP, NULL, NULL } #else #define UTIL_TEST_NO_WIN(n, f) UTIL_TEST(n, (f)) With this, my test.exe runs fine. Although 36 SKIPPED tests. Another thing regarding MSVC. In test/test_checkdir.c, <dirent.h> is included for _WIN32. MSVC does not have this header. Hence I think this patch is needed: --- a/test/test_checkdir.c 2015-08-31 13:24:33 +++ b/test/test_checkdir.c 2015-08-31 14:50:53 @@ -4,9 +4,7 @@ #include "orconfig.h" #include "or.h" -#ifdef _WIN32 -#include <direct.h> -#else +#ifndef _MSC_VER #include <dirent.h> #endif Since <direct.h> is already included in "or.h", it's not needed here too. -- --gv

2 1

Applications Team meeting today (Tuesday Jan 5) 19:00 UTC
by Mike Perry 05 Jan '16

05 Jan '16

Hi, Just a reminder that the applications team is having its monthly meeting today at 19:00 UTC in #tor-project on irc.oftc.net. We'll likely recap the State of the Onion, and generally talk about UI/UX as per usual. Please come up with suggestions if you feel there is something else we should discuss. -- Mike Perry

1 0

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor
by Zhenfei Zhang 04 Jan '16

04 Jan '16

Hi all, Thanks for all the comments. Sorry I wasn't able to reply immediately. Please allow me to summarize the comments. I see mainly the following questions. 1. Quantum-safe authentication. As Yawning has pointed out, > I personally don't think that any of the PQ signature schemes are usable > for us right now, because the smallest key size for an algorithm that > isn't known to be broken is ~1 KiB (SPHINCS256), and we probably can't > afford to bloat our descriptors/micro-descriptors that much. This is also the reason we wanted to roll out QSH first and add the quantum-safe signature schemes later. We have several good candidate for quantum-safe encryption algorithms. But for signatures, they are not mature imho. Another reason that we did not include authentication is due to the attack model. As I have mentioned (but probably didn't explain very clearly) in previous email, we are facing two types of attackers. Attacker type I, passive attacker at present, who cannot break classical authentication nor encryption, record the data anyway, and decrypt it when quantum computer become available in future. Attack type II, active attacker who tries to attack the authentication while the communication is taking place. This attack will be possible in future when quantum computer arrives. But for now, they will not be successful. As we believe that there does not exist a general purpose quantum computer at present (and maybe several years away), we have time to deal with attacker type II. But the attacker type I is the real threat at the present day. Our proposal is to address this threat. 2. On NTRU vs NTRU-Prime vs R-LWE and others. The QSH is modular designed to suite any quantum-safe encryption algorithm. So we can chose any one we want for trail. And furthermore, we can also hybrid, say ECC, NTRU and R-LWE, to give a bit more confidence in case one of the quantum-safe encryption algorithm turns out to be not quantum safe, or broken. That been said, we chose NTRU for several reasons. NTRU is more mature than R-LWE from our point o view. NTRU has a full spec, a reference implementation, and is standardized by several bodies; while for R-LWE, since it enables many interesting cryptographic primitives, such as FHE, there has been many different parameter proposals, which leads to some kind of confusion as to which one should reference to. > However, if we were to go the route of using NTRU, we'd likely want to instead > use Dan Bernstein's NTRU Prime parameters, in order to eliminate some of the > inherent algebraic structure of the ideal lattice which might possibly be > exploited. [0] [1] As for NTRU-Prime, I am not aware there is a specific instantiation of this parameter sets, nor any paper that considers the security of a specific parameter set. Also, this NTRU-Prime would require some extensive scrutiny before we can use it. We are happy to roll out any above encryption algorithm as you see fit. But our proposal is mainly about the QSH approach. I think the best option for now is to buildin a QSH for Tor, with a flexible API that allows us to switch between algorithms when fit. And for now use any quantum-safe encryption algorithm that is ready to be used. After all, any QS encryption is better than nothing. 3. License I am sorry I am not familiar with the license. But my general feeling is that Security Innovation is willing to let Tor to use NTRU for free. We just need to work out the suitable license to make this happen. 4. Misc. > Post-quantum forward-secrecy is what I've been using to describe this > property. We will use this terminology. Thanks. > As I recall, the product form parameter sets are extra encumbered. > Apart from key/ciphertext size and a minor performance differential, is > there any reason to not use one of the X9.98 parameter sets (Eg: > EES613EP1) Yes we can use non-product form polynomials, if everyone agrees on it. Non-product form polynomials will make key generation and decryption a bit slower, but those cost are on the client side. It has no impact on the load of server side. > * "For 128 bits quantum security, use NTRU_EESS743EP1." should be > "For 256 bits" (Section 2.3). NTRU_EESS743EP1 provides 256 classical security and 128 bits quantum security. Please see https://eprint.iacr.org/2015/708.pdf for arguments of those security levels. > I'm a little confused about what exactly is meant by "disaster resilience" here. We will remove "disaster resilience". Those are most comments I saw. Sorry if I missed some of your comments. Please let me know if you have questions that I failed to answer. Happy new year to everyone. Cheers, Zhenfei On Sun, Jan 3, 2016 at 8:32 PM, Ryan Carboni <ryacko(a)gmail.com> wrote: > Wasn't there a transition period in migrating from RSA to ECC? > > Maybe I'm just confused. Or you are confused. But I think it is best plan > for a five or ten year transition period. > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >

2 2

Re: [tor-dev] tor-dev Digest, Vol 60, Issue 2
by Flipchan 04 Jan '16

04 Jan '16

How would u add quantum-safe crypto? I havent seen anyone puttin a pub lib that anyone can import tor-dev-request(a)lists.torproject.org skrev: (2 januari 2016 13:00:02 CET) >Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-dev digest..." > > >Today's Topics: > > 1. Re: Quantum-safe Hybrid handshake for Tor (Ryan Carboni) > 2. Re: Quantum-safe Hybrid handshake for Tor (Yawning Angel) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 1 Jan 2016 19:33:31 -0800 >From: Ryan Carboni <ryacko(a)gmail.com> >To: tor-dev(a)lists.torproject.org >Subject: Re: [tor-dev] Quantum-safe Hybrid handshake for Tor >Message-ID: > <CAO7N=i2MspE1N5eOczCyT9RCPORgUJboSOY3vUMGKL5FSzAPnw(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >The first step should be replacing the long-term keys with quantum-safe >crypto. >

5 6

Go version in Gitian descriptors
by Jeremy Rand 04 Jan '16

04 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I noticed that it looks like Tor Project is using Go 1.4.2 to build the pluggable transports in Gitian. I'm curious why a newer version of Go isn't used. My understanding is that Go 1.4.2 (or earlier) is needed to build Go 1.5 because 1.5's source code is itself in Go. Would using Go 1.5 be as simple as building 1.4.2 in Gitian (as is done now), and then using 1.4.2 to build 1.5, and then placing 1.5 in PATH instead of 1.4.2 as is done now? Have obstacles been identified in such a configuration, or is it just that no one tried it? Cheers, - -Jeremy Rand -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWifxjAAoJEAHN/EbZ1y0686cP/3kdRz3va8dZ056j4x9k+sd7 XJsfsj9eWJ/tPxdpppPsBIoseTVNrPSCOB/cJ/bc0Xl75KGQkHFsmGusnUp6kg9L bwJK8wcNoO+s5EjjiY/Rk39UQTNJ3YKOaanvUnGXolYy4LtgUTTI7jdSWcpyZmd7 zxQVzvIXQEawgbu9SjTzXFkBQVHkZzkCDmTPcQNEPtIZambj7fFU0EMBWSmrYkVa /Lzz0bq2wMcZBpdMR07JT0WcrXNgkun48gJlBCV2SuScgs+FycmQi1dVCapwptrQ H0WeCv61XnhXTlens60gfhjrXMcUf4Xud2p71pG0N3OYrF8eOJGpSzTdnBnOFNGw IA2B+CB8u6l8PoZAqeJg0qhFjwm/BoG9o8b8WI9WJOvqDsSfo9Mjmr2lfuoxEGI7 /Uu7aZgRboFI899/xfKJUjzZpQs3hVrtpgukjNEShDBBhsZDOQUkbfzw097NttxB Nst6RW8WmRpbvFMGMrLiYrUKxGKJkzOUVaexU2C9y6y5asq3i2qotTmXpzEHkcP0 XL4KR9/JC6MeuBqSszEb2gpcQsHVsPxk7Wo1cJwLDSeS2YniZnxlpre5DjF2Exez H54PqwtXTezThc8TZuTzfJZrkOA/X5ggL7/wnpUaDrF8T9r4fn1rosP6m8PdUeOL RhVNDX3NeTjV6KywVJX4 =ELuw -----END PGP SIGNATURE-----

5 4

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor
by Ryan Carboni 04 Jan '16

04 Jan '16

Wasn't there a transition period in migrating from RSA to ECC? Maybe I'm just confused. Or you are confused. But I think it is best plan for a five or ten year transition period.

1 0

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor
by Ryan Carboni 04 Jan '16

04 Jan '16

> > We had a GSOC project to produce "consensus diffs", so that clients could download the differences between each consensus each hour, rather than downloading a full consensus (~1.5MB). > > It showed some great results, but still needs a little work before we merge it.https://trac.torproject.org/projects/tor/ticket/13339 <https://trac.torproject.org/projects/tor/ticket/13339> > > Still, one doesn't need to download the full consensus. 3/16ths of the consensus could work and would be more beneficial for low bandwidth clients. If Tor became popular, it wouldn't be usable. Right now it consumes the bandwidth of several colleges. If Tor got anywhere near consuming the bandwidth and popularity of a major datacenter (such as the five million user botnet spike of 2013), Tor wouldn't work too well. Facebook has hundreds of millions of active users. A few billion people live under a dictatorship. How well would Tor work if it's infrastructure and usage was scaled up a hundred times? It's not an immediate issue, but if one was to add quantum cryptography, this would be one of the issues that needs to be addressed (as it is one of many long-term issues). nb: Migrating to X448 would possibly hold up longer than Curve25519 > would since it requires a bigger quantum computer. But performance > isn't that great without using vectorization. > > Given the slow time it takes to roll things out, a timeline which begins with trusted directory keys include post-quantum crypto first, and which ends in enabling clients to use post-quantum crypto would be best.

3 2