- tor-dev - lists.torproject.org

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

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

03 Jan '16

And yet the NSA is moving to prime numbers. A large public key isn't a very good reason to not adopt quantum-safe crypto, it just means that it requires having the Tor project to be able to scale to a larger degree. I suggest hash tables, a percentage of which are pseudorandomly downloaded. Otherwise the Tor project won't scale to 10x the relays ... even ignoring quantum cryptography.

4 4

trac account 'proper' - Full Disclosure
by Patrick Schleizer 02 Jan '16

02 Jan '16

Hi, I've learned that using the trac account 'proper' [1] has lead to some confusion and/or curiosity. That account name is really old, it's been created while I was still anonymous. Tickets created by the trac account are created by me, Patrick Schleizer, nickname adrelanos. The arguments made in these tickets should stand or fall independently of my identity. Those are either of interest for me personally, for my general contribution to Libre Software and/or for the Whonix project. >From now, I will be using my new trac account 'adrelanos'. Cheers, Patrick [1] https://trac.torproject.org/projects/tor/query?reporter=proper&col=id&col=s…

2 1

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

02 Jan '16

The first step should be replacing the long-term keys with quantum-safe crypto.

2 1

Proposal 262: Re-keying live circuits with new cryptographic material
by Nick Mathewson 29 Dec '15

29 Dec '15

[Proposal 261 probably needs this.] Filename: 262-rekey-circuits.txt Title: Re-keying live circuits with new cryptographic material Author: Nick Mathewson Created: 28 Dec 2015 Status: Open 1. Summary and Motivation Cryptographic primitives have an upper limit of how much data should be encrypted with the same key. But currently Tor circuits have no upper limit of how much data they will deliver. While the upper limits of our AES-CTR crypto is ridiculously high (on the order of hundreds of exabytes), the AEZ crypto we're considering suggests we should rekey after the equivalent in cells after around 280 TB. 280 TB is still high, but not ridiculously high. So in this proposal I explain a general mechanism for rekeying a circuit. We shouldn't actually build this unless we settle on 2. RELAY_REKEY cell operation To rekey, the circuit initiator ("client") can send a new RELAY_REKEY cell type: struct relay_rekey { u16 rekey_method IN [0, 1]; u8 rekey_data[]; } const REKEY_METHOD_ACK = 0; const REKEY_METHOD_SHAKE128_CLIENT = 1; This cell means "I am changing the key." The new key material will be derived from SHAKE128 of the aez_key concatenated with the rekey_data field, to fill a new shake_output structure. The client should set rekey_data at random. After sending one of these RELAY_REKEY cells, the client uses the new aez_key to encrypt all of its data to this hop, but retains the old aez_key for decrypting the data coming back from the relay. When the relay receives a RELAY_REKEY cell, it sends a RELAY_REKEY cell back towards the client, with empty rekey_data, and relay_method==0, and then updates its own key material for all additional data it sends and receives to the client. When the client receives this reply, it can discard the old AEZ key, and begin decrypting subsequent inbound cells with the new key. So in summary: the client sends a series of cells encrypted with the old key, and then sends a REKEY cell, followed by relay cells encrypted with the new key: OldKey[data data data ... data rekey] NewKey[data data data...] And after the server receives the REKEY cell, it stops sending relay cells encrypted with the old keys, sends its own REKEY cell with the ACK method, and starts sending cells encrypted with the new key. REKEY arrives somewhere in here I V OldKey[data data data data rekey-ack] NewKey[data data data ...] 2.1. Supporting other cryptography types Each relay cipher must specify its own behavior in the presence of a REKEY cell of each type that it supports. In general, the behavior of method 1 ("shake128-client") is "regenerate keys as if we were calling the original KDF after a CREATE handshake, using SHAKE128 on our current static key material and on a 32-byte random input." The behavior of any unsupported REKEY method must be to close the circuit with an error. The AES-CTR relay cell crypto doesn't support rekeying. See 3.2 below if you disagree. 2.2. How often to re-key? Clients should follow a deterministic algorithm in deciding when to re-key, so as not to leak client differences. This algorithm should be type-specific. For AEZ, I recommend that clients conservatively rekey every 2**32 cells (about 2 TB). And to make sure that this code actually works, the schedule should be after 2**15 cells, and then every 2**32 cells thereafter. It may be beneficial to randomize these numbers. If so, let's try subtracting between 0 and 25% at random. 2.3. How often to allow re-keying? We could define a lower bound to prevent too-frequent rekeying. I'm not sure I see the point here; the process described above is not that costly. 3. Alternative designs 3.1. Should we add some public key cryptography here? We could change the body of a REKEY cell and its ack to be more like CREATE/CREATED. Then we'd have to add a third step from the client to the server to acknowledge receipt of the 'CREATED' cell and changing of the key. So, what would this added complexity and computational load buy us? It would defend against the case where an adversary had compromised the shared key material for a circuit, but was not able to compromise the rekey process. I'm not sure that this is reasonable; the likeliest cases I can think of here seem to be "get compromised, stay compromised" for a circuit. 3.2. Hey, could we use this for forward secrecy with AES-CTR? We could, but the best solution to AES-CTR's limitations right now is to stop using our AES-CTR setup. Anything that supports REKEY will also presumably support AEZ or something better. 3.3. We could upgrade ciphers with this! Yes we could. We could define this not only to change the key, but to upgrade to a better ciphersuite. For example, we could start by negotiating AES-CTR, and then "secretly" upgrade to AEZ. I'm not sure that's worth the complexity, or that it would really be secret in the presence of traffic analysis.

2 1