- tor-dev - lists.torproject.org

Relay Database: Existing Schemas?
by nusenu 26 Feb '16

26 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm planing to store relay data in a database for analysis. I assume others have done so as well, so before going ahead and designing a db schema I'd like to make sure I didn't miss pre-existing db schemas one could build on. Data to be stored: - - (most) descriptor fields - - everything that onionoo provides in a details record (geoip, asn, rdns, tordnsel, cw, ...) - - historic records I didn't find something matching so far, so I'll go ahead, but if you know of other existing relay db schemas I'd like to hear about it. thanks, nusenu "GSoC2013: Searchable Tor descriptor archive" (Kostas Jakeliunas) https://www.google-melange.com/gsoc/project/details/google/gsoc2013/wfn/ 5866452879933440 https://lists.torproject.org/pipermail/tor-dev/2013-May/004923.html https://lists.torproject.org/pipermail/tor-dev/2013-September/005357.htm l https://github.com/wfn/torsearch (btw, someone knows the license of this?) > This is true: the summary/details documents (just like in Onionoo > proper) deal with the *last* known info about relays. ernie https://gitweb.torproject.org/metrics-db.git/plain/doc/manual.pdf (didn't find db/tordir.sql mentioned in the pdf) "Instructions for setting up relay descriptor database" https://lists.torproject.org/pipermail/tor-dev/2010-March/001783.html "Set up descriptor database for other researchers" https://trac.torproject.org/projects/tor/ticket/1643 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVLrmVAAoJEFv7XvVCELh0+ycP/0VkRWMGAhx7YwWhixtOPB0q ouitosse3SdLCMd1W7cps7nnQhcGv8E1xeUPYeizNQ+RIK9ldvnwgxhVt9ETOI3e oL6bcx3B/NSbTcGfZhIU6XCCX7+39CXz3/+/gXg4c1a5Cd9rYKuwTn7ZApPUNAK2 9yfckCwHaqh67ZDHB1A7nrHX1BJAjwhri5JRGomHSUXPwNZOyMzpgPkB+I92esqc Z4ajQo2D+Vyk42qF7apqp5ApVBLdt5ycUtW1j4s4KvyJH2BjeP4tCXvvYLKv9IvN TGHMJ111NQXbuk6H1OdaDmMZhhW6utPk8YAbNc7RZHqCdH7No40zFVlikLDrV2Xl uLt8FMlck7hGQv/4udA59Dw3PGHfrSiCbvJXb0S2jarnWOH2O+zSSuMs8jQM/x7k 6tIOlwtRDVGw3VuvNbb4MJnLzdHRxq3qy6ueDYuhmhHslxjD1Cbr3eE1RA7Da9aX kNDgjfXtdah52HWUZbIIxHQYzyCg5G3M5yy51GhUlA2Fe1sbPpNcEBeyEDK/jH3Y +7G+tgR+CdMvSFraCiYKHa1drVPJHeqNvZAqPNHKxpKwOwOoJEYrsW4wb/mJ7ybe o8xNYK691hcaMvHqwI47tw4hZfrI0f0+gQKKzENQQk8/8yUZ/0jgMRlW/Cz0yYIa FZEg+OJ/yEs8vKfYerIN =Rfn4 -----END PGP SIGNATURE-----

3 2

stopping the censoring of tor users.
by blacklight . 26 Feb '16

26 Feb '16

hello there! i don't know if this mailing list works but i thought of giving it a try. i was lately reading an article ( http://www.pcworld.com/article/3037180/security/tor-users-increasingly-trea… ) and it was about tor users getting blocked from accessing alot of website. but after giving this some thought i think i came up with a possible solution to the problem :there is a thing called bridges, they are used to access the tor network without your isp knowing that you use tor, but if you can use those proxies to enter the network, it might also be possible to exit the network with them. But then we face a second challenge, the exit nodes have to be configured in such a way that it will relay traffic to such a bridge, so the exit node owners also need to know the ip of the bridge. While this doesn't seem difficult to do, it can become difficult. You see if the bridges are published on a public list(like normal bridges are) then the blocking sites in question will be able to block those address too. While this also posses a problem, a possible solution could be found in something called flashproxies, flashproxies are bridges with a really short life span, they are created and destroyed fairly swiftly, when this is done in a rapid pace, they become really hard to block because the ip changes all the time. So if the exit nodes can be configured to make use of such flash proxies, then the problem could be solved. I Must admit that not an expert on this or anything, and it needs alot of more thought, but it could work. so i was wondering if there are any experts who could help me with thinking out this subject and maybe confirm if this idea could work. greetings, blacklight

3 4

Fwd: Re: Support for mix integration research
by Sebastian G. <bastik.tor> 25 Feb '16

25 Feb '16

I'm forwarding this to the list, because it might contain relevant information. Mostly within George's reply. Initial reason to not send my reply to the list was to not bother too many people with seemingly irrelevant questions on my part. I agree with the reply given in the forwarded message. It has to be considered what 'it' does to the network. Best Regards, Sebastian G. (bastik) -------------- Forwarded Message -------------- Subject: Re: [tor-dev] Support for mix integration research Date: Thu, 25 Feb 2016 19:58:56 +0100 From: George Kadianakis <desnacked(a)riseup.net> To: Sebastian G. <bastik.tor> <bastik.tor(a)googlemail.com> "Sebastian G. <bastik.tor>" <bastik.tor(a)googlemail.com> writes: > 25.02.2016, 13:08 George Kadianakis: >> b) Does this increase the hard disk or memory requirement of people running Tor >> relays? That is in high-latency mode, will Tor relays need to store client's >> traffic for longer? How does that impact the memory and hard disk >> requirement of people running Tor relays? > > Hello, > > this has been intentionally sent off list. > > I just don't understand the question. How would you delay traffic > without storing it for longer? Whenever in memory or disk, the data that > are being delayed have to be stored somewhere, as far as I understand. > > Could one delay traffic on a wire? E.g. like with a truck that drives on > a road between two storage facilities where you couldn't say it is > already stored in the facilities. > > I fail to see how it would be possible to have a system that delays > something without holding back whatever is delayed. > I agree. I'm wondering how this increases the memory and hard disk requirement of running a relay. And how much would the current relays contribute to such a high-latency system? And how much memory / CPU will be required to contribute meaningfully to this. And what about DDoS opportunities? All these things will need to be thought of so that we don't overwhelm the current Tor network by introducing this high-latency mode. Because if that's the case, we should probably have a separate network for the high-latency mode. Pity you replied off list, this conversation is of sufficient interest. Cheers. > If you currently take in x and give out y at the same rate, what needs > to be stored is what has to be buffered. If now the rate of y decreases > while the rate for x remains the same, more stuff needs be buffered. > Unless you reduce the rate for x, more storage is required. > > Sorry, I just don't get it. Please show me where my error is. Can be > short. :) >

1 0

Fwd: Downloadable content: Fonts!
by Nathan Freitas 25 Feb '16

25 Feb '16

Mozilla is adding some new runtime installation features to reduce the size of the mobile Firefox APK. Is this happening at all on desktop? It makes me nervous as the "default" config could very much more greatly, not to mention having a new centralized attack channel. ----- Original message ----- From: Sebastian Kaspari <s.kaspari(a)gmail.com> To: "mobile-firefox-dev" <mobile-firefox-dev(a)mozilla.org> Subject: Downloadable content: Fonts! Date: Fri, 19 Feb 2016 11:56:42 +0000 Good news, everyone! Our first step to downloadable content has been enabled in Nightly: This means we now stopped to ship fonts[1] in the APK and instead download them at runtime (Bug 1194338 [2]). With that we reduced the size of the APK by roughly 6.4% (~ 2.7MB) [3]. Without having the fonts downloaded (yet) our users can still browse websites but they may look less nice. And in fact, as things go, a bug caused just that to happen in Nightly (We don't download any fonts): bug 1249354 [4]. So if websites are currently looking a bit weird on Nightly then that's because of that. The bug should be resolved soon and after that let me know if you see any new weird issues related to (wrong) fonts. :) Our plans for the future: * Right now we ship the list of fonts and the location to download with the application. We want to synchronize this catalog of content from a Kinto instance: https://bugzilla.mozilla.org/show_bug.cgi?id=1201059 * We want to download hyphenation dictionaries at runtime too: https://bugzilla.mozilla.org/show_bug.cgi?id=1095719 * Eventually we might even want to download (some) localization files at runtime: https://bugzilla.mozilla.org/show_bug.cgi?id=945123 Best, Sebastian [1] https://www.youtube.com/watch?v=6J2rrFiN1Jw [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 [3] https://twitter.com/Anti_Hype/status/699905577196134400 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1249354 _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev

5 7

Tor Consensus Transparency, take two
by Linus Nordberg 25 Feb '16

25 Feb '16

Hi, Some time ago, like 1,5 years, this list received a proposal for how to build Tor Consensus Transparency. I got some good feedback and then i got busy with other things. Here's an updated version with feedback incorporated, change in wordings, more of an actual specification, some changes in data structures and over all an easier read, I hope. I'll follow up shortly with a separate email describing the status of an experimental implementation. --8<---------------cut here---------------start------------->8--- Filename: xxx-tor-consensus-transparency.txt Title: Tor Consensus Transparency Author: Linus Nordberg Created: 2014-06-28 Status: Draft 0. Introduction This document describes how to provide and use public, append-only, verifiable logs containing Tor consensus and vote status documents, much like what Certificate Transparency [CT] does for TLS certificates, making it possible for log monitors to detect false consensuses and votes. Tor clients and relays can refuse using a consensus not present in a set of logs of their choosing, as well as provide possible evidence of misissuance by submitting such a consensus to any number of logs. 1. Overview Tor status documents, consensuses as well as votes, are stored in one or more public, append-only, externally verifiable log using a history tree like the one described in [CrosbyWallach]. Consensus-users, i.e. Tor clients and relays, expect to receive one or more "proof of inclusions" with new consensus documents. A proof of inclusion is a hash sum representing the tree head of a log, signed by the logs private key, and an audit path listing the nodes in the tree needed to recreate the tree head. Consensus-users are configured to use one or more logs by listing a log address and a public key for each log. This is enough for verifying that a given consensus document is present in a given log. Submission of status documents to a log can be done by anyone with an internet connection (and the Tor network, in case of logs only on a .onion address). The submitter gets a signed tree head and a proof of inclusion in return. Directory authorities are expected to submit to one or more logs and include the proofs when serving consensus documents. Directory caches and consensus-users receiving a consensus not including a proof of inclusion may submit the document and use the proof they receive in return. Auditing log behaviour and monitoring the contents of logs is performed in cooperation between the Tor network and external services. Relays act as log auditors with help from Tor clients gossiping about what they see. Directory authorities are good candidates for monitoring log content since they know what votes they have sent and received as well as what consensus documents they have issued. Anybody can run both an auditor and a monitor though, which is an important property of the proposed system. 2. Motivation Popping a handful of boxes (currently five) or factoring the same number of RSA keys should not be ruled out as a possible attack against a subset of Tor users. An attacker controlling a majority of the directory authorities signing keys can, using man-in-the-middle or man-on-the-side attacks, serve consensus documents listing relays under their control. If mounted on a small subset of Tor users on the internet, the chance of detection is probably low. Implementation of this proposal increases the cost for such an attack by raising the chances of it being detected. Note that while the proposed solution gives each individual some degree of protection against using a false consensus this is not the primary goal but more of a nice side effect. The primary goal is to detect correctly signed consensus documents which differ from the consensus of the directory authoritites. This raises the risk of exposure of an attacker capable of producing a consensus and feed it to users. The complexity of the proposed solution is motivated by the fact that the log key is not just another key on top of the directory authority keys since the log doesn't have to be trusted. Another value is the decentralisation given -- anybody can run their own log and use it. Anybody can audit all existing logs and verify their correct behaviour. This empowers people outside the group of Tor directory authority operators and the people who trust them for one reason or the other. 3. Design Communication with logs is done over HTTP using TLS or Tor onion services for transport, similar to what is defined in [rfc6962-bis-12]. Parameters for POSTs and all responses are encoded as name/value pairs in JSON objects [RFC4627]. Summary of proposed changes to Tor: - Configuration is added for listing known logs and for describing policy for using them. - Directory authorities start submitting newly created consensuses to at least one public log. - Tor clients and relays receiving a consensus not accompanied by a proof of inclusion start submitting that consensus to at least one public log. - Consensus-users start rejecting consensuses accompanied by an invalid proof of inclusion. - A new cell type LOG_STH is defined, for clients and relays to exchange information about seen tree heads and their validity. - Consensus-users send seen tree heads to relays acting as log auditors. - Relays acting as log auditors validate tree heads (section 3.2.2) received from consensus-users and send results back. - Consensus-users start rejecting consensuses for which valid proofs of inclusion can not be obtained. Definitions: - Log id: The SHA-256 hash of the log's public key, to be treated as an opaque byte string identifying the log. 3.1. Consensus submission Logs accept consensus submissions from anyone as long as the consensus is signed by a majority of the Tor directory authorities of the Tor network that it's logging. Consensus documents are POST:ed to a well-known URL as defined in section 5.2. The output is what we call a proof of inclusion. 3.2. Verification 3.2.1. Log entry membership verification Calculate a tree head from the hash of the received consensus and the audit path in the accompanying proof. Verify that the calculated tree head is identical to the tree head in the proof. This can easily be done by consensus-users for each received consensus. We now know that the consensus is part of a tree which the log claims to be The Tree. Whether this tree is the same tree that everybody else see is unknown at this point. 3.2.2. Log consistency verification Ask the log for a consistency proof between the tree head to verify and a previously known good tree head from the pool. Section 5.3 specifies how to fetch a consistency proof. [[TBD require auditors to fetch and store the tree head for the empty tree as part of bootstrapping, in order to avoid the case where there's no older tree to verify against?]] [[TODO description of verification of consistency goes here]] Relays acting as auditors cache results to minimise calculations and communication with log servers. [[TBD have clients verify consistency as well? NOTE: we still want relays to see tree heads in order to catch a lying log (the split-view attack)]] We now know that the verified tree is a superset of a known good tree. 3.3. Log auditing A log auditor verifies two things: - A logs append-only property, i.e. that no entries once accepted by a log are ever altered or removed. - That a log presents the same view to all of its users [[TODO describe the Tor networks role in auditing more than what's found in section 3.2.2]] A log auditor typically doesn't care about the contents of the log entries, other than calculating their hash sums for auditing purposes. Tor relays should act as log auditors. 3.4. Log monitoring A log monitor downloads and investigates each entry in a log searching for anomalies according to its monitoring policy. This document doesn't define monitoring policies but does outline a few strategies for monitoring in section [[TBD]]. Note that there can be more than one valid consensus documents for a given point in time. One reason for this is that the number of signatures can differ due to consensus voting timing details. [[TODO Are there more reasons?]] [[TODO expand on monitoring strategies -- even if this is not part of the proposed extensions to the Tor network it's good for understanding. a) dirauths can verify consensus documents byte for byte; b) anyone can look for diffs larger than D per time T, where "diffs" certainly can be smarter than a plain text diff]] 3.5. Consensus-user behaviour [[TODO move most of this to section 5]] Keep an on-disk cache of consensus documents. Mark them as being in one of three states: LOG_STATE_UNKNOWN -- don't know whether it's present in enough logs or not LOG_STATE_LOGGED -- have seen good proof(s) of inclusion LOG_STATE_LOGGED_GOOD -- confident about the tree head representing a good tree Newly arrived consensus documents start in UNKNOWN or LOGGED depending on whether they are accompanied by enough proofs or not. There are two possible state transitions: - UNKNOWN --> LOGGED: When enough correctly verifying proofs of inclusion (section 3.2.1) have been seen. The number of good proofs required is a policy setting in the configuration of the consensus-user. - LOGGED --> LOGGED_GOOD: When the tree head in enough of the inclusion proofs have been verified (section 3.2.2) or enough LOG_STH cells vouching for the same tree heads have been seen. The number of verifications required is a policy setting in the configuration of the consensus-user. Consensuses in state UNKNOWN are not used but are instead submitted to one or more logs. If the submission succeeds, this will take the consensus to state LOGGED. Consensuses in state LOGGED are used despite not being fully verified with regard to logging. LOG_STH cells containing tree heads from received proofs are being sent to relays for verification. Clients send to all relays that they have a circuit to, i.e. their guard relay(s). Relays send to three random relays that they have a circuit to. 3.6. Relay behaviour when acting as an auditor In order to verify the append-only property of a log, relays acting as log auditors verify the consistency of tree heads received in LOG_STH cells. An auditor keeps a copy of 2+N known good tree heads in a pool stored on persistent media [[TBD where N is either a fixed number in the range 32-128 or is a function of the log size]]. Two of them are the oldest and newest tree heads seen, respectively. The rest, N, are randomly chosen from the tree heads seen. [[TODO describe or refer to an algorithm for "randomly chosen", hopefully not subjective to flushing attacks (or other attacks)]]. 3.7. Notable differences from Certificate Transparency - The data logged is "strictly time-stamped", i.e. ordered. - Much shorter lifetime of logged data -- a day rather than a year. Is the effects of this difference of importance only for "one-shot attacks"? - Directory authorities have consensus about what they're signing -- there are no "web sites knowing better". - Submitters are not in the same hurry as CA:s and can wait minutes rather than seconds for a proof of inclusion. 4. Security implications TODO 5. Specification 5.0. Data structures Data structures are defined as described in [RFC5246] section 4, i.e. TLS 1.2 presentation language. While it is tempting to try to avoid yet another format, the cost of redefining the data structures in [rfc6962-bis-12] outweighs this consideration. The burden of redefining, reimplementing and testing is extra true for those structures which need precise definitions because they are to be signed. 5.1. Signed Tree Head (STH) An STH is a TransItem structure of type "signed_tree_head" as defined in [rfc6962-bis-12] section 5.8. 5.2. Submitting a consensus document to a log POST https://<log server>/tct/v1/add-consensus Input: consensus: A consensus status document as defined in [dir-spec] section 3.4.1 [[TBD gziped and base64 encoded to save 50%?]] Output: sth: A signed tree head as defined in section 5.1 refering to a tree in which the submitted document is included. inclusion: An inclusion proof as specified for the "inclusion" output in [rfc6962-bis-12] section 6.5. 5.3. Getting a consistency proof from a log GET https://<log server>/tct/v1/get-sth-consistency Input and output as specified in [rfc6962-bis-12] section 6.4. 5.x. LOG_STH cells A LOG_STH cell is a variable-length cell with the following fields: TBDname [TBD octets] TBDname [TBD octets] TBDname [TBD octets] 6. Compatibility TBD 7. Implementation TBD 8. Performance and scalability notes TBD A. Open issues / TODOs - TODO: Add SCTs from CT, at least as a practical "cookie" (i.e. no need to send them around or include them anywhere). Logs should be given more time for distributing than we're willing to wait on an HTTP response for. - TODO: explain why no hash function and signing algorithm agility, [[rfc6962-bis-12] section 10 - TODO: add a blurb about the values of publishing logs as onion services - TODO: discuss compromise of log keys B. Acknowledgements This proposal leans heavily on [rfc6962-bis-12]. Some definitions are copied verbatim from that document. Valuable feedback has been received from Ben Laurie, Karsten Loesing and Ximin Luo. C. References [CrosbyWallach] http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf [dir-spec] https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt [RFC4627] https://tools.ietf.org/html/rfc4627 [rfc6962-bis-12] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/12 [CT] https://https://www.certificate-transparency.org/ --8<---------------cut here---------------end--------------->8---

2 1

Support for mix integration research
by Katharina Kohls 25 Feb '16

25 Feb '16

Hi everyone, we are a team of 4 PHD students in the field of IT security, working at the Ruhr-University Bochum at the chair for systems security and the information security group. Currently we work on a research project with the goal to leverage the security of Tor against timing attacks by integrating mixes in Tor nodes. The general idea is to differentiate high-latency and low-latency traffic among the network for applying additional delays to the former type of packets. Based on this the success of traffic analysis attacks should be decreased without restricting the low latency assurance of Tor. We plan to integrate the mix into Tor version 0.2.5.10 and analyze its performance along with the Shadow simulator. As there are a lot of details to consider, both regarding the technical aspects of the integration as well as practical assumptions, e.g., "how do we get DiffServ-like nodes?", we would be pleased to receive some feedback on the idea and support for the implementation of the mix. Further details on the mix and stuff will sure be provided if needed! Cheers, Katharina -- M.Sc. Katharina Kohls Ruhr-University Bochum Research Group Information Security Universitätsstrasse 150 ID 2/123 44780 Bochum / Germany Phone: +49 234 / 32 - 26991 Web: www.infsec.rub.de

4 4

Nyx Project Ideas
by Damian Johnson 25 Feb '16

25 Feb '16

Hi wonderful relay operators. It's GSoC season again, where students can be funded to make open source projects like Tor even better! Nyx (previously known as arm [1]) has been my main focus this last year and is inching ever closer to release. For those unfamiliar with it, Nyx is an ncurses monitor for Tor relays providing a bandwidth graph, event log, connections, config editor, and more. Rather than add new features my work has focused on making Nyx simpler and faster, but GSoC provides us an opportunity to do even more. So I'm curious - what do you want from an ncurses monitor? The answer may be 'keep it simple'. Feature creep does us no favors. But if there's a good fit I'd love to mentor a project that makes your lives even better! I'm not overly fond of the ideas I've had so far... * Windows support. This poses a few challenges. [2] * When running multiple tor instances on a single system connect to them all, aggregating the information. So anything come to mind? Cheers! -Damian [1] https://www.atagar.com/arm/ [2] https://trac.torproject.org/projects/tor/wiki/doc/arm#Windows

1 0

Tor consensus documents now in a public append-only verifiable log
by Linus Nordberg 24 Feb '16

24 Feb '16

Hi, One of the directory authoritites (maatuska) is submitting new consensus documents to a public append-only verifiable log, similar to what Certificate Transparency uses. If you think this is exciting and want to help out with this experiment, consider setting up a monitor and start looking for anomalies, or at least an auditor verifying proper log behaviour. Or help making the submission code in Tor more useful (f.ex. submitting to the log's .onion address, submitting votes too, making the POST chunked). Below are two examples of how to investigate what's in the log so far. Fetching one document, using curl --------------------------------- Here's an example of how to fetch the 80th entry in the log: $ curl -sA '' -x socks4a://localhost:9050/ 'http://mvkhztpvqcxpdbn3.onion/open/gaol/v1/get-entries?start=79&end=79' The result is a large JSON document (~740kB): --8<---------------cut here---------------start------------->8--- { "entries" : [ { "leaf_input" : "AAAAAAFTA+pimwAACHcGH4sIAAAAAAACA+y96XLi2rYu+H8/hX7WDTKN+sa [...] rUcfehxefa/xjpqq45E6dZEPzPosd1cg8mSGi03G/r+LikK1rl7GQ/I7yOzvfvGm3jeWrD/g6++f2yN9oeI7dH+31/w3O7wS+HI8YAAAA", "extra_data" : "AAAA" } ] } --8<---------------cut here---------------end--------------->8--- "leaf_input" contains a gziped, base64 encoded Tor consensus document. Note that this format _will_ change in the future! Fetching all documents, using fetchallblobs.py from catlfish ------------------------------------------------------------ Given a local copy of branch gaol6 of catlfish in my private repo [1] and a copy of the public key for the log [2], here's how to download all the entries from the log and store them in ZIP files in directory 'gaol-store': $ torsocks catlfish/tools/fetchallblobs.py --store gaol-store --publickey logs gaol.ct.nordu.net.pem http://mvkhztpvqcxpdbn3.onion/ The base64 encoded entry can be extracted using this awk script: /-----END BLOB-----/{blob=0} //{if (blob) print} /-----BEGIN BLOB-----/{blob=1} Feeding that to base64 -d and gzip -d should produce a Tor consensus document. For example: $ cat 00000080 | awk '/-----END BLOB-----/{blob=0}//{if (blob) print}/-----BEGIN BLOB-----/{blob=1}'| base64 -d | gzip -d [1] $ git clone -b gaol6 https://git.nordu.net/user/linus/catlfish.git [2] https://www.ct.nordu.net/gaol.ct.nordu.net.pem https://www.ct.nordu.net/gaol.ct.nordu.net.pem.asc

1 0

Post-quantum symetric crypto
by Jeff Burdges 22 Feb '16

22 Feb '16

Symmetric crypto might start worrying more about being post-quantum soon : http://arxiv.org/abs/1602.05973 Best, Jeff

1 0

Help with TOR on UDP/QUIC
by Xiaofan Li 20 Feb '16

20 Feb '16

Hi everyone: I'm new to Tor dev community and my name is Xiaofan Li, currently a senior at Carnegie Mellon University studying ECE and CS. My friend Kevin Ku and I are taking a graduate class <http://www.cs.cmu.edu/%7Esrini/15-744/S16/> on computer networks and we decided to examine the possibilities of substituting TCP with the Google QUIC protocol for Tor in order to improve performance. We are emailing you because: 1. We want to get some points of contact with the Tor community in case of future integration and/or testing. 2. We want to know if *anyone else* has done (or is doing) Tor with QUIC. If so, what their status is; and if not, why not? 3. We want to get *your opinions* on this idea. Attached is our (very) preliminary plan and goals for the project. Any feedback is welcomed. 4. Any *implementation recommendations*. My plan is to find a clean layer of abstraction where I can substitute TCP with QUIC. Any ideas? On a first look, I'm thinking about either *or/channel.c* or *or/transports.c * 5. Any *testing suggestions*? How do Tor engineers test new stuff? Please take a look at our outline attached below. Thank you! Looking forward to hearing from you soon! Li.

3 3