- tor-dev - lists.torproject.org

[GSOC16] Fingerprint Central - Status report n°1
by Pierre Laperdrix 03 Jun '16

03 Jun '16

Hi everyone, Here is my first status report for my GSOC project. 1 - Here is the link to the GitHub repo of the project: https://github.com/plaperdr/fp-central I have chosen the name "Fingerprint Central" for the project. I may change it in the future but I'm pretty satisfied with it for the moment. If someone has a great suggestion to replace it, don't hesitate to send it to me! I have also included on the main page a checklist for anyone to follow the progression of development. 2 - I took the time to build strong foundations for my project to support both current and future features. * To support addition and removal of fingerprinting tests, I have added a system that need two components: - a definition file where one gives all the information related to the test - the source code needed to execute the test With this system, I can manage tests dynamically and I can give information to the users on what is currently being run in the test suite. * To support different types of fingerprints and browsers, I plan to integrate a system to tag fingerprints. Instead of storing fingerprints in specific databases, I found that a tag system is a flexible way to deal with any changes and when statistics will be implemented, it will be easier to get numbers on relevant categories thanks to tags. Everything is explained in greater details in the "fingerprint" folder of the repo in the Readme files. I'd love to have feedback on it to know if I'm going in the right direction and if my project seems well structured. 3 - Everything that I'm planning to use is present in the Debian repositories except for the PyMongo support of Flask. This means that it may possible to use the Tor infrastructure to host the website. I'll see when I get closer to a first stable version what could be possible on that front. What's next? My focus for the next two weeks is mainly to add new tests (both standard and specific to the Tor browser) and to add support of MongoDB. I hope to have a page that collects fingerprints, stores them in Mongo and calculate statistics on them. That's it for me this week! Have a great week-end everyone, Pierre

1 0

[GSoC 2016] Orfox - Report 1
by Amogh Pradeep 03 Jun '16

03 Jun '16

Hey guys, This is my first status report for GSoC 2016. I’ve attended the tor browser meeting on IRC and done some organizational work there. We plan to now track Orfox specific tickets on trac [0] using the keyword “tbb-mobile”. We still have bugs on the TGP bug tracker [1] but plan to move slowly from there to trac. Currently, on the tor projects trac, we have mobile fingerprinting tickets. I’ve also had success in rebasing from orfox-tor-browser-38.5.0esr-5.5-2 to orfox-tor-browser-38.8.0esr-5.5-1 [2]. Between the time of writing the GSoC proposal and the start of the program, we rebased from orfox-tb_GECKO380esr_2015050513_RELBRANCH to orfox-tor-browser-38.5.0esr-5.5-2. And now we’ve successfully moved to 38.8.0. Here’s a temporary build if someone wants to check it out [3]. But the official one should be on FDroid pretty soon. Next up, ESR 45. Rebasing to 45 might be harder, but I will see how it goes. After which I plan on starting with the code audit. Thats it for now, just regular maintenance stuff, nothing fancy to report! Hope you guys have a nice weekend. Best, Amogh Pradeep amoghbl1(a)gmail.com [0] https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~tbb… [1] https://dev.guardianproject.info/projects/orfox-private-browser/issues/ [2] https://github.com/amoghbl1/tor-browser/ [3] https://web.iiit.ac.in/~amoghbl1/Orfox-38.8.0.apk

1 0

[GSoC] CONIKS for Tor Messenger - 1st status report
by Huy Vu Quoc 02 Jun '16

02 Jun '16

Hi everyone, This is the first status report on the CONIKS for Tor Messenger project. This is what I have done so far: * Discussing with Arlo and Marcela about the account verification module. The proposal is described below. * Implementing the Merkle prefix tree module. The source code is under review and is available on github repo [1] * Submitting 2 patches for ctype-otr addon (pull #74 and #75 [2]) For now, I'm working on implementing the STR module as a part of Merkle tree module. This module would be moved into its own repo as a library, separated from the key server module, after others commented on the code. Next I plan to continue implementing the key server module (including the registration and key change operation). It also requires a prototype implementation of the account verification module. Besides, we also established the collaboration with engineers and PhD students from EPFL on developing the CONIKS server module. The source code of the CONIKS server module would be committed to its own repo [3], while other Tor Messenger specific modules would be committed to the repo of the project [4]. --- The account verification protocol is proposed as follows (credit to Arlo) - the user connects to an account - the client sends the registration request to a registration bot on the server - the client also signs the registered public key and sends it to the registration bot - the bot verifies the signature and registers the sending account with the public key The client sends the signed public key to the registration bot by using one of following methods: - send a direct message to the Twitter account of the bot (in case the account is a Twitter account) - send a private chat to the Jabber account of the bot (in case the account is a Jabber account) Best, Huy [1] https://github.com/coniks-sys/libconiks-server-go/pull/1 [2] https://github.com/arlolra/ctypes-otr/pulls [3] https://github.com/coniks-sys/libconiks-server-go/ [4] https://github.com/c633/tor-messenger-coniks

1 0

SHA-256 checksum mismatch
by Tuuranton 02 Jun '16

02 Jun '16

The SHA-256 checksum of the downloaded file https://www.torproject.org/dist/torbrowser/6.0/TorBrowser-6.0-osx64_en-US.d… is on my computer 0f4f6ca01028c2956c811dd94d67a76feb507cad176c031f32e6f95873003b4c But according to the text file https://dist.torproject.org/torbrowser/6.0/sha256sums-unsigned-build.txt the SHA-256 checksum of the file TorBrowser-6.0-osx64_en-US.dmg should be d68d01889ba38764ebf2057b3cd3263f638a74205031a6d1df11ab8ca13a3618 Why the mismatch?

3 2

Tor Messenger Sources
by AKASH DAS 01 Jun '16

01 Jun '16

Sir, Can you please tell me from where and how can I install sources of tor messenger so that I can start building it. Akash Das Student Systems Admin IIIT-Sricity

3 2

Re: [tor-dev] Tor Messenger Sources
by moosehadley＠gmail.com 01 Jun '16

01 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The guide on how to build Tor Messenger from source is here- https://gitweb.torproject.org/tor-messenger-build.git/tree/README Including the dependencies you need to build it. On Jun 1, 2016, at 2:56 AM, AKASH DAS <akash.d14(a)iiits.in> wrote: Sir, Can you please tell me from where and how can I install sources of tor messenger so that I can start building it. Akash Das Student Systems Admin IIIT-Sricity _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -----BEGIN PGP SIGNATURE----- Version: iPGMail (3.0.1) iQIcBAEBCAAGBQJXTpNWAAoJEMV6CBTIYTyTAAEQAMXb89I+5FzPtqqc1BcD8NAOBay6JYTb+/YR ytvipWr8uReasnXqnUnHM4uAJd5chtu3+1zHE25XCviozZPrg84OTNtGOTE4IbIVAnMx4e7dfbte Z2Pte4nOoixidU4AJfmhQL+rkyLQEIsTYcRxDTrSdEmXhxVFc1WfCEVy+ksq5g46xkEM/5TMZX2D v6T4tV7fBD9S/Aj9r/CL4GeeOVyH4Garj/ibpcSRbFeMJ/NnmmllJvq64/LHQvvIzRw+JatSg7Pk 4qtB/ccWNRPuA0YWCZncepE1SobtwY6HJLnDPw4+2umwhbRAG3Er0ojnpuqYRbQ3dfgJMENZA393 M/Pnmt3ex9t10gNJlYF1uSfu+ZXW6XbF5NLz6/6CmmjeLFxT0FN89xfgWbThlJIgarQI32Vy9/MD sNigyZAndifNpTiSnaarshmT46NLJT0l9/IIXDBZZrVC3vdZU3Rv48gco4YEFUzq3WrO5KpCHBER kBcbhHTlXsrhIo2iozQ0oDLkRBU9XAdLW47ELQc/is9P+GIumuysV58qaX/c3NrGjHCev+IqUbNk 2sCNBM5T1TvmYqDGBmgcKjSHggMj2zRNLxmu7ULeUOznvT6ZgHGDWbiPY5lJjPrSb1lrwEGA7mTW 9uLxKwdzPYxEKJuNUjwFHxs3H5GeQ2/bSYxivmfG =4Ssu -----END PGP SIGNATURE-----

1 0

both onionoo instances behind, any others available?
by nusenu 31 May '16

31 May '16

Hi, since both onionoo instances[1] I know of are currently "behind" (2016-05-26 and 2016-05-30 as of today 2016-05-31), does anyone know of other onionoo instances? thanks! https://onionoo.thecthulhu.com/details?limit=0 https://onionoo.torproject.org/details?limit=0

1 0

[PATCH torsocks]: Add support for the musl c library
by Felix Janda 30 May '16

30 May '16

Signed-off-by: Felix Janda <felix.janda(a)posteo.de> --- src/common/compat.c | 4 ++-- src/common/compat.h | 4 ++-- src/common/ref.h | 4 ++-- src/lib/torsocks.h | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/common/compat.c b/src/common/compat.c index a861b3d..eb8eb12 100644 --- a/src/common/compat.c +++ b/src/common/compat.c @@ -19,7 +19,7 @@ #include "compat.h" -#if (defined(__GLIBC__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) +#if (defined(__GLIBC__) || defined(__linux__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) /* * Initialize a pthread mutex. This never fails. @@ -96,4 +96,4 @@ void tsocks_once(tsocks_once_t *o, void (*init_routine)(void)) tsocks_mutex_unlock(&o->mutex); } -#endif /* __GLIBC__, __darwin__, __FreeBSD__, __NetBSD__ */ +#endif /* __GLIBC__, __linux__, __darwin__, __FreeBSD__, __NetBSD__ */ diff --git a/src/common/compat.h b/src/common/compat.h index ce47129..11e0175 100644 --- a/src/common/compat.h +++ b/src/common/compat.h @@ -22,7 +22,7 @@ #define __darwin__ 1 #endif -#if (defined(__GLIBC__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) +#if (defined(__GLIBC__) || defined(__linux__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) #define RTLD_NEXT ((void *) -1) @@ -55,7 +55,7 @@ void tsocks_once(tsocks_once_t *o, void (*init_routine)(void)); #else #error "OS not supported." -#endif /* __GLIBC__, __darwin__, __FreeBSD__, __NetBSD__ */ +#endif /* __GLIBC__, __linux__, __darwin__, __FreeBSD__, __NetBSD__ */ #if defined(__linux__) #include <unistd.h> diff --git a/src/common/ref.h b/src/common/ref.h index 88aec2e..32e07a1 100644 --- a/src/common/ref.h +++ b/src/common/ref.h @@ -26,7 +26,7 @@ struct ref { long count; }; -#if (defined(__GLIBC__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) +#if (defined(__GLIBC__) || defined(__linux__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) /* * Get a reference by incrementing the refcount. @@ -57,6 +57,6 @@ static inline void ref_put(struct ref *r, #else #error "OS not supported" -#endif /* __GLIBC__, __FreeBSD__, __darwin__ */ +#endif /* __GLIBC__, __linux__, __FreeBSD__, __darwin__ */ #endif /* TORSOCKS_REF_H */ diff --git a/src/lib/torsocks.h b/src/lib/torsocks.h index 076f3a5..5fb76ee 100644 --- a/src/lib/torsocks.h +++ b/src/lib/torsocks.h @@ -33,7 +33,7 @@ #define TSOCKS_DECL(name, type, sig) \ extern type tsocks_##name(sig); -#if (defined(__GLIBC__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) +#if (defined(__GLIBC__) || defined(__linux__) || defined(__FreeBSD__) || defined(__darwin__) || defined(__NetBSD__)) /* connect(2) */ #include <sys/types.h> @@ -207,7 +207,7 @@ struct hostent **result, int *h_errnop #else #error "OS not supported." -#endif /* __GLIBC__ , __FreeBSD__, __darwin__, __NetBSD__ */ +#endif /* __GLIBC__, __linux__, __FreeBSD__, __darwin__, __NetBSD__ */ #if (defined(__linux__)) -- 2.7.3

2 1

tor on GNU/Windows
by Ian Goldberg 28 May '16

28 May '16

I had a crazy thought the other day: has anyone tried running the Linux version of tor (client or node) on the new GNU/Windows (or whatever they're officially calling their Linux compatability layer)?

3 2

Test coverage updates on 0.2.8, master vs 0.2.7
by Nick Mathewson 26 May '16

26 May '16

Hi, all. In our first stable 0.2.7 release (0.2.7.5), we had 39.5% line coverage from our unit tests, and 66.1% from unit plus integration tests. In current 0.2.8, we have 46.8% from unit tests, and 69.7% from integration tests. In current master, we have 47.0% from unit tests, and 69.6% from integration tests. (All number as of a couple days ago on my linux desktop) So far, so good. Now, let's do a breakdown of the changes in UNIT TEST COVERAGE between 0.2.7 and 0.2.8 based on the cov-diff tool in scripts/test, git diff --stat tor-0.2.7.5 maint-0.2.8 src/{common,or} gives me: 180 files changed, 9434 insertions(+), 3571 deletions(-) grep '^- *1' cov-diff-output | wc -l 438 removed lines-with-coverage. grep '^- *#' cov-diff-output | wc -l 4266 removed lines without coverage [*] grep '^+ *#' cov-diff-output | wc -l 2367 insertions without coverage. [**] grep '^+ *1' cov-diff-output | wc -l 5793 insertions WITH coverage. [*] Note that these could be either lines that we began to cover with tests, OR lines that had no coverage which we removed, OR lines that had no coverage which we edited. [**] Note that these could be either lines that we stopped covering with tests, OR lines that we added without tests, OR untested lines that we changed. Now the changes in INTEGRATION TEST COVERAGE: 1023 removed lines-with-coverage 1896 removed lines-without-coverage 1086 added lines without coverage. 5289 added lines with coverage (same disclaimers apply. Can we make cov-diff give even better results?) And last, a breakdown of changes between 0.2.8 and master so far: 58 files changed, 2110 insertions(+), 570 deletions(-) UNIT TESTS: 219 removed lines-with-coverage 132 removed lines-without-coverage 234 added lines without coverage. 317 added lines with coverage INTEGRATION TESTS: 359 removed lines-with-coverage 248 removed lines-without-coverage 401 added lines without coverage. 406 added lines with coverage -- Nick

1 0

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
by Zhenfei Zhang 26 May '16

26 May '16

Hi Peter, > That's great news! Any thoughts on the license? Can you place it into > public domain? I am not 100% sure but I think it will be the same as the current NTRU implementation. > Did the attachment get lost? Sorry. Here are the data extracted from our paper. The final version will be ready in a couple of days. The data are based on ntru-443 with CCA-2. By moving to CPA, we may be able to save say 30% of computation. The ntru-743 is roughly 2.5x slower than ntru-443. Cheers, Zhenfei On Thu, May 26, 2016 at 1:35 AM, Peter Schwabe <peter(a)cryptojedi.org> wrote: > Zhenfei Zhang <zzhang(a)securityinnovation.com> wrote: > > Hi Peter, > > Hi Zhenfei, hi all, > > > We are working on a constant-time implementation of NTRU. We expect to > > release the source code this summer. > > That's great news! Any thoughts on the license? Can you place it into > public domain? > > > However, as far as I know, timing attacks are much more powerful > > against encryption algorithm (that uses long-lived key for multiple > > times), rather than KEMs (use ephemeral keys). Our proposal treats > > NTRU as a KEM so I think the timing attack is not so useful. > > It's tricky; I agree that if you get only a single timing trace with the > same key, it will be much harder to get useful information about the > key than in a public-key encryption (or signature) setting where the > private key is used many times. Then again, I also think that it will be > very hard to prove that it's impossible to extract useful information > about keys from timing on any platform. > Maybe more importantly, Tor does not only have to be concerned about > leaking the key, but also leaking de-anonymizing information. That's why > Isis and I sat down and wrote a constant-time version of the sampling of > the public polynomial in NewHope. > My general take on this is that it's much easier to write constant-time > code than to deal with the fallout caused by software that is vulnerable > to timing attacks. > > > Please see the attached for some benchmark results. > > Did the attachment get lost? > > > We are working on the camera-ready version of the paper. The final > > version should be out soon. Also note that we are using an IND-CCA-2 > > secure version of NTRU. The performance can be further improved by > > switching to the IND-CPA secure version. IND-CPA is enough to provide > > channel security, provide that the ciphertext is accepted for only > > once for a given key. (This may open doors to some DoS attack.) As far > > as I can tell, the NewHope and NTRU-prime all uses CPA secure > > encryption algorithms. > > Definitely true for NewHope. > > > Here's what my answers would be to your questions: > > > It would be nice to have a final decision on > > a. shall we use non-production form > > Would be interesting to see benchmarks of both. > > > b. shall we remove the IND-CCA-2 feature > > Again, it would be interesting in a larger context to have benchmarks of > both; the Tor handshake should be fine with IND-CPA. > > > c. shall we use ntru-743/887 to build a sufficiently large margin just > like > > NTRUprime > > Definitely. As I wrote in my previous mail, in NewHope we went for a > much larger margin than NTRUprime did; I would probably feel better with > 887, but for long-term security (and this is what the whole thing is > about), 743 is a must-have. > > > Cheers, > > Peter > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >

1 0

Re: [tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
by Zhenfei Zhang 26 May '16

26 May '16

Hi Peter, Thanks for such a nice overview of current discussions. Just want to give a quick update on the NTRU. > - NTRU is around for the longest time and has, even with high-security > parameters, fairly short messages. However, existing software > implementations (at least the ones in SUPERCOP) are highly vulnerable > to timing attacks. Key generation (with protection to against timing > attacks) is, as far as I can tell, fairly expensive. We are working on a constant-time implementation of NTRU. We expect to release the source code this summer. However, as far as I know, timing attacks are much more powerful against encryption algorithm (that uses long-lived key for multiple times), rather than KEMs (use ephemeral keys). Our proposal treats NTRU as a KEM so I think the timing attack is not so useful. > What I'm missing in the discussion are benchmarks of NTRU and NTRUprime (in > the context of key exchange). Please see the attached for some benchmark results. We are working on the camera-ready version of the paper. The final version should be out soon. Also note that we are using an IND-CCA-2 secure version of NTRU. The performance can be further improved by switching to the IND-CPA secure version. IND-CPA is enough to provide channel security, provide that the ciphertext is accepted for only once for a given key. (This may open doors to some DoS attack.) As far as I can tell, the NewHope and NTRU-prime all uses CPA secure encryption algorithms. > Would it help the discussion at this point to fix NTRU parameters, produce > an optimized implementation of NTRU (not production-quality code for Tor, but > something to obtain benchmarks) and compare performance of NewHope, NTRU, and > NTRUprime in an ephemeral key exchange? This would be a nice project for a > Ph.D. student. It would be very interesting indeed. We need to fix the parameter sets for NTRU. Currently we have 1. ntru-443 with product form, providing 128 pre-quantum/post-quantum security 2. ntru-743 with product form, providing 256 pre-quantum and >128 post-quantum security 3. ntru-887 with non-product form, providing 256 pre-quantum security And all of those parameter sets uses SHA256 rather than SHA-3 as suggested by the community. It would be nice to have a final decision on a. shall we use non-production form b. shall we remove the IND-CCA-2 feature c. shall we use ntru-743/887 to build a sufficiently large margin just like NTRUprime Cheers, Zhenfei On Tue, May 24, 2016 at 6:32 PM, Peter Schwabe <peter(a)cryptojedi.org> wrote: > bancfc(a)openmailbox.org wrote: > > Hi all, > > > Some great developments in lattice-based crypto. DJB just released a > paper > > on NTRU Prime: > > Let me just also throw in my 2 cents: > > As far as I can tell, there are now 5 approaches to post-quantum key > exchange that are discussed (or at least have surfaced) in this thread: > - NTRU > - NewHope > - NTRUprime > - McEliece > - SIDH > > In some of the posts I got the impression that there are considerations > for some sort of "algorithm agility" in the key exchange. This can mean > two things: > - runtime algorithm agility, such that a client can choose what > algorithm to use according to some strategy; or > - upgrading algorithm agility, which means that for each version number > of a client, it is very clear which algorithm it will use, but the key > exchange supports (easy) upgrading to better algorithms with > increasing version numbers. > > In my opinion, the second approach is extremely important, in particular > because at the moment we certainly want some sort of PQ key exchange, > but are quite uncertain about what approach will prove best in the long > run. > I'm not really sure whether anybody really suggested the first approach, > but just in case, I think it's a terrible idea. If the decision of what > algorithms to use is left to users, they will certainly end up making > worse choices than experts; if it's left to randomness, users inevitably > get the worst out of the set from time to time. I simply cannot think of > any strategy that lets the user win here. > > Now, out of the 5 proposals, my impression is that McEliece with binary > Goppa codes has been killed as an idea for key exchange in Tor and that > whenever somebody mentions it again, Isis will just shout "KEYSIZE" to > make sure that it remains dead. > > I can see good reasons for each of the first three (lattice-based) > proposals: > > - NTRU is around for the longest time and has, even with high-security > parameters, fairly short messages. However, existing software > implementations (at least the ones in SUPERCOP) are highly vulnerable > to timing attacks. Key generation (with protection to against timing > attacks) is, as far as I can tell, fairly expensive. > > - NewHope is explicitely designed for ephemeral key exchange (not > public-key encryption), i.e, for the operation that is required. It > offers best performance and, as Isis pointed out, the paramters we > propose have the largest security margin against all known attacks. > Disadvantage (price to pay for the security margin): somewhat longer > messages. > > - NTRUprime is much less conservative than NewHope in its parameter > choices against known attacks but offers "defenses" against attacks > that may or may not work against NewHope and NTRU. > The advertisement of those defenses is a pretty good job of the > marketing department: the wording suggests that NTRUprime is, at the > same bit-security level, at least as secure as NTRU or NewHope, but > then has those defenses as additional safeguards. This is not quite > true: NTRUprime operates in a different mathematical structure, which > may in the long run prove more secure, it may also prove less secure > and it could turn out that the "defenses" against hypothetical attacks > turn out to be weaknesses against other attacks. > Having said that, I really like the ideas of the NTRUprime paper and > much more often than not have Dan and Tanja been right with their > intuition for cryptographic design. > > What I'm missing in the discussion are benchmarks of NTRU and NTRUprime (in > the context of key exchange). For NTRUprime there is not even a proposal > for > ephemeral key exchange as needed in Tor; however, I assume that it's not > too > hard to replace NTRU operations (from the NTRU proposal) by NTRUprime > operations. Also (please correct me if I'm wrong), for NTRU it's not clear > what parameters to use and there is no optimized and timing-attack > protected > implementation. > Would it help the discussion at this point to fix NTRU parameters, produce > an optimized implementation of NTRU (not production-quality code for Tor, > but > something to obtain benchmarks) and compare performance of NewHope, NTRU, > and > NTRUprime in an ephemeral key exchange? This would be a nice project for a > Ph.D. student. > > > Now, then there is SIDH: I really like SIDH, not so much for the shorter > public keys (that's nice, but it's not like a difference of an order of > magnitude), but because of two other reasons: > 1.) It is a completely different approach and even if all > non-standard lattice crypto falls, SIDH may survive. > 2.) It's offering the same functionality as (EC)DH right now; both > parties can compute their public keys without having received the > public key of the other party. This is a great feature for protocol > design and for migrating existing DH-based protocols to a > post-quantum setting. > However, I don't think that SIDH is ready for use at the moment. The > reason is not only that it's about 300x slower than ECC, the reason is > that security is really not understood at all. While probably everybody > in the crypto community expects some progress in lattice attacks over > the next few decades, I don't think that anybody seriously expects a > polynomial-time algorithm that breaks, for example, Ring-LWE with > suitably chosen paramters. A polynomial-time algorithm to break SIDH > would clearly be a major breakthrough with an immediate-accept at any of > the big crypto venues, but I would not want to really bet anything > important (like my life in freedom) against this happening. > I talked to Michael Naehrig (co-author of the Crypto paper this year > implementing SIDH) two days ago and mentioned that SIDH popped up in > this discussion as a possible approach for Tor. His reaction was roughly > along the lines of "We say in our paper that you shouldn't use this, and > very certainly not in Tor". > > So, I hope that SIDH will survive in the long run, after serious > cryptanalytic effort trying to break it; I hope that it will become > faster by, say, a factor of 100 (that's not totally inconceivable, > pairings took minutes to compute at the beginning, now we're below a > millisecond) and if this happens then Tor should migrate to SIDH. Not > now. > > As I said, just my 2 cents. > > Cheers, > > Peter > > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > >

2 1

[proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
by isis 24 May '16

24 May '16

Hello, Peter (in CC) and I have recently composed a draft proposal for a new Tor handshake. It's a hybrid handshake combining Tor's current X25519-based NTor handshake with the NewHope lattice-based key exchange, in order to protect the secrecy of Tor connections today from an attacker with a quantum computer in the future. I have not given the proposal a number. It is available in my `drafts/newhope` branch of my torspec repository: https://gitweb.torproject.org/user/isis/torspec.git/tree/proposals/XXX-newh… For purposes of facilitating discussion, it is also included here inline. Review and comments are very appreciated. ______________________________________________________________________________ Filename: XXX-newhope-hybrid-handshake.txt Title: Post-Quantum Secure Hybrid Handshake Based on NewHope Author: Isis Lovecruft, Peter Schwabe Created: 16 Apr 2016 Updated: 4 May 2016 Status: Draft Depends: prop#220 prop#249 prop#264 §0. Introduction NewHope is a post-quantum-secure lattice-based key-exchange protocol based on the ring-learning-with-errors (Ring-LWE) problem. We propose a hybrid handshake for Tor, based on a combination of Tor's current NTor handshake and a shared key derived through a NewHope ephemeral key exchange. For further details on the NewHope key exchange, the reader is referred to "Post-quantum key exchange - a new hope" by Alkim, Ducas, Pöppelmann, and Schwabe [0][1]. For the purposes of brevity, we consider that NTor is currently the only handshake protocol in Tor; the older TAP protocol is ignored completely, due to the fact that it is currently deprecated and nearly entirely unused. §1. Motivation An attacker currently monitoring and storing circuit-layer NTor handshakes who later has the ability to run Shor's algorithm on a quantum computer will be able to break Tor's current handshake protocol and decrypt previous communications. It is unclear if and when such attackers equipped with large quantum computers will exist, but various estimates by researchers in quantum physics and quantum engineering give estimates of only 1 to 2 decades. Clearly, the security requirements of many Tor users include secrecy of their messages beyond this time span, which means that Tor needs to update the key exchange to protect against such attackers as soon as possible. §2. Design An initiator and responder, in parallel, conduct two handshakes: - An X25519 key exchange, as described in the description of the NTor handshake in Tor proposal #216. - A NewHope key exchange. The shared keys derived from these two handshakes are then concatenated and used as input to the SHAKE-256 extendable output function (XOF), as decribed in FIPS-PUB-202 [2], in order to produce a shared key of the desired length. The testvectors in §C assume that this key has a length of 32 bytes, but the use of a XOF allows arbitrary lengths to easily support future updates of the symmetric primitives using the key. See also §3.3.1. §3. Specification §3.1. Notation Let `a || b` be the concatenation of a with b. Let `a^b` denote the exponentiation of a to the bth power. Let `a == b` denote the equality of a with b, and vice versa. Let `a := b` be the assignment of the value of b to the variable a. Let `H(x)` be 32-bytes of output of the SHAKE-256 XOF (as described in FIPS-PUB-202) applied to message x. Let X25519 refer to the curve25519-based key agreement protocol described in RFC7748 §6.1. [3] Let `EXP(a, b) == X25519(., b, a)` with `g == 9`. Let X25519_KEYGEN() do the appropriate manipulations when generating the secret key (clearing the low bits, twidding the high bits). [XXX match RFC7748 notation more. --isis] Let `X25519_KEYID(B) == B` where B is a valid X25519 public key. When representing an element of the Curve25519 subgroup as a byte string, use the standard (32-byte, little-endian, x-coordinate-only) representation for Curve25519 points. Let `ID` be a router's identity key taken from the router microdescriptor. In the case for relays possessing Ed25519 identity keys (c.f. Tor proposal #220), this is a 32-byte string representing the public Ed25519 identity key. For backwards and forwards compatibility with routers which do not possess Ed25519 identity keys, this is a 32-byte string created via the output of H(ID). We refer to the router as the handshake "responder", and the client (which may be an OR or an OP) as the "initiator". ID_LENGTH [32 bytes] H_LENGTH [32 bytes] G_LENGTH [32 bytes] PROTOID := "pqtor-x25519-newhope-shake256-1" T_MAC := PROTOID || ":mac" T_KEY := PROTOID || ":key_extract" T_VERIFY := PROTOID || ":verify" (X25519_SK, X25519_PK) := X25519_KEYGEN() §3.2. Protocol ======================================================================================== | | | Fig. 1: The NewHope-X25519 Hybrid Handshake. | | | | Before the handshake the Initiator is assumed to know Z, a public X25519 key for | | the Responder, as well as the Responder's ID. | ---------------------------------------------------------------------------------------- | | | Initiator Responder | | | | SEED := H(randombytes(32)) | | x, X := X25519_KEYGEN() | | a, A := NEWHOPE_KEYGEN(SEED) | | CLIENT_HDATA := ID || Z || X || A | | | | --- CLIENT_HDATA ---> | | | | y, Y := X25519_KEYGEN() | | NTOR_KEY, AUTH := NTOR_SHAREDB(X,y,Y,z,Z,ID,B) | | M, NEWHOPE_KEY := NEWHOPE_SHAREDB(A) | | SERVER_HDATA := Y || AUTH || M | | sk := SHAKE-256(NTOR_KEY || NEWHOPE_KEY) | | | | <-- SERVER_HDATA ---- | | | | NTOR_KEY := NTOR_SHAREDA(x, X, Y, Z, ID, AUTH) | | NEWHOPE_KEY := NEWHOPE_SHAREDA(M, a) | | sk := SHAKE-256(NTOR_KEY, NEWHOPE_KEY) | | | ======================================================================================== §3.2.1. The NTor Handshake §3.2.1.1. Prologue Take a router with identity ID. As setup, the router generates a secret key z, and a public onion key Z with: z, Z := X25519_KEYGEN() The router publishes Z in its server descriptor in the "ntor-onion-key" entry. Henceforward, we refer to this router as the "responder". §3.2.1.2. Initiator To send a create cell, the initiator generates a keypair: x, X := X25519_KEYGEN() and creates the NTor portion of a CREATE2V cell's HDATA section: CLIENT_NTOR := ID || Z || X [96 bytes] The initiator includes the responder's ID and Z in the CLIENT_NTOR so that, in the event the responder OR has recently rotated keys, the responder can determine which keypair to use. The initiator then concatenates CLIENT_NTOR with CLIENT_NEWHOPE (see §3.2.2), to create CLIENT_HDATA, and creates and sends a CREATE2V cell (see §A.1) to the responder. CLIENT_NEWHOPE [1824 bytes] (see §3.2.2) CLIENT_HDATA := CLIENT_NTOR || CLIENT_NEWHOPE [1920 bytes] If the responder does not respond with a CREATED2V cell, the initiator SHOULD NOT attempt to extend the circuit through the responder by sending fragmented EXTEND2 cells, since the responder's lack of support for CREATE2V cells is assumed to imply the responder also lacks support for fragmented EXTEND2 cells. Alternatively, for initiators with a sufficiently late consensus method, the initiator MUST check that "proto" line in the responder's descriptor (c.f. Tor proposal #264) advertises support for the "Relay" subprotocol version 3 (see §5). §3.2.1.3. Responder The responder generates a keypair of y, Y = X25519_KEYGEN(), and does NTOR_SHAREDB() as follows: (NTOR_KEY, AUTH) ← NTOR_SHAREDB(X, y, Y, z, Z, ID, B): secret_input := EXP(X, y) || EXP(X, z) || ID || B || Z || Y || PROTOID NTOR_KEY := H(secret_input, T_KEY) verify := H(secret_input, T_VERIFY) auth_input := verify || ID || Z || Y || X || PROTOID || "Server" AUTH := H(auth_input, T_MAC) The responder sends a CREATED2V cell containing: SERVER_NTOR := Y || AUTH [64 bytes] SERVER_NEWHOPE [2048 bytes] (see §3.2.2) SERVER_HDATA := SERVER_NTOR || SERVER_NEWHOPE [2112 bytes] and sends this to the initiator. §3.2.1.4. Finalisation The initiator then checks Y is in G^* [see NOTE below], and does NTOR_SHAREDA() as follows: (NTOR_KEY) ← NTOR_SHAREDA(x, X, Y, Z, ID, AUTH) secret_input := EXP(Y, x) || EXP(Z, x) || ID || Z || X || Y || PROTOID NTOR_KEY := H(secret_input, T_KEY) verify := H(secret_input, T_VERIFY) auth_input := verify || ID || Z || Y || X || PROTOID || "Server" if AUTH == H(auth_input, T_MAC) return NTOR_KEY Both parties check that none of the EXP() operations produced the point at infinity. [NOTE: This is an adequate replacement for checking Y for group membership, if the group is Curve25519.] [XXX: This doesn't sound exactly right. You need the scalar tweaking of X25519 for this to work and also, the point at infinity is obviously an element of the group --isis, peter] Both parties now have a shared value for NTOR_KEY. They expand this into the keys needed for the Tor relay protocol. [XXX We think we want to omit the final hashing in the production of NTOR_KEY here, and instead put all the inputs through SHAKE-256. --isis, peter] [XXX We probably want to remove ID and B from the input to the shared key material, since they serve for authentication but, as pre-established "prologue" material to the handshake, they should not be used in attempts to strengthen the cryptographic suitability of the shared key. Also, their inclusion is implicit in the DH exponentiations. I should probably ask Ian about the reasoning for the original design choice. --isis] §3.2.2. The NewHope Handshake §3.2.2.1. Parameters & Mathematical Structures Let ℤ be the ring of rational integers. Let ℤq, for q ≥ 1, denote the quotient ring ℤ/qℤ. We define R = ℤ[X]/((X^n)+1) as the ring of integer polynomials modulo ((X^n)+1), and Rq = ℤq[X]/((X^n)+1) as the ring of integer polynomials modulo ((X^n)+1) where each coefficient is reduced modulo q. When we refer to a polynomial, we mean an element of Rq. n := 1024 q := 12289 SEED [32 Bytes] NEWHOPE_POLY [1792 Bytes] NEWHOPE_REC [256 Bytes] NEWHOPE_KEY [32 Bytes] NEWHOPE_MSGA := (NEWHOPE_POLY || SEED) NEWHOPE_MSGB := (NEWHOPE_POLY || NEWHOPE_REC) §3.2.2.2. High-level Description of Newhope API Functions For a description of internal functions, see §B. (NEWHOPE_POLY, NEWHOPE_MSGA) ← NEWHOPE_KEYGEN(SEED): â := gen_a(seed) s := poly_getnoise() e := poly_getnoise() ŝ := poly_ntt(s) ê := poly_ntt(e) b̂ := pointwise(â, ŝ) + ê sp := poly_tobytes(ŝ) bp := poly_tobytes(b̂) return (sp, (bp || seed)) (NEWHOPE_MSGB, NEWHOPE_KEY) ← NEWHOPE_SHAREDB(NEWHOPE_MSGA): s' := poly_getnoise() e' := poly_getnoise() e" := poly_getnoise() b̂ := poly_frombytes(bp) â := gen_a(seed) ŝ' := poly_ntt(s') ê' := poly_ntt(e') û := poly_pointwise(â, ŝ') + ê' v := poly_invntt(poly_pointwise(b̂,ŝ')) + e" r := helprec(v) up := poly_tobytes(û) k := rec(v, r) return ((up || r), k) NEWHOPE_KEY ← NEWHOPE_SHAREDA(NEWHOPE_MSGB, NEWHOPE_POLY): û := poly_frombytes(up) ŝ := poly_frombytes(sp) v' := poly_invntt(poly_pointwise(û, ŝ)) k := rec(v', r) return k When a client uses a SEED within a CREATE2V cell, the client SHOULD NOT use that SEED in any other CREATE2V or EXTEND2 cells. See §4 for further discussion. §3.3. Key Expansion The client and server derive a shared key, SHARED, by: HKDFID := "THESE ARENT THE DROIDS YOURE LOOKING FOR" SHARED := SHAKE_256(HKDFID || NTorKey || NewHopeKey) §3.3.1. Note on the Design Choice The reader may wonder why one would use SHAKE-256 to produce a 256-bit output, since the security strength in bits for SHAKE-256 is min(d/2,256) for collision resistance and min(d,256) for first- and second-order preimages, where d is the output length. The reasoning is that we should be aiming for 256-bit security for all of our symmetric cryptography. One could then argue that we should just use SHA3-256 for the KDF. We choose SHAKE-256 instead in order to provide an easy way to derive longer shared secrets in the future without requiring a new handshake. The construction is odd, but the future is bright. As we are already using SHAKE-256 for the 32-byte output hash, we are also using it for all other 32-byte hashes involved in the protocol. Note that the only difference between SHA3-256 and SHAKE-256 with 32-byte output is one domain-separation byte. [XXX why would you want 256-bit security for the symmetric side? Are you talking pre- or post-quantum security? --peter] §4. Security & Anonymity Implications This handshake protocol is one-way authenticated. That is, the server is authenticated, while the client remains anonymous. The client MUST NOT cache and reuse SEED. Doing so gives non-trivial adversarial advantages w.r.t. all-for-the-price-of-one attacks during the caching period. More importantly, if the SEED used to generate NEWHOPE_MSGA is reused for handshakes along the same circuit or multiple different circuits, an adversary conducting a sybil attack somewhere along the path(s) will be able to correlate the identity of the client across circuits or hops. §5. Compatibility Because our proposal requires both the client and server to send more than the 505 bytes possible within a CREATE2 cell's HDATA section, it depends upon the implementation of a mechanism for allowing larger CREATE cells (c.f. Tor proposal #249). We reserve the following handshake type for use in CREATE2V/CREATED2V and EXTEND2V/EXTENDED2V cells: 0x0003 [NEWHOPE + X25519 HYBRID HANDSHAKE] We introduce a new sub-protocol number, "Relay=3", (c.f. Tor proposal #264 §5.3) to signify support this handshake, and hence for the CREATE2V and fragmented EXTEND2 cells which it requires. There are no additional entries or changes required within either router descriptors or microdescriptors to support this handshake method, due to the NewHope keys being ephemeral and derived on-the-fly, and due to the NTor X25519 public keys already being in included within the "ntor-onion-key" entry. Add a "UseNewHopeKEX" configuration option and a corresponding consensus parameter to control whether clients prefer using this NewHope hybrid handshake or some previous handshake protocol. If the configuration option is "auto", clients SHOULD obey the consensus parameter. The default configuration SHOULD be "auto" and the consensus value SHOULD initially be "0". §6. Implementation The paper by Alkim, Ducas, Pöppelmann and Schwabe describes two software implementations of NewHope, one C reference implementation and an optimized implementation using AVX2 vector instructions. Those implementations are available at [1]. Additionally, there are implementations in Go by Yawning Angel, available from [4] and in Rust by Isis Lovecruft, available from [5]. The software used to generate the test vectors in §C is based on the C reference implementation and available from: https://code.ciph.re/isis/newhope-tor-testvectors https://github.com/isislovecruft/newhope-tor-testvectors §7. Performance & Scalability The computationally expensive part in the current NTor handshake is the X25519 key-pair generation and the X25519 shared-key computation. The current implementation in Tor is a wrapper to support various highly optimized implementations on different architectures. On Intel Haswell processors, the fastest implementation of X25519, as reported by the eBACS benchmarking project [6], takes 169920 cycles for key-pair generation and 161648 cycles for shared-key computation; these add up to a total of 331568 cycles on each side (initiator and responder). The C reference implementation of NewHope, also benchmarked on Intel Haswell, takes 358234 cycles for the initiator and 402058 cycles for the Responder. The core computation of the proposed combination of NewHope and X25519 will thus mean a slowdown of about a factor of 2.1 for the Initiator and a slowdown by a factor of 2.2 for the Responder compared to the current NTor handshake. These numbers assume a fully optimized implementation of the NTor handshake and a C reference implementation of NewHope. With optimized implementations of NewHope, such as the one for Intel Haswell described in [0], the computational slowdown will be considerably smaller than a factor of 2. §8. References [0]: https://cryptojedi.org/papers/newhope-20160328.pdf [1]: https://cryptojedi.org/crypto/#newhope [2]: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=919061 [3]: https://tools.ietf.org/html/rfc7748#section-6.1 [4]: https://github.com/Yawning/newhope [5]: https://code.ciph.re/isis/newhopers [6]: http://bench.cr.yp.to §A. Cell Formats §A.1. CREATE2V Cells The client portion of the handshake should send CLIENT_HDATA, formatted into a CREATE2V cell as follows: CREATE2V { [2114 bytes] HTYPE := 0x0003 [2 bytes] HLEN := 0x0780 [2 bytes] HDATA := CLIENT_HDATA [1920 bytes] IGNORED := 0x00 [194 bytes] } [XXX do we really want to pad with IGNORED to make CLIENT_HDATA the same number of bytes as SERVER_HDATA? --isis] §A.2. CREATED2V Cells The server responds to the client's CREATE2V cell with SERVER_HDATA, formatted into a CREATED2V cell as follows: CREATED2V { [2114 bytes] HLEN := 0x0800 [2 bytes] HDATA := SERVER_HDATA [2112 bytes] IGNORED := 0x00 [0 bytes] } §A.3. Fragmented EXTEND2 Cells When the client wishes to extend a circuit, the client should fragment CLIENT_HDATA into four EXTEND2 cells: EXTEND2 { NSPEC := 0x02 { [1 byte] LINK_ID_SERVER [22 bytes] XXX LINK_ADDRESS_SERVER [8 bytes] XXX } HTYPE := 0x0003 [2 bytes] HLEN := 0x0780 [2 bytes] HDATA := CLIENT_HDATA[0,461] [462 bytes] } EXTEND2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := CLIENT_HDATA[462,954] [492 bytes] } EXTEND2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := CLIENT_HDATA[955,1447] [492 bytes] } EXTEND2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := CLIENT_HDATA[1448,1919] || 0x00[20] [492 bytes] } EXTEND2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := 0x00[172] [172 bytes] } The client sends this to the server to extend the circuit from, and that server should format the fragmented EXTEND2 cells into a CREATE2V cell, as described in §A.1. §A.4. Fragmented EXTENDED2 Cells EXTENDED2 { NSPEC := 0x02 { [1 byte] LINK_ID_SERVER [22 bytes] XXX LINK_ADDRESS_SERVER [8 bytes] XXX } HTYPE := 0x0003 [2 bytes] HLEN := 0x0800 [2 bytes] HDATA := SERVER_HDATA[0,461] [462 bytes] } EXTENDED2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := SERVER_HDATA[462,954] [492 bytes] } EXTEND2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := SERVER_HDATA[955,1447] [492 bytes] } EXTEND2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := SERVER_HDATA[1448,1939] [492 bytes] } EXTEND2 { NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] HDATA := SERVER_HDATA[1940,2112] [172 bytes] } §B. NewHope Internal Functions gen_a(SEED): returns a uniformly random poly poly_getnoise(): returns a poly sampled from a centered binomial poly_ntt(poly): number-theoretic transform; returns a poly poly_invntt(poly): inverse number-theoretic transform; returns a poly poly_pointwise(poly, poly): pointwise multiplication; returns a poly poly_tobytes(poly): packs a poly to a NEWHOPE_POLY byte array poly_frombytes(NEWHOPE_POLY): unpacks a NEWHOPE_POLY byte array to a poly helprec(poly): returns a NEWHOPE_REC byte array rec(poly, NEWHOPE_REC): returns a NEWHOPE_KEY --- Description of the Newhope internal functions --- gen_a(SEED seed) receives as input a 32-byte (public) seed. It expands this seed through SHAKE-128 from the FIPS202 standard. The output of SHAKE-128 is considered a sequence of 16-bit little-endian integers. This sequence is used to initialize the coefficients of the returned polynomial from the least significant (coefficient of X^0) to the most significant (coefficient of X^1023) coefficient. For each of the 16-bit integers first eliminate the highest two bits (to make it a 14-bit integer) and then use it as the next coefficient if it is smaller than q=12289. Note that the amount of output required from SHAKE to initialize all 1024 coefficients of the polynomial varies depending on the input seed. Note further that this function does not process any secret data and thus does not need any timing-attack protection. poly_getnoise() first generates 4096 Bytes of uniformly random data. This can be done by reading these bytes from the system's RNG; efficient implementations will typically only read a 32-byte seed from the system's RNG and expand it through some fast PRNG (for example, ChaCha20 or AES-256 in CTR mode). The output of the PRG is considered an array of 2048 16-bit integers r[0],...,r[2047]. The coefficients of the output polynomial are computed as HW(r[0])-HW(r[1]), HW(r[2])-HW(r[3]),...,HW(r[2046])-HW(r[2047]), where HW stands for Hamming weight. Note that the choice of RNG is a local decision; different implementations are free to use different RNGs. Note further that the output of this function is secret; the PRG (and the computation of HW) need to be protected against timing attacks. poly_ntt(poly f): For a mathematical description of poly_ntt see the [0]; a pseudocode description of a very naive inplace transformation of an input polynomial f = f[0] + f[1]*X + f[2]*X^2 + ... + f[1023]*X^1023 is the following code (all arithmetic on coefficients performed modulo q): psi = 7 omega = 49 for i in range(0,n): t[i] = f[i] * psi^i for i in range(0,n): f[i] = 0 for j in range(0,n): f[i] += t[j] * omega^((i*j)%n) Note that this is not how poly_ntt should be implemented if performance is an issue; in particular, efficient algorithms for the number-theoretic transform take time O(n*log(n)) and not O(n^2) Note further that all arithmetic in poly_ntt has to be protected against timing attacks. poly_invntt(poly f): For a mathematical description of poly_invntt see the [0]; a pseudocode description of a very naive inplace transformation of an input polynomial f = f[0] + f[1]*X + f[2]*X^2 + ... + f[1023]*X^1023 is the following code (all arithmetic on coefficients performed modulo q): invpsi = 8778; invomega = 1254; invn = 12277; for i in range(0,n): t[i] = f[i]; for i in range(0,n): f[i]=0; for j in range(0,n): f[i] += t[j] * invomega^((i*j)%n) f[i] *= invpsi^i f[i] *= invn Note that this is not how poly_invntt should be implemented if performance is an issue; in particular, efficient algorithms for the inverse number-theoretic transform take time O(n*log(n)) and not O(n^2) Note further that all arithmetic in poly_invntt has to be protected against timing attacks. poly_pointwise(poly f, poly g) performs pointwise multiplication of the two polynomials. This means that for f = (f0 + f1*X + f2*X^2 + ... + f1023*X^1023) and g = (g0 + g1*X + g2*X^2 + ... + g1023*X^1023) it computes and returns h = (h0 + h1*X + h2*X^2 + ... + h1023*X^1023) with h0 = f0*g0, h1 = f1*g1,..., h1023 = f1023*g1023. poly_tobytes(poly f) first reduces all coefficents of f modulo q, i.e., brings them to the interval [0,q-1]. Denote these reduced coefficients as f0,..., f1023; note that they all fit into 14 bits. The function then packs those coefficients into an array of 1792 bytes r[0],..., r[1792] in "packed little-endian representation", i.e., r[0] = f[0] & 0xff; r[1] = (f[0] >> 8) & ((f[1] & 0x03) << 6) r[2] = (f[1] >> 2) & 0xff; r[3] = (f[1] >> 10) & ((f[2] & 0x0f) << 4) . . . r[1790] = (f[1022]) >> 12) & ((f[1023] & 0x3f) << 2) r[1791] = f[1023] >> 6 Note that this function needs to be protected against timing attacks. In particular, avoid non-constant-time conditional subtractions (or other non-constant-time expressions) in the reduction modulo q of the coefficients. poly_frombytes(NEWHOPE_POLY b) is the inverse of poly_tobytes; it receives as input an array of 1792 bytes and coverts it into the internal representation of a poly. Note that poly_frombytes does not need to check whether the coefficients are reduced modulo q or reduce coefficients modulo q. Note further that the function must not leak any information about its inputs through timing information, as it is also applied to the secret key of the initiator. helprec(poly f) computes 256 bytes of reconciliation information from the input poly f. Internally, one byte of reconciliation information is computed from four coefficients of f by a function helprec4. Let the input polynomial f = (f0 + f1*X + f2*X^2 + ... + f1023*X^1023); let the output byte array be r[0],...r[256]. This output byte array is computed as r[0] = helprec4(f0,f256,f512,f768) r[1] = helprec4(f1,f257,f513,f769) r[2] = helprec4(f2,f258,f514,f770) . . . r[255] = helprec4(f255,f511,f767,f1023), where helprec4 does the following: helprec4(x0,x1,x2,x3): b = randombit() r0,r1,r2,r3 = CVPD4(8*x0+4*b,8*x1+4*b,8*x2+4*b,8*x3+4*b) r = (r0 & 0x03) | ((r1 & 0x03) << 2) | ((r2 & 0x03) << 4) | ((r3 & 0x03) << 6) return r The function CVPD4 does the following: CVPD4(y0,y1,y2,y3): v00 = round(y0/2q) v01 = round(y1/2q) v02 = round(y2/2q) v03 = round(y3/2q) v10 = round((y0-1)/2q) v11 = round((y1-1)/2q) v12 = round((y2-1)/2q) v13 = round((y3-1)/2q) t = abs(y0 - 2q*v00) t += abs(y1 - 2q*v01) t += abs(y2 - 2q*v02) t += abs(y3 - 2q*v03) if(t < 2q): v0 = v00 v1 = v01 v2 = v02 v3 = v03 k = 0 else v0 = v10 v1 = v11 v2 = v12 v3 = v13 r = 1 return (v0-v3,v1-v3,v2-v3,k+2*v3) In this description, round() returns the closest integer and abs() returns the absolute value. Note that all computations involved in helprec operate on secret data and must be protected against timing attacks. rec(poly f, NEWHOPE_REC r) computes the pre-hash (see paper) Newhope key from f and r. Specifically, it computes one bit of key from 4 coefficients of f and one byte of r. Let f = f0 + f1*X + f2*X^2 + ... + f1023*X^1023 and let r = r[0],r[1],...,r[255]. Let the bytes of the output by k[0],...,k[31] and let the bits of the output by k0,...,k255, where k0 = k[0] & 0x01 k1 = (k[0] >> 1) & 0x01 k2 = (k[0] >> 2) & 0x01 . . . k8 = k[1] & 0x01 k9 = (k[1] >> 1) & 0x01 . . . k255 = (k[32] >> 7) The function rec computes k0,...,k255 as k0 = rec4(f0,f256,f512,f768,r[0]) k1 = rec4(f1,f257,f513,f769,r[1]) . . . k255 = rec4(f255,f511,f767,f1023,r[255]) The function rec4 does the following: rec4(y0,y1,y2,y3,r): r0 = r & 0x03 r1 = (r >> 2) & 0x03 r2 = (r >> 4) & 0x03 r3 = (r >> 6) & 0x03 Decode(8*y0-2q*r0, 8*y1-2q*r1, 8*y2-2q*r2, 8*y3-q*r3) The function Decode does the following: Decode(v0,v1,v2,v3): t0 = round(v0/8q) t1 = round(v1/8q) t2 = round(v2/8q) t3 = round(v3/8q) t = abs(v0 - 8q*t0) t += abs(v0 - 8q*t0) t += abs(v0 - 8q*t0) t += abs(v0 - 8q*t0) if(t > 1) return 1 else return 0 §C. Test Vectors ______________________________________________________________________________ Best Regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

11 49

estimating traffic/bandwidth needed to run a Tor node
by Razvan Dragomirescu 24 May '16

24 May '16

Hello everyone, I'm working on an Internet of Things project and Tor will be a part of it (Hidden Services to be more precise). The nodes however may be battery powered or have slow (or metered) Internet connectivity, so I'm trying to estimate the traffic patterns for a fully functional Tor node. Has this been measured at all? I mean how much traffic should I expect per hour/day/month whatever in order to maintain a good "Tor citizen" node, serving a very low traffic hidden service? I do remember reading something about it needing 4MB per day or something like that, but I can't seem to find that link or page anywhere now... :(. Any hints on where to find this type of info (or maybe how to measure it myself) would be appreciated. Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

3 3

Re: [tor-dev] Onioncat and Prop224
by str4d 22 May '16

22 May '16

On 20/05/16 18:23, grarpamp wrote: > On 4/30/16, str4d <str4d(a)i2pmail.org> wrote: >> On 27/04/16 22:31, grarpamp wrote: >>> I think there are a nontrivial number of users interested in, and >>> using, non-strictly-TCP transport over an IPv6 tunnel interface. >>> For example, look at users of CJDNS... >>> >>> For which we should try to continue a way, in v2, to do that over >>> anonymous overlay network Tor / I2P. >>> >> >> There is already some work on doing this in I2P: >> >> https://github.com/majestrate/i2p-tools/tree/master/i2tun >> https://github.com/majestrate/i2p-tools/tree/master/pyi2tun >> >> I2P also natively supports non-TCP protocols if that helps (only >> datagrams implemented thus far). > > You mean just UDP? How would you move ICMP, GRE, raw IP/packets? > Do you have to implement each one? I mean that I2P has a numbered protocol system (like IP protocol numbers). Currently we only have three protocols defined: streaming (our TCP-like protocol), repliable datagrams (our UDP-like protocol) and non-repliable/raw datagrams (c/f raw sockets). Our higher-level APIs map clearnet TCP data onto streaming, and clearnet UDP data onto repliable datagrams. > That seems more work > than implementing a generic data conduit, or an IPv6 conduit (as > a more specific, host stack oriented, interoperable form). > Though yes UDP would be the most useful for people after TCP. It is relatively easy to use repliable or raw datagrams as a conduit for any other protocol. That's how i2tun is implemented. str4d

1 0

Memory usage of Tor daemon
by Rob van der Hoeven 21 May '16

21 May '16

Hi, I'm running Tor on a router and was wondering why the Tor daemon uses so much memory. Did a pmap: pmap `pidof tor` And got the following result: 1703: /usr/sbin/tor --PidFile /var/run/tor.pid 00400000 1024K r-x-- /usr/sbin/tor 0050f000 4K r---- /usr/sbin/tor 00510000 20K rw--- /usr/sbin/tor 00515000 12K rwx-- [ anon ] 00ae9000 36K rwx-- [ anon ] 00af2000 17288K rwx-- [ anon ] 7713a000 7140K r---- /tmp/lib/tor/cached-microdescs 77833000 516K rw--- [ anon ] 778f5000 348K r-x-- /lib/libuClibc-0.9.33.2.so 7794c000 60K ----- [ anon ] 7795b000 4K r---- /lib/libuClibc-0.9.33.2.so 7795c000 4K rw--- /lib/libuClibc-0.9.33.2.so 7795d000 20K rw--- [ anon ] 77962000 80K r-x-- /lib/libgcc_s.so.1 77976000 60K ----- [ anon ] 77985000 4K rw--- /lib/libgcc_s.so.1 77986000 12K r-x-- /lib/libdl-0.9.33.2.so 77989000 60K ----- [ anon ] 77998000 4K r---- /lib/libdl-0.9.33.2.so 77999000 4K rw--- /lib/libdl-0.9.33.2.so 7799a000 76K r-x-- /lib/libpthread-0.9.33.2.so 779ad000 60K ----- [ anon ] 779bc000 4K r---- /lib/libpthread-0.9.33.2.so 779bd000 4K rw--- /lib/libpthread-0.9.33.2.so 779be000 8K rw--- [ anon ] 779c0000 1300K r-x-- /usr/lib/libcrypto.so.1.0.0 77b05000 64K ----- [ anon ] 77b15000 72K rw--- /usr/lib/libcrypto.so.1.0.0 77b27000 4K rw--- [ anon ] 77b28000 292K r-x-- /usr/lib/libssl.so.1.0.0 77b71000 60K ----- [ anon ] 77b80000 20K rw--- /usr/lib/libssl.so.1.0.0 77b85000 176K r-x-- /usr/lib/libevent-2.0.so.5.1.9 77bb1000 64K ----- [ anon ] 77bc1000 4K rw--- /usr/lib/libevent-2.0.so.5.1.9 77bc2000 88K r-x-- /lib/libm-0.9.33.2.so 77bd8000 60K ----- [ anon ] 77be7000 4K rw--- /lib/libm-0.9.33.2.so 77be8000 56K r-x-- /usr/lib/libz.so.1.2.8 77bf6000 60K ----- [ anon ] 77c05000 4K rw--- /usr/lib/libz.so.1.2.8 77c06000 28K r-x-- /lib/ld-uClibc-0.9.33.2.so 77c1a000 8K rw--- [ anon ] 77c1c000 4K r---- /lib/ld-uClibc-0.9.33.2.so 77c1d000 4K rw--- /lib/ld-uClibc-0.9.33.2.so 7f9a0000 132K rw--- [ stack ] 7fff7000 4K r-x-- [ anon ] total 29360K As you can see there is a large 17288K block which turns out to be a heap (of course). When I dumped the block and looked inside I found it was full of router data. Looks like it is mostly an in-memory database of the router list. This worries me. If in the future the router list grows, my router (and many other routers running Tor) can run out of memory. For me, it looks a little bit strange to have an in-memory database of the router list. Is there a reason for having this data in memory? And, can something be done about it? Rob. https://hoevenstein.nl

3 6

[GSoC] Tails Server - status report 2
by segfault 20 May '16

20 May '16

Hi everyone, this is the second status report on the Tails Server GSoC project. In the last two weeks I worked on these things: * Discussing the design of the GUI on the Tails-UX mailing list. I sent the last prototype of the GUI two weeks ago and we have been discussing it since. * Write a specification proposal for the service API [1] * Continue implementation of the GUI. I restructured the project and implemented some more features like monitoring the service's status via systemd manager. Next I plan to get a fully functional prototype of the GUI, to be able to conduct first user tests. This also requires some more features of the CLI. I also plan to discuss the service specification. Cheers! [1] https://tails.boum.org/blueprint/tails_server/#index4h1

1 0

Work in tor messenger
by AKASH DAS 18 May '16

18 May '16

Sir, I want to work in tor messenger and want to know what all I have to do to get in the flow of the work. Any help would be very helpful. Regards, Akash Das IIIT-Sricity

2 1

Re: [tor-dev] tor-dev Digest, Vol 64, Issue 26
by AKASH DAS 17 May '16

17 May '16

hello all, I am an aspirant for gsoc 2017 studying cse in IIIT-Sricity and i want to contribute to this community..can i get some help to start/cope up with the work that is going on.. Regards, Akash Das IIIT-Sricity On Tue, May 17, 2016 at 5:30 PM, <tor-dev-request(a)lists.torproject.org> wrote: > 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: onionoo.tpo stuck at 2016-05-13 12:00 (Karsten Loesing) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 17 May 2016 10:57:45 +0200 > From: Karsten Loesing <karsten(a)torproject.org> > To: nusenu <nusenu(a)openmailbox.org> > Cc: "tor-dev(a)lists.torproject.org" <tor-dev(a)lists.torproject.org> > Subject: Re: [tor-dev] onionoo.tpo stuck at 2016-05-13 12:00 > Message-ID: <573ADD09.1020104(a)torproject.org> > Content-Type: text/plain; charset=utf-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 14/05/16 12:00, nusenu wrote: > > Hi Karsten, > > Hi Nusenu, > > > I was surprised that ornetradar did not send a single email for > > yesterday's new relays. > > > > After looking into it, it turned out it is an onionoo problem. > > > > "relays_published":"2016-05-13 12:00:00" > > > > https://onionoo.torproject.org/details?limit=4 > > It looks like the Onionoo host has some serious load problems (again). > It's at "relays_published":"2016-05-16 19:00:00" now, so it didn't > stop entirely, but it's still behind. I just kicked it, maybe it'll > catch up in the next few hours. > > As a short-term fix, feel free to switch to the Onionoo mirror: > > https://onionoo.thecthulhu.com/summary?limit=0 > > As a medium-term fix, extend your client to fetch both headers > (/summary?limit=0) and get the full details from the host with more > recent "relays_published" line. > > As a long-term fix we should fix most/all inconsistencies between > Onionoo instances (different encodings and other minor problems) and > add a hostname that round-robins requests to all available mirrors. > > > regards, nusenu > > Thanks for letting me know! > > All the best, > Karsten > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJXOt0JAAoJEC3ESO/4X7XBLqIH/RYSZrlcKE3+Z9tx0dvdeYRN > OTvwX632AGnfn8Ej2x9mGzf12Qkv3ED6Of979z5Zu02uCgTpOfgKy8MxxjnW0qDu > oWvAw1OeO0T+kw+tD5IbjKhqDX0dYgNzoiYS2W/SwkR+OmGEX1i5/nVZm/M7hJFo > VWikP0th4ajVhIRwTEILjuMK3DS6UruHYYX7gCrLdvYOC3R11h3AXOWBgbblT8wz > x0jPKmNiOSWSKdpPCD5DHQbHaifNWMTqvZEqURhDpSKpfqUDZ82i7b/rG5bXlYZM > KdjMUdF0e5NIxzKhg0rQkaJFAeSdgXhj++yqJdGfNXYgtu4QDccTCaKdQKb67gs= > =AmcN > -----END PGP SIGNATURE----- > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > ------------------------------ > > End of tor-dev Digest, Vol 64, Issue 26 > *************************************** >

2 1

Exitmap's control flow
by Philipp Winter 17 May '16

17 May '16

Hi Mridul, I'm copying tor-dev@, so other folks can chime in. On Thu, May 12, 2016 at 10:16:45AM +0530, Mridul Malpotra wrote: > a) Can you give me a short description about the program flow on how the > EventHandler class enables modules to be executed in exitmap? From my > initial pondering over the code, the circuits seem to be created in > succession. Then for each circuit creation, the listener catches the event > and starts by calling module_closure for invoking probe() function specific > to each module. However, I am having trouble understanding the role of the > command utility and IPC queue, for which I can see a separate queue having > the exit_fingerprint and socket pairs but fail to comprehend how it is > being used. Like you said, circuits are created sequentially in exitmap.py:419. We have configurable inter-circuit delay (exitmap.py:442) to reduce the load on the Tor network. Before exitmap asks Stem to create circuits, it registers event listeners for all circuit and stream events (exitmap.py:371). So whenever Tor tells Stem that a circuit or stream has changed, Stem notifies exitmap. We only care about a subset of all circuit and stream events, though. All the event code is in eventhandler.py. Once Tor managed to create a new circuit, it tells Stem, which tells exitmap. We catch this event in the new_circuit() function (eventhandler.py:254). Now here's where the command utility come in. Exitmap modules can do one of two things. They can either use pure Python to do their scan (e.g., by using httplib to fetch a web site), or use an external tool and parse its output (e.g., by running the openssl command line tool). For the first case, we offer the function run_python_over_tor() (command.py:37). It basically monkey-patches Python's socket.socket and makes it go over Tor. External programs are a little bit more tricky, and handled by the Command object (command.py:58). We will have multiple instances of our command line tool running at the same time, and they all connect to Tor's SOCKS port. Exitmap then maps a stream (e.g., whatever openssl does) to a circuit. But how does exitmap know which one among the, say, 10 streams belongs to a given circuit? If we don't attach them correctly, we can still detect MitM attacks, but we will get the alert for the wrong exit relay. To correctly attach streams to circuits, exitmap modules remember the source port of the command line tool and hand it back to exitmap (note that a module runs in a different process than exitmap) over the queue. We can get the source port by parsing the output of torsocks. However, the current version of torsocks does not implement this yet. > b) For calculating all possible exits and creating circuits, > ServerDescriptors is set to 0 probably to avoid conflict with changed > consensus data in the middle of module execution. Also, for each module run > in the same execution, the original consensus downloaded during > bootstrapping Tor is being used. In my use case however, which involves > long duration scanning, we will need to update the cached-consensus after > some iterations. One way I think this can be made possible is by having an > asynchronous task that updates the consensus after say, an hour or so. > Conflicts could be avoided mid-module execution by either stalling > execution if near the DA consensus time period or use the old > cached-consensus. I would like to ask you whether my conclusion is correct > and if so, what other ways can I explore? Yes, that sounds reasonable to me. In fact, we might as well periodically download server descriptors instead of consensuses, so we can also scan relays that don't have the Exit flag, but have an exit policy. The consensus does not necessarily tell us what a relay's exit policy looks like. For more information, see: <https://github.com/NullHypothesis/exitmap/issues/13> > c) In exitmap, we are taking in the analysis_dir parameter in the command > line and storing it in a global variable in util.py. However, nowhere is > the dump_to_file function [1] being called to report on bad exits. What was > the working that was thought of behind this function? Was exitmap to dump > the log entries in files inside the analysis_dir for every false negative? > Can't seem to find code where the function is called. dump_to_file() is only used in modules, and not by exitmap itself. You certainly have a point here; the way exitmap logs stuff is inconsistent because it's entirely module-driven. Seems worthy of some improvements. I hope that clears things up a bit. Let me know if you want me to elaborate on something. Cheers, Philipp

1 0

Request for feedback/victims: cfc-0.0.2
by Yawning Angel 16 May '16

16 May '16

Hello, Thanks for the feedback so far. [ PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL STILL SHOULD NOT USE THIS. ] New version with changes some that add functionality, some code of quality stuff, hence a version bump to 0.0.2, especially since it'll probably be a bit before I can focus on tackling the TODO items. Source: https://git.schwanenlied.me/yawning/cfc XPI: https://people.torproject.org/~yawning/volatile/cfc-20160327/ Major changes: * Properly deregister the HTTP event listeners on addon unload. * Toned down the snark when I rewrite the CloudFlare captcha page, since I wasn't very nice. * Additional quality of life/privacy improvements courtesy of Will Scott, both optional and enabled by default. * (QoL) Skip useless landing pages (github.com/twitter.com will be auto-redirected to the "search" pages). * (Privacy) Kill twitter's outbound link tracking (t.co URLs) by rewriting the DOM to go to the actual URL when possible. Since DOM changes made from content scripts are isolated from page scripts, this shouldn't substantially alter behavior. * (Code quality) Use a pref listener to handle preference changes. TODO: * Try to figure out a way to mitigate the ability for archive.is to track you. The IFRAME based approach might work here, needs more investigation. * Handle custom CloudFlare captcha pages (In general my philosophy is to minimize false positives, over avoiding false negatives). Looking at the regexes in dcf's post, disabling the title check may be all that's needed. * Handle CloudFlare 503 pages. * Get samples of other common blanket CDN based Tor blocking/major sites that block Tor, and implement bypass methods similar to how CloudFlare is handled. * Look into adding a "contact site owner" button as suggested by Jeff Burdges et al (Difficult?). * Support a user specified "always use archive.is for these sites" list. * UI improvements. * More Quality of Life/Privacy improvements (Come for the Street Signs, stay for the user scripts). * I will eventually get annoyed enough at being linked to mobile wikipedia that I will rewrite URLs to strip out the ".m.". * Test this on Fennec. * Maybe throw this up on addons.mozilla.org. Regards, -- Yawning Angel

6 10

[GSoC] Tails Server - status report
by segfault 16 May '16

16 May '16

Hi everyone, this is the first status report on the Tails Server GSoC project. I officially began working on it on April 25th, although I already did some work in the weeks before. This is what I have done so far: * Updating the blueprint of the Tails Server [1] * Implementing two iterations of prototypes of the GUI. The most recent one is available on gitlab [2]. * Discussing the design of the GUI on the Tails-UX mailing list [3][4] * I began implementing the CLI, the current code (not ready for review yet) is also available on gitlab [2] Next I plan to continue the design of the GUI, after others commented on the new prototype. There are still some features missing which I will implement in time. In parallel I will continue implementing the CLI and discussing the design decisions. I did quite a lot during the last two weeks and I will have some other work to do in the next two weeks, so I expect to get less work done until the next report. Cheers! [1] https://tails.boum.org/blueprint/tails_server/ [2] https://gitlab.com/segfault_/tails_server [3] https://mailman.boum.org/pipermail/tails-ux/2016-April/thread.html#919 [4] https://mailman.boum.org/pipermail/tails-ux/2016-May/thread.html#953

2 2

Firejail Integration
by bancfc＠openmailbox.org 13 May '16

13 May '16

Hi Yawning. We are thinking about how to integrate your Firejail profile [0] in Whonix. Do you plan to upstream the changes in the start-tor-browser script soon? If not then what is the best way to ensure the custom script survives TBB upgrades? [0] https://git.schwanenlied.me/yawning/tor-firejail

2 1

exitmap modules that make *lots* of connections
by Zack Weinberg 13 May '16

13 May '16

I'm working on an exitmap module that wants to feed order of 5000 short-lived streams through each exit relay. I think this is running foul of some sort of upper limit (in STEM, or in Tor itself, not sure) on the number of streams a circuit can be used for, or how long, or something. What I see in the logs (note: I've modified eventhandler.py for more detailed debug logs) looks like 2016-04-22 16:07:53,306 [DEBUG]: Circuit status change: CIRC 6 LAUNCHED PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:53,325 [DEBUG]: Circuit status change: CIRC 6 EXTENDED [fp] PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:54,114 [DEBUG]: Circuit status change: CIRC 6 EXTENDED [fp],[fp] PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:54,115 [DEBUG]: Circuit status change: CIRC 6 BUILT [fp],[fp] PURPOSE=GENERAL TIME_CREATED=2016-04-22T20:07:53.305851 2016-04-22 16:07:54,136 [DEBUG]: Port 47488 preparing to attach to circuit 6 2016-04-22 16:07:54,136 [DEBUG]: Port 47488 circuit 6 waiting for stream. 2016-04-22 16:07:54,155 [DEBUG]: Attempting to attach stream 65 to circuit 6. 2016-04-22 16:07:54,387 [DEBUG]: Port 47492 preparing to attach to circuit 6 2016-04-22 16:07:54,387 [DEBUG]: Port 47492 circuit 6 waiting for stream. 2016-04-22 16:07:54,388 [DEBUG]: Attempting to attach stream 67 to circuit 6. 2016-04-22 16:07:54,809 [DEBUG]: Port 47496 preparing to attach to circuit 6 2016-04-22 16:07:54,810 [DEBUG]: Port 47496 circuit 6 waiting for stream. 2016-04-22 16:07:54,810 [DEBUG]: Attempting to attach stream 69 to circuit 6. 2016-04-22 16:07:55,060 [DEBUG]: Port 47502 preparing to attach to circuit 6 2016-04-22 16:07:55,060 [DEBUG]: Port 47502 circuit 6 waiting for stream. 2016-04-22 16:07:55,061 [DEBUG]: Attempting to attach stream 72 to circuit 6. 2016-04-22 16:07:55,468 [DEBUG]: Port 47506 preparing to attach to circuit 6 2016-04-22 16:07:55,468 [DEBUG]: Port 47506 circuit 6 waiting for stream. 2016-04-22 16:07:55,469 [DEBUG]: Attempting to attach stream 74 to circuit 6. 2016-04-22 16:07:55,720 [DEBUG]: Port 47508 preparing to attach to circuit 6 2016-04-22 16:07:55,720 [DEBUG]: Port 47508 circuit 6 waiting for stream. 2016-04-22 16:07:55,990 [DEBUG]: Port 47512 preparing to attach to circuit 6 2016-04-22 16:07:55,990 [DEBUG]: Port 47512 circuit 6 waiting for stream. 2016-04-22 16:07:55,990 [DEBUG]: Attempting to attach stream 77 to circuit 6. 2016-04-22 16:07:56,241 [DEBUG]: Port 47518 preparing to attach to circuit 6 2016-04-22 16:07:56,241 [DEBUG]: Port 47518 circuit 6 waiting for stream. 2016-04-22 16:07:56,242 [DEBUG]: Attempting to attach stream 80 to circuit 6. 2016-04-22 16:07:56,492 [DEBUG]: Port 47528 preparing to attach to circuit 6 2016-04-22 16:07:56,492 [DEBUG]: Port 47528 circuit 6 waiting for stream. 2016-04-22 16:07:56,495 [DEBUG]: Attempting to attach stream 85 to circuit 6. 2016-04-22 16:07:56,836 [DEBUG]: Port 47536 preparing to attach to circuit 6 2016-04-22 16:07:56,836 [DEBUG]: Port 47536 circuit 6 waiting for stream. 2016-04-22 16:07:56,836 [DEBUG]: Attempting to attach stream 89 to circuit 6. 2016-04-22 16:07:57,100 [DEBUG]: Port 47540 preparing to attach to circuit 6 2016-04-22 16:07:57,100 [DEBUG]: Attempting to attach stream 91 to circuit 6. 2016-04-22 16:07:57,351 [DEBUG]: Port 47544 preparing to attach to circuit 6 2016-04-22 16:07:57,351 [DEBUG]: Port 47544 circuit 6 waiting for stream. 2016-04-22 16:07:57,352 [DEBUG]: Attempting to attach stream 93 to circuit 6. 2016-04-22 16:07:57,769 [DEBUG]: Port 47550 preparing to attach to circuit 6 2016-04-22 16:07:57,769 [DEBUG]: Port 47550 circuit 6 waiting for stream. 2016-04-22 16:07:57,769 [DEBUG]: Attempting to attach stream 96 to circuit 6. 2016-04-22 16:07:58,118 [DEBUG]: Port 47554 preparing to attach to circuit 6 2016-04-22 16:07:58,118 [DEBUG]: Port 47554 circuit 6 waiting for stream. 2016-04-22 16:07:58,118 [DEBUG]: Attempting to attach stream 98 to circuit 6. 2016-04-22 16:08:04,697 [DEBUG]: Circuit status change: CIRC 6 CLOSED [fp],[fp] PURPOSE=PATH_BIAS_TESTING TIME_CREATED=2016-04-22T20:07:53.305851 REASON=FINISHED 2016-04-22 16:08:05,878 [DEBUG]: Port 47690 preparing to attach to circuit 6 2016-04-22 16:08:05,878 [DEBUG]: Port 47690 circuit 6 waiting for stream. 2016-04-22 16:08:05,879 [DEBUG]: Attempting to attach stream 166 to circuit 6. 2016-04-22 16:08:05,879 [WARNING]: Failed to attach stream because: Unknown circuit "6" You can see that circuit 6 is no longer available, but the module is still trying to use it. It looks like it lasted for almost exactly ten seconds, which smells like a time limit, but I can't find any relevant configuration parameters in the documentation. Rather than trying to make a circuit survive as long as necessary, which might not even be possible, it'd probably be better if exitmap could notice that it's lost a circuit that's still in use and create a new one. However, I'm not sure how to do that in the current architecture. The existing code has "one circuit per module invocation = one circuit per exit node" as a pretty deeply embedded design constraint. Anyone have any ideas? Full logfile available on request, but it's huge. zw

2 2

Fewer Failures in Shared Random
by Tim Wilson-Brown - teor 12 May '16

12 May '16

Hi All, Currently, the shared random system treats the first vote of the next commit phase specially - it's the only time it tries to agree on a new shared random value. This makes one consensus in each day particularly attractive to adversaries (or particularly vulnerable to failures), because if we fail to agree on that consensus, the next shared random value is never agreed. This makes hidden service behaviour far more predictable for the next 24 hours. But we can try to agree 12 times on a new shared random value like this: * for the first consensus in the new commit period: * vote the calculated shared random value based on the commits and reveals we've seen; * for subsequent consensuses in the new commit period: * if we have an agreed shared random value from a trusted, previous consensus in the period, vote that value; * if not, (if the new shared random value is missing from all previous consensuses in that period, or there is no trusted consensus), continue to vote our calculated value. This way, we try up to 12 times to agree on a shared random value. (But we never change an agreed value after we've agreed on it.) This is very similar to how the previous shared random value is determined. I've added #19045 to keep track of this: https://trac.torproject.org/projects/tor/ticket/19045 Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n

1 0