- tor-dev - lists.torproject.org

Proposal 277: Detect multiple relay instances running with same ID
by Nick Mathewson 24 Feb '17

24 Feb '17

Filename: 277-detect-id-sharing.txt Title: Detect multiple relay instances running with same ID. Author: Nick Mathewson Created: 20-Feb-2017 Status: Open Target: 0.3.?? 1. Overview This document proposes that we detect multiple relay instances running with the same ID, and block them all, or block all but one of each. 2. Motivation While analyzing microdescriptor and relay status transitions (see proposal XXXX), I found that something like 16/10631 router identities from January 2017 were apparently shared by two or more relays, based on their excessive number of onion key transitions. This is probably accidental: and if intentional, it's probably not achieving whatever the relay operators intended. Sharing identities causes all the relays in question to "flip" back and forth onto the network, depending on which one uploaded its descriptor most recently. One relay's address will be listed; and so will that relay's onion key. Routers connected to one of the other relays will believe its identity, but be suspicious of its address. Attempts to extend to the relay will fail because of the incorrect onion key. No more than one of the relays' bandwidths will actually get significant use. So clearly, it would be best to prevent this. 3. Proposal 1: relay-side detection Relays should themselves try to detect whether another relay is using its identity. If a relay, while running, finds that it is listed in a fresh consensus using an onion key other than its current or previous onion key, it should tell its operator about the problem. (This proposal borrows from Mike Perry's ideas related to key theft detection.) 4. Proposal 2: offline detection Any relay that has a large number of onion-key transitions over time, but only a small number of distinct onion keys, is probably two or more relays in conflict with one another. In this case, the operators can be contacted, or the relay blacklisted. We could build support for blacklisting all but one of the addresses, but it's probably best to treat this as a misconfiguratino serious enough that it needs to be resolved.

1 0

Proposing "Post-Quantum safe handshake implementation" as GSoc Project
by Jaskaran Singh 23 Feb '17

23 Feb '17

Hi, My name is Jaskaran, and I'm an Electronics Engineering undergrad in India. I'm a privacy, anonymity and FOSS supporter. I've worked in the past with the Libreoffice project during the Google Summer of Code 2016. This year I'm interested to work with the TOR project as a part of GSoC. I'm particularly interested to work on making TOR Handshakes Post-Quantum Safe. I feel that this should be implemented at the earliest because adversaries could store the network traffic and decrypt it later on using Quantum Computers when they're invented. So here's what I think the task would comprise of : 1. Add a new CREATE2V and CREATED2V cell that can support 2240 bytes of HDATA (according to NewHope-Simple algorithm[1]). Add facility for multiple EXTEND2/EXTENDED2 cells to be sent when the handshake data doesn't fit into a single cell. 2. Implement the NewHope-Simple algorithm[1] because we'll not be able to use the Vanilla NewHope as it is protected by some patents. I wasn't able to find any implementation of NewHope Simple. So can the Vanilla NewHope Implementation be tweaked to convert it into NewHope Simple? Or would we have to write it from ground up? I don't know about the patent laws regarding it. 3. Finally, generate test vectors and check for any bottlenecks. Improve efficiency and check for any vulnerabilities in the implementation that could be exploited by the adversary. I'd like to know your views on this. Suggestions, comments, criticism are all welcome. References [1] https://eprint.iacr.org/2016/1157.pdf PS: There's Something I noticed while reading the proposal. The portions don't add up to the size of the cell. Here's aSigned fix for it. commit a55692fcd93e3f064f1fffe24796dc747e4870e1 Author: Jaskaran Singh <jvsg1303(a)gmail.com> Date: Sat Feb 18 13:32:32 2017 +0530 Fix HDATA sizes in proposal 270 diff --git a/proposals/270-newhope-hybrid-handshake.txt b/proposals/270-newhope-hybrid-handshake.txt index ccf3390..c0f36ae 100644 --- a/proposals/270-newhope-hybrid-handshake.txt +++ b/proposals/270-newhope-hybrid-handshake.txt @@ -432,7 +432,7 @@ Depends: prop#220 prop#249 prop#264 prop#270 HTYPE := 0x0003 [2 bytes] HLEN := 0x0780 [2 bytes] HDATA := CLIENT_HDATA [1920 bytes] - IGNORED := 0x00 [194 bytes] + IGNORED := 0x00 [190 bytes] } [XXX do we really want to pad with IGNORED to make CLIENT_HDATA the @@ -485,7 +485,7 @@ Depends: prop#220 prop#249 prop#264 prop#270 NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] - HDATA := 0x00[172] [172 bytes] + HDATA := 0x00[172] [174 bytes] } The client sends this to the server to extend the circuit from, and that @@ -525,7 +525,7 @@ Depends: prop#220 prop#249 prop#264 prop#270 NSPEC := 0x00 [1 byte] HTYPE := 0xFFFF [2 bytes] HLEN := 0x0000 [2 bytes] - HDATA := SERVER_HDATA[1940,2112] [172 bytes] + HDATA := SERVER_HDATA[1940,2112] [174 bytes] } Regards, Jaskaran

3 3

txtorcon 'all_routers' issue
by meejah 23 Feb '17

23 Feb '17

As per https://github.com/meejah/txtorcon/issues/203 all released versions of txtorcon that have TorState.all_routers will, upon a NEWCONSENSUS event, make this set empty. There is already a fix on master for the real issue and it will be in the next release. For users of released versions there is a workaround, pointed out by evilaliv3: simply use TorState.routers.values() instead. Cheers, meejah

1 0

List of Tor Exit IP address: Is this available from Tor Control Port
by Fabio Pietrosanti (naif) - lists 22 Feb '17

22 Feb '17

Hi all, is the list of Tor Exit IP addresses available from Tor Control Port or only from https://check.torproject.org/exit-addresses via TorDNSEL ? -naif

2 1

announcing: txmix, a twisted python mixnet library
by dawuud 19 Feb '17

19 Feb '17

Hi. I'd like to announce txmix, a library for writing mixnets in python. https://github.com/applied-mixnetworks/txmix txmix is GPL3 licensed and currently depends on: sphinxmixcrypto, Twisted, txtorcon, attrs, eliot and Tor Project's chutney (for integration tests). txmix allows you to write mixnets with reduced code complexity and transport agnosticism... however I've choosen to focus my development efforts on the Tor onion transport for several reasons, the onion transport has some properties which the UDP transport does not: - reliability - forward secrecy - NAT penetration Additionally the Tor anonymity properties are a welcome bonus since they aren't really overlapping with those of the mixnet, they are vulnerable to different types of attacks and accomodate for totally different threat models. Currently txmix has some integration tests that use chutney to spin up a local 25 relay tor network; builds a mixnet using onion services as the transport and then tests functionality by sending and receiving messages on the mixnet. future development ------------------ - txmix could certainly be used to write various kinds of mixnets, however, we are missing a PKI. Without some kind of public key infrastructure how will mix clients learn about mix public keys? - sphixmixcrypto library needs improvements that would allow us to specify more message types such as dummy/cover traffic message and heartbeat messages. These of course are essential for the defense against certain known active attacks against some mix types. questions, code review and pull requests welcome. David Stainton

1 0

Netflow padding
by grarpamp 19 Feb '17

19 Feb '17

Are these the current / recommended paper refs for eyeballing things on this to date? torspec/proposals/251-netflow-padding.txt torspec/proposals/254-padding-negotiation.txt

2 1

Re: [tor-dev] GAEuploader (Adam Fisk)
by Katherine Li 19 Feb '17

19 Feb '17

Hi Adam, my experience is also that GAE is blocked in China. It is possible to find unblocked IPs. XXnet, for example, has a built-in scanne <https://github.com/XX-net/XX-Net/wiki/%E2%80%9C%E6%89%AB%E6%8F%8FIP%E2%80%9…>r for Google's unblocked IPs. GAEuploader currently does not have built-in scanning for unblocked IP addresses. We definitely want to incorporate this feature in the future, and any contribution on this would be much appreciated. On Wed, Feb 1, 2017 at 9:40 AM, Adam Fisk <afisk(a)getlantern.org> wrote: > In our experience GAE is basically blocked in China at least. Is that > your experience as well? I believe it's possible to find IPs that are > unblocked, but you'd have to embed those IPs somehow into the client > or integrate the scanning. Katherine Li https://github.com/katherinelitor/GAEuploader

1 0

Tor Browser and Mozilla addon verification
by bancfc＠openmailbox.org 18 Feb '17

18 Feb '17

Hi, does Tor Browser check addon code for tampering for addons from the Mozilla server?

2 2

[release] metrics-lib/DescripTor 1.6.0
by iwakeh 17 Feb '17

17 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! Another release of metrics-lib/DescripTor is available: https://dist.torproject.org/descriptor/1.6.0/ - From the change-log: * Major changes - Deprecate DescriptorDownloader in favor of the much more widely used DescriptorCollector. * Medium changes - Parse "proto" lines in server descriptors, "pr" lines in status entries, and "(recommended|required)-(client|relay)-protocols" lines in consensuses and votes. - Parse "shared-rand-.*" lines in consensuses and votes. ... and quite a bit more see [0]. Please direct comments and questions to the metrics-team mailing list [1]. Cheers, iwakeh [0] https://gitweb.torproject.org/metrics-lib.git/plain/CHANGELOG.md?id=10042d3… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYpyhdAAoJEPeEx9Sa/gvikq0QAKKhd2v04WGwokOGD+j7HNJC ylEamW7BSxMHCecgkMULy7RvTkmUmw/OJ66Ob2chdqVd6di8/fej3Sra+mpxcx9f mibg7UTLtMPgmoKMOp2qL7++HYuhWOowU+6e5rF1Ps0vVBZHWAD2iRCMX+jU2J+p XzYcVJ4YyV7ovfITDi1hDMvOXqDRrvhbH5bFDgXM0b5mWyKfjb/p35Y5wivEFPxp DYfVQ231IhDaN8ews3jXpuU8MILUBxzybOK+xtnAfYI4SXxMrJ16LmEpuP5lL2j8 9FfdG2U9MTdxnfEEYVPV/NrBRxZ9r+6d6pTtySmJ8D2s1hnwF3higTYm1DPCfU5U /m1AtLJsFvGVd/qJ4TNmWww8r1WgZlPzggVHgsHL28lpGK3L8ryQrbA0Nr6AVuFO sHDG4Fq5iegoWPsgGIcD8ThJlgvi5a6nS0l79OL+DUv4is2zQeI+zOgiaVeu/CmE JlRkMaA3U2AxayqBSJCwHKdFOu75cHCErTYEQt8Oy+h3rhrw2ucfUe/fKyMOVWps g156i/PsroggHMZWackXBv9tPJyK57ipTEr84ljg2jsZYTUsrYzN13+v/bkrOWXe jTOiicdFJ8Kfyj9Ng5afbLmt24W7BYQSqp4BM4MdEmZ2sY4Zq3iTPMqzBGai3OV4 8EJ5gsOCP7WEmSJcMNyg =EBek -----END PGP SIGNATURE-----

1 0

Prop224 oppurtunity: keygen, crypt, sign, encoding tools
by grarpamp 17 Feb '17

17 Feb '17

Tor could ship with a tool to offline generate all the various keys, encrypt and sign with them, for debug, test, and use with other apps that tie to tor. And a tool to translate strings between different encodings in use. Or at least provide howto and links in the docs to third party tools that users could use for key ops and translation. Since those howto topics appear on the lists now and then. We here might code up openssl, python functions, etc on the fly. However beginning users are typically looking for simple purpose dedicated tools, or example docs using prebuilt tools off the net. This tends to apply to budding application development in onionland, developing things that look at and use tor, etc.

5 4