[tor-dev] Comparing handshake protocols for Tor: Ace vs ntor
Hi, in WPES 2012 [2], Aniket Kate and me introduced Ace, an alternative for Tor's current handshake protocol ntor (which was also briefly discussed on this list [4]). Back then, no implementation for the double scalar multiplication operation (a * b + c * d) on Curve25519 was available. But recently, Robert Ransom implemented in his celator library [1] a highly efficient double scalar multiplication which is suitable for our handshake protocol Ace. In an internship with us, Shivanker Goel implemented and run comparative benchmarks of the Ace protocol, using Robert's celator library [1], and the current ntor implementation. Here are the benchmarks: 64-bit architecture: Ace: 401,129 cycles, ntor: 472,772 cycles, 32-bit architecture: Ace: 2,797,303 cycles, ntor: 5,179,069 cycles, About the benchmarks: * For cleaning the cache, the benchmarks runs the handshake 1000 times prior to starting the benchmarks. Then, we used a tsc_read() function to count the cycles, repeated the handshake 5000 times and computed the average of the cycles. * In order not to be forced to import too many functions from the Tor library, we do not use the function dimap_search, which looks up the secret key for a given public key, in the benchmarks. * We assume that ephemeral keys are precomputed, e.g., in idle cycles. In the benchmarks these ephemeral keys are received as an input. * For the benchmarks hyper-threading and overclocking were disabled and gcc-4.8 with "-O2" optimizations was used. The code is available online [2]. We also tried to formulate a tor-style proposal, which is also available online [3]. Any feedback, comments, or suggestions are welcome. - Esfandiar [1] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/celator.tar.gz [2] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/ace-benchmarks.tar.gz [3] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/ace-handshake.txt [4] It was discussed in the thread "Another key exchange algorithm for extending circuits: alternative to ntor?" from August 2012. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 223: Ace: Improved circuit-creation key exchange
Am 20.11.2013 um 18:19 schrieb Paul Syverson : > These authors found a > vulnerability in that protocol, improved on it, and proved their > protocol secure. Actually, Ian Goldberg, Douglas Stebila, and Berkant Ustaoglu found the vulnerability in Lasse and Paul's protocol [1], improved it, and proved the resulting protocol ntor secure [2]. We improved the efficiency of ntor and proved the resulting protocol Ace secure [3]. - Esfandiar [1] Lasse Overlier and Paul Syverson. Improving efficiency and simplicity of Tor circuit establishment and hidden services. In Proceedings of the 7th international conference on Privacy enhancing technologies, pages 134 - 152, ACM, 2007. [2] Ian Goldberg, Douglas Stebila, and Berkant Ustaoglu. Anonymity and one-way authentication in key exchange protocols. In the journal on Designs, Codes and Cryptography, pages 245-269, Springer, 2012. [3] Michael Backes, Aniket Kate, and Esfandiar Mohammadi. Ace: an efficient key-exchange protocol for onion routing. In Proceedings of the 2012 ACM workshop on Privacy in the electronic society, pages 55 - 64, ACM, 2012. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] MATor: A live-monitor for anonymity guarantees
Hi, tl;dr: we have a CCS paper coming up about a client-based live-monitor, called MATor [1], that assesses the influence of Tor's path selection to a user's anonymity. The paper is a first step towards a useful live-monitor that assesses a user's anonymity in a provable manner. We would appreciate your feedback on our approach and the direction in general. In detail, we implemented a live-monitor that computes upper bounds of the de-anonymization probability for sender, receiver, and relationship anonymity, based on Tor consensus data and the ports that the client needs. We formalized the guarantees that the live-monitor outputs in (an extension of) the AnoA framework [2] for circuit creation against passive attackers that do not control infrastructure (ASNs or IXPs). We use safe approximations in the live-monitor to be able to efficiently (a few seconds [3]) compute upper bounds for de-anonymization. At the moment the MATor monitor is a separate tool, but we are working on integrating it into the Tor client code. We envision an integration into Tor Browser Bundle. Since MATor is an ongoing project, we would appreciate your opinion about the approach in general. Best wishes, - Sebastian & Esfandiar [1] Michael Backes, Aniket Kate, Sebastian Meiser, Esfandiar Mohammad. (Nothing else) MATor(s): Monitoring the Anonymity of Tor's Path Selection. to appear in Proceedings of 21st ACM CCS, ACM, 2014. The MATor project page (containing the paper and the implementation): http://www.infsec.cs.uni-saarland.de/projects/anonymity-guarantees/mator.html [2] Michael Backes, Aniket Kate, Praveen Manoharan, Sebastian Meiser, and Esfandiar Mohammadi. AnoA: A Framework For Analyzing Anonymous Communication Protocols Unified Definitions and Analyses of Anonymity Properties. Proceedings of 26th IEEE CSF, pages 163-178, IEEE, 2013. The AnoA project page (containing the paper): http://www.infsec.cs.uni-saarland.de/~meiser/paper/anoa.html [3] The running time is as follows on a MacBook Air 2GHz Intel i7 with 4GB RAM: Preparation time: 3.39 seconds For sender anonymity: 0.73 seconds For recipient anonymity:6.07 seconds For relationship anonymity: 9.10 seconds signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
