- tor-dev - lists.torproject.org

Roster introduction
by Virgil Griffith 29 Jul '15

29 Jul '15

Hello everyone. This is my first report on the Roster project and I wanted to give you all an introduction what it is and where it's going. I'm interested in seeing Tor grow. Current work towards this is tor2web and now Roster. Roster is the rebranded continuation of the "Torati" proposal which I first mentioned here: https://lists.torproject.org/pipermail/tor-dev/2014-June/006975.html In short the gist is to: * Socially incentivize operators to run relays. * Make the operator experience more compelling. * Gamify operating a Tor relay. The main difference between Roster and Globe/Atlas is that Roster provides information at the level of *operators*, not individual relays. In Roster information is aggregated and metrics are summed across all relays of a family. The idea is that when you run a relay, you generate nerd points and badges. And then when people Google your name/alias, they will see how many nerd points+badges you have and they will be in awe of your epic geek-street-cred. In addition to improving operator experience, there are proposals for encouraging operators to do things Tor management like them to do such as upgrading to the latest Tor version and/or probably setting up their Families. E.g., a badge for using the latest/recommended Tor software. That's the gist of it. I will be spending most of my time on tor-relays@ and talking with operators there. So if you want to follow day-to-day stuff subscribe there. Main things accomplished so far: * Setup the basic website at: http://www.tor-roster.org/ * I have an assistant whom I've taken under my wing. His name is Sean Saito <saitosean(a)ymail.com>. He's a Computer Science student at Yale-NUS here in Singapore. He wishes to become more involved in The Tor Project and this is his first Tor-related experience. * We also have discussed with the tor-relays@ list candidate badges. Are interested in additional badge proposals. --- https://lists.torproject.org/pipermail/tor-relays/2015-June/007228.html That's it so far. -Virgil

3 5

[Measurement Team] Next IRC meeting happens tomorrow, Jul 29, 14:00 UTC in #tor-project
by Karsten Loesing 28 Jul '15

28 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team tomorrow on Wednesday, July 29, 2015, 14:00 UTC in #tor-project http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150729T14 Two weeks ago we created a list of existing measurement-related products and last week we brainstormed what tools we would want to exist if none of these existed yet. Logs of all past meetings are available here: http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-08-14.06.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-15-14.00.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-22-14.00.log… While I found the last two meetings extremely productive, I want to suggest a slightly looser-defined agenda this week: - Introductions, problems, products, priorities: any feedback, remarks, comments on what we did in the previous three weeks (for example, I'm planning to present a roadmap document based on the two pads we worked on in the past two weeks) - 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) - Misc/discussion: whatever comes up during the meeting If you think this can be fun, please join us at the meeting! Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVt5O9AAoJEJD5dJfVqbCrqVUH/jKEjckSOEY+1hOpz7cyPXFr E6Z7L64gDSUlCJ68YeADA5C8Y1kG6Pzkhb+Z7zGigJp7ZdEWI8xLbhUtXcgE6cQY 9pyqYd+IK/zNrSdUTgHEfpfHF0sAyHCgMcUMuNQ0Vt82IFxyWef30MJm/w6jvis8 v5iFRLbDut1YZ+xXmm/Y6YyyXxCuSPE/rKxQUbIXFAqf3Nz4207tC4VF9h53vKeF aZr5fnZC6j3cdt0QbPi3vBYMsw9oU0Z9HDpleEh639uEM07wq7wamBvvOKJioNtT 0IcwlDoCDx5ldyZsCNE9aOdVzwkzDjYBRytgNJUHzTyh+yjmFzlIR3a5H8KTVrI= =FCO3 -----END PGP SIGNATURE-----

1 0

Tor Browser/Tor Applications Team Meeting temporarily moved to Tuesday 18:00 UTC
by Mike Perry 26 Jul '15

26 Jul '15

The Tor Browser team meeting will be temporarily moved this week to Tuesday (July 28th) at 18:00 UTC, due to scheduling conflicts for Georg and me. Because of an additional conflict with the Tor Patch Workshop, we will likely be using #tor-project on irc.oftc.net instead of #tor-dev, as well. We're also expanding the meeting in general to open it up to anyone who is working on user-facing Tor client applications (such as Tor Birdy, Tor Messenger, Ricochet, GetTor, Satori, etc). If you work on something user-facing and want to discuss UI/UX, censorship circumvention configuration, or any related topics, please join us! The meeting format is described here: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html -- Mike Perry

1 0

Proposal 249: Allow CREATE cells with >505 bytes of handshake data
by Nick Mathewson 23 Jul '15

23 Jul '15

Filename: 249-large-create-cells.txt Title: Allow CREATE cells with >505 bytes of handshake data Authors: Nick Mathewson Created: 23 July 15 Status: Draft 1. Summary There have been multiple proposals over the last year or so for adding post-quantum cryptography to Tor's circuit extension handshakes. (See for example https://eprint.iacr.org/2015/008 or https://eprint.iacr.org/2015/287 .) These proposals share the property that the request and reply for a handshake message do not fit in a single RELAY cell. In this proposal I describe a new CREATE2V cell for handshakes that don't fit in a 505-byte CREATE2 cell's HDATA section, and a means for fragmenting these CREATE2V cells across multiple EXTEND2 cells. I also discuss replies, migration, and DoS-mitigation strategies. 2. CREATE2V and CREATED2V First, we add two variable-width cell types, CREATE2V and CREATED2V. These cell formats are nearly the same as CREATE2 and CREATED2. (Here specified using Trunnel.) struct create2v_cell_body { /* Handshake type */ u16 htype; /* Length of handshake data */ u16 hlen; /* Handshake data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; struct created2v_cell_body { /* Handshake replay length */ u16 hlen; /* Handshake reply data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; The 'ignored' fields, which extend to the end of the variable-length cells, are reserved. Initiators MAY set them to any length, but MUST fill them with zero-valued bytes. Responders MUST ignore them, regardless of what they contain. When a CREATE2V cell is generated in response to a set of EXTEND2 cells, these fields are set by the relay that receives the EXTEND2 cells. (The purpose of the 'ignored' fields here is future-proofing and padding.) 3. Fragmented EXTEND2 cells Without changing the current EXTEND2 cell format, we change its semantics: If the 'HLEN' field in an EXTEND2 cell describes a handshake data section that would be too long to fit in the EXTEND2 cell's payload, the handshake data of the EXTEND2 cell is to be continued in one or more subsequent EXTEND2 cells. These subsequent cells MUST have zero link specifiers, handshake type 0xFFFF, and handshake data length field set to zero. Similarly, if the 'HLEN' field in an EXTENDED2 cell would be too long to fit into the EXTENDED2 cell's payload, the handshake reply data of the EXTENDED2 cell is to be continued in one or more subsequent EXTENDED2 cells. These subsequent cells must have the handshake data length field set to zero. These cells must be sent on the circuit with no intervening cells. If any intervening cells are received, the receiver SHOULD destroy the circuit. 4. Example So for example, if we are a client, and we need to send a 2000-byte handshake to extend a circuit from relay X to relay Y, we might send cells as follows: EXTEND2 { nspec = 2; { node ID for Y, taking 22 bytes. } { node address for Y, taking 8 bytes } htype = {whatever the handshake type is.} hlen = 2000 hdata = { the first 462 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the final 62 bytes of the handshake } } Upon receiving this last cell, the relay X would send a create2v cell to Y, containing the entire handshake. 5. Migration We can and should implement the EXTEND2 fragmentation feature before we implement anything that uses it. If we can get it widely deployed before it's needed, we can use the new handshake types whenever both of the involved relays support this proposal. Clients MUST NOT sent fragmented EXTEND2 cells to relays that don't support them, since this would cause them to close the circuit. Relays MAY send CREATE2V and CREATED2V cells to relays that don't support them, since unrecognized cell types are ignored. 6. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell bodies for incoming cells until the entire CREATE2V/CREATED2V body has arrived. To avoid memory-related denial-of-service attacks, the buffers allocated for this data need to be counted against the total data usage of the circuit. Appendix A. A rejected idea for migration In section 5 above, I gave up on the idea of allowing relay A to extend to relay B with a large CREATE cell when relay A does not support this proposal. There are other ways to do this, but they are impressively kludgey. For example, we could have a fake CREATE cell for new handshake types that always elicits a "yes, keep going!" CREATED cell. Then the client could send the rest of the handshake and receive the rest of the CREATED cell as RELAY cells inside the circuit. This design would add an extra round-trip to circuit extension whenever it was used, however, and would violate a number of Tor's assumptions about circuits (e.g., by having half-created circuits, where authentication hasn't actually been performed). So I'm guessing we shouldn't do that.

1 0

[Patch] or/config.c for MSVC
by Gisle Vanem 23 Jul '15

23 Jul '15

This gcc-centric macro in or/config.c doesn't work well in MSVC v16/18: #define COMPLAIN(args...) \ STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END I suggest it should be patched like this: --- a/config.c 2015-05-06 22:22:09 +0000 +++ b/config.c 2015-05-06 23:15:57 +0000 @@ -2571,8 +2571,8 @@ #define REJECT(arg) \ STMT_BEGIN *msg = tor_strdup(arg); return -1; STMT_END -#define COMPLAIN(args...) \ - STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END +#define COMPLAIN(args, ...) \ + STMT_BEGIN log_warn(LD_CONFIG, args, ## __VA_ARGS__); STMT_END /** Log a warning message iff <b>filepath</b> is not absolute. * Warning message must contain option name <b>option</b> and ------- All recent compilers supports '__VA_ARGS__'? -- --gv

3 5

☎ Second Computer Graphics, Multimedia and Image Processing - 2015 Malaysia
by Conference Alert 23 Jul '15

23 Jul '15

The Second International Conference on Computer Graphics, Multimedia and Image Processing (CGMIP2015) Universitas Siswa Bangsa Internasional Jakarta, Indonesia October 29-31, 2015 http://sdiwc.net/conferences/cgmip2015/ cgmip15(a)sdiwc.net ---------------------------------------------- CALL FOR PAPERS, WORKSHOP and SPECIAL SESSIONS ---------------------------------------------- Research topics not limited to: - 3D imaging - Case studies and emerging technologies - Color and texture - Computational geometry - Computer art and entertainment (including games) - Case studies - Classification and clustering techniques - Compression methods - Computer animation - Curves and meshes - e-Learning applications and computer graphics - Emerging technologies - Emerging display technologies - Face recognition, face detection, and gesture recognition - Fractal geometry and applications - Graphics algorithms and applications - Graph theory in image processing and vision - Human-computer interfaces - Image compression, coding, and encryption - Image feature extraction - Image geometry and multi-view geometry - Immersive virtual reality - Interactive digital media - Simulation and virtual reality - Software tools for virtual reality - Surface modeling - Virtual environments - Virtual laboratories - Virtual reality, visualization, and education - Visualization All registered papers will be included in SDIWC Digital Library, and in the proceedings of the conference. All submitted papers will be reviewed by a minimum of two reviewers. The published proceedings will be indexed in ResearchBib, in addition, they will be reviewed for POSSIBLE inclusion within the INSPEC, EI, DBLP, Microsoft Academic Research, ResearchGate, and Google Scholar Databases. Important Dates =============== Submission Deadline: September 29, 2015 Notification of Acceptance: 2-4 weeks from the submission date Camera Ready Submission: October 19, 2015 Registration Deadline: October 19, 2015 Conference Dates: October 29-31, 2015

1 0

Fwd: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00
by hellekin 22 Jul '15

22 Jul '15

Dear Tor developers, would it be possible to add https://torproject.org/spec page, including anchors for the various specifications: #tor-protocol, #tor-rendezvous, etc. pointing to the repository, to accommodate the General Area Review Team's comments, enable future stable reference to Tor specs, and move on? That would be very, very simple to implement, and very, very useful as a temporary fix since I don't see the Tor project nor the IETF releasing Tor specs RFCs before the CAB forum's deadline is reached within four months. Thank you, == hk -------- Forwarded Message -------- Subject: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00 Date: Sat, 18 Jul 2015 05:25:25 -0400 From: Joel M. Halpern <jmh(a)joelhalpern.com> To: A. Jean Mahoney <mahoney(a)nostrum.com>, General Area Review Team <gen-art(a)ietf.org>, dnsop(a)ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dnsop-onion-tld-00 The .onion Special-Use Domain Name Reviewer: Joel Halpern Review Date: 18-July-2015 IETF LC End Date: 11-August-2015 IESG Telechat date: N/A Summary: This document is nearly ready for publication as a Proposed Standard RFC Major issues: It seems to this reviewer that at least the definition of how to use these names, reference tor-rendezvous, needs to be a normative reference. It appears likely that tor-address also ought to be a normative reference. Minor issues: It is not clear that a github reference without version identification is sufficiently stable for a normative reference from an RFC. Nits/editorial comments: _______________________________________________ DNSOP mailing list DNSOP(a)ietf.org https://www.ietf.org/mailman/listinfo/dnsop

3 10

Proposal 248: Remove all RSA identity keys
by Nick Mathewson 22 Jul '15

22 Jul '15

Filename: 248-removing-rsa-identities.txt Title: Remove all RSA identity keys Authors: Nick Mathewson Created: 15 August 2015 Status: Draft 1. Summary With 0.2.7.2-alpha, all relays will have Ed25519 identity keys. Old identity keys are 1024-bit RSA, which should not really be considered adequate. In proposal 220, we describe a migration path to start using Ed25519 keys. This proposal describes an additional migration path, for finally removing our old Ed25519 keys. See also proposal 245, which describes a migration path away from the old TAP RSA1024-based circuit extension protocol. 1.1. Steps of migration Phase 1. Prepare for routers that do not advertise their RSA identities, by teaching clients and relays and other dependent software how to handle them. Reject such routers at the authority level. Phase 2. Once all supported routers and clients are updated to phase 1, we can accept routers at the authority level which lack RSA keys. Phase 3. Once all authorities accept routers without RSA keys, we can finally remove RSA keys from relays. 2. Accepting descriptors without RSA identities We make the following changes to the descriptor format: If an ed25519 key and signature are present, then these elements may be omitted: "fignerprint", "signing-key", "router-signature". They must either be all present or all absent. If they are all absent, then the router has no RSA identity key. Authorities MUST NOT accept routers descriptors of this form in phase 1. 3. Accepting handshakes without RSA identities When performing a new version of our link handshake, only the Ed25519 key and certificates and authentication need to be performed. If the link handshake is performed this way, it is accepted as authenticating the route with an ed25519 key but no RSA key. A circuit extension EXTEND2 cell may contain an Ed25519 identity but not an RSA identity. In this case, the relay should connect the circuit to any connection with the correct ed25519 identity, regardless of RSA identity. If an EXTEND2 cell contains an RSA identity fingerprint, however, its the relay receiving it should not connect to any relay that has a different RSA identity or that has no identity, even if the Ed25519 identity does match. 4. UI updates In phase 1 we can update our UIs to refer to all relays that have Ed25519 keys by their Ed25519 keys. We can update our configuration and control port interfaces so that they accept Ed keys as well as RSA keys. During phase 1, we should warn about identifying any dual-identity relays by their Ed identity alone. For backward compatibility, we should consider a default that refers to referring to Ed25519 relays by the first 160 bits of their key. This would allow many controller-based tools to work transparently with the new key types. 5. Changes to external tools This is the big one. We need a relatively comprehensive list of tools we can break with the above changes. Anything that refers to relays by SHA1(RSA1024_id) will need to be able to remember and use an Ed25519 key instead. 5. Testing Before going forward with phase 2 and phase 3, we need to verify that we did phase 1 correctly. To do so, we should create a small temporary testing network, and verify that it works correctly as we make the phase 2 and phase 3 changes.

6 6

BOINC-based Tor wrapper
by Serg 21 Jul '15

21 Jul '15

Greetings to all developers! What do you think? BOINC - The Berkeley Open Infrastructure for Network Computing. https://boinc.berkeley.edu/ Technical wiki: https://boinc.berkeley.edu/trac/wiki/ProjectMain BOINC -> VirtualBox -> operating system with running Tor relay. Real working solutions? Yes: http://atlasathome.cern.ch/ http://lhcathome2.cern.ch/vLHCathome/ Platform diversity in Tor network may be solved by preparing images with different operating systems. The power of the Tor network may grow very quickly. Fastes reaction to Security vulnerabilities. All client will upgrade Tor images by administrator command. (all images should be signed ofcourse. It is the BOINC principle). You are doing a great job. Thank you! -- Best regards, Sergey

4 6

[Measurement Team] Next IRC meeting happens tomorrow, Jul 22, 14:00 UTC in #tor-project
by Karsten Loesing 21 Jul '15

21 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [I hope this message is not considered noise by people on this list, but we haven't yet decided where these announcements should be sent. Until we have, I'm planning to send these messages to this list and tag them with [Measurement Team], so that people can filter these messages if they absolutely don't care. Thanks for understanding.] Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team tomorrow on Wednesday, July 22, 2015, 14:00 UTC in #tor-project http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150722T14 Two weeks ago we started with introductions, and last week we created a list of measurement-related products and started writing fact sheets for some of them. Logs are available here: http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-08-14.06.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-15-14.00.log… This week I suggest the following agenda: - Introductions, 5 min (only if someone didn't introduce themselves yet) - Problems, 5-10 min: did anything else come up since last week - Products, 5 min: what are we doing with fact sheets - Priorities, 30 min: should we focus more on a certain aspect of measurements in the Tor network, while temporarily suspending or even permanently dropping other aspects? - Misc, 5 min: anything else you come up with Regarding the Priorities item, I'd want us to do another collaborative round involving a pad where we temporarily assume that no single Tor measurement-related tool exists or ever existed and where we brainstorm what tools we should build to measure (passively collect, actively probe, sanitize, archive, pre-process, feed back, aggregate, visualize) things in the Tor network. Maybe we can conclude that brainstorming session by deriving some suggestions for prioritizing our work, given the fact that some of the tools already exist. Hope that sounds interesting to you, but please remember that this discussion will happen tomorrow, not on this mailing list. If you want to participate, please join us at the meeting! Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVrjlvAAoJEJD5dJfVqbCrJp4IAMiq9Wp4N+ZEjaMdnXPPkMJS 5ItvmsxPxPZkhckrJafZtayE+3x+xfIZG44shgps53DKACxrtDxGdVruZRuA8o3f FGGLZ/YXQj7JJBiVGDn/vIXCfC4fuZSU5K4QYZeG9nDdspKl6HiB/xyavcF76mZw bQNyLU1870On1iQc7Ka9lP8+wO5WyfkJl0jspEs2GrRNMxK68hHakG8rFMVuE9z8 BQnqV113TQtSGJcpoWkfMeNQo0vf/BgbWVgE5/FA9x27WqQtS06oRfwxVMhgGYoW KNWVHyw0R7AG/1WEG/DTR8B/2M7iYVUmr4BrIjaaBo7GLYhySvo/z90fSiFz4Jg= =x3uM -----END PGP SIGNATURE-----

1 0