- tor-dev - lists.torproject.org

[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