Re: [tor-dev] KIST somewhat implemented
Thanks for getting this started, Nick! I’ve added some comments and changes to the trac ticket #12890. All the best, Rob > On Dec 20, 2014, at 12:51 PM, Nick Mathewson wrote: > > Hi! > > So, Rob came up with this clever way to use help from an OS kernel to > improve Tor's performance: > > http://www.robgjansen.com/publications/kist-sec2014.pdf > > I've got a sketchy implementation together now. > > See my comments on the end of ticket 12890. I have a branch which I > believe implements something like the KIST algorithm for Linux as I > discussed with Rob. I made a list of not-yet-implemented issues. > > Rob, could you please let me know which of the issues I listed need to > be fixed before this is reasonably testable? > > cheers, > -- > Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] N reasons why the spooks love Tribler (Number N' will surprise you)
On Sat, Dec 20, 2014 at 2:09 PM, Nick Mathewson wrote: > On Sat, Dec 20, 2014 at 4:56 AM, Yawning Angel > wrote: > And I think that the CREATE cell handler's code's implementation of > the (deprecated) TAP protocol is vulnerable to the timing attack > discussed in Goldberg's "On the Security of the Tor Authentication > Protocol". Whoops. This paper didn't have a timing attack in it. I don't know what I was thinking of when I wrote this paragraph. I think I was misremembering which modifications the paper said that would have made TAP vulnerable. (Thanks to Ian for pointing this out to me.) -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] N reasons why the spooks love Tribler (Number N' will surprise you)
On Sat, Dec 20, 2014 at 4:56 AM, Yawning Angel wrote: [...] > * How not to do Diffie-Hellman: > >key = pow(dh_received, dh_secret, DIFFIE_HELLMAN_MODULUS) > >This is relatively minor since recovering the secret key is trivial >via PRNG attacks, so the fact that the modular exponentiation is not >constant time matters less. Additionally, I don't believe their code checks that the dh_secret value is actually in [2..(p-1)], which enables an attack if the node receiving an EXTEND cell replaces enc(g^x) and g^y with enc(1), 1 respectively. This makes the circuit crypto more or less pointless. And I think that the CREATE cell handler's code's implementation of the (deprecated) TAP protocol is vulnerable to the timing attack discussed in Goldberg's "On the Security of the Tor Authentication Protocol". > Recommendations: > > * For users, "don't". Cursory analysis found enough fundamental >flaws, and secure protocol design/implementation errors that I would >be reluctant to consider this secure, even if the known issues were >fixed. It may be worth revisiting in several years when the >designers obtain more experience, and a thorough third party audit >of the improved code and design has been done. Yeah. To be clear, if you had reviewed Tor in 2004, you would have found a lot of horrible mistakes too. Software gets better, and programmers get better. This one has a long way to go, but if they keep at it, it will eventually get there. (Honestly, I find that the best way to put this kinds of mistakes into context is to put a huge disclaimer on the front of all new software, so that people will know not to use it until it's had a lot of attention.) -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] KIST somewhat implemented
Hi! So, Rob came up with this clever way to use help from an OS kernel to improve Tor's performance: http://www.robgjansen.com/publications/kist-sec2014.pdf I've got a sketchy implementation together now. See my comments on the end of ticket 12890. I have a branch which I believe implements something like the KIST algorithm for Linux as I discussed with Rob. I made a list of not-yet-implemented issues. Rob, could you please let me know which of the issues I listed need to be fixed before this is reasonably testable? cheers, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] N reasons why the spooks love Tribler (Number N' will surprise you)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Yawning Angel wrote: > Hello all, > > Recently a decentralized onion-routing based Bittorrent client > known as Tribler has made rounds through the clickbait > garbage^w^wtech journalism sites. Since protocol design is a > research interest of mine, I did some casual analysis based off the > documentation and publicly available source code. Thank you for taking the time to write this; I'm sure I speak for many when I say that your contributions are greatly appreciated :) If this is "casual analysis", I shudder to think what you would find during office hours :-P Perhaps it could be posted on the Cryptography Coding Standard wiki [0] as an example of what not to do? > Most of the fixes require major revisions to the wire protocol. > As it appears that there is no versioning, how that will be done > is left as an exercise for the student. > > Alternatively, rebase the system on I2P. If they did choose to rebase on I2P, they would be able to integrate with the existing I2P torrent swarms. In case the Tribler developers are following this ML, the protocol details common to all BitTorrent clients on I2P are documented in [1]. str4d [0] https://cryptocoding.net/ [1] https://geti2p.net/en/docs/applications/bittorrent -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJUlV4AAAoJEIA97kkaNHPnZFoP/iSsUzDBUsgApq6XC0o3TMlt SpjTEvYkuK4xq2wLEcggu+eX7ZOTQFLPjIocIfSkkPuj4DDT0/Esyg9/Fo55BsmQ xHN6u6CaaDNCe2VdnCm1T93MFUL9hTIvVV+hXaF78QIrbp2+g5swOpuBl8ePnMhX +YcBQ/T3mPMhKSBbDAQgRMl5vYovpu2ET2dYb0hhJcwtZ0OVSKlRSH0NJCrCH/KB UpJCI4gSj731POUhuKVUE6oYc6ZlUJt6262sRFAyLOuej+gHlcYtXrsNjX1zOKTV /vs0X6DeyYJlLD6gfNpZuDVZNA/a0zRJTuoK0imHwFIUQDuIXqPq3yTs8xcFcCtS 5PWjQKXgrOfN/ifwTqRaQHKm9UXaOFAkNDCfjGui+cftncZ0VquJBnsQFW6KbngK N+1+QetXk8RQ36IyBq9H7j6uqSMTfPQiBVUFWec9GcqWaruLRRcLj5IGFTHgiAGt KYd6bYgMFwUUTVVOTj0dgeeCqfFBdzR12rSzb3SzlXq/i8UgFcuIn5cw5p3TfWYm LN6twG5i8tK6F2U6TNaakbmih6xMVRMUBbV/EleBrIYdQeTYG8FvAsGQQ70r0kzz nBCiuAWYRN7EWNtmKClNJGj0GTe4gwN+0et6g0HmVqMerw+4tPAJ8exWvuJNT0e8 0EYzbEfMRcG61zVgNIPI =xhxt -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] N reasons why the spooks love Tribler (Number N' will surprise you)
Hello all, Recently a decentralized onion-routing based Bittorrent client known as Tribler has made rounds through the clickbait garbage^w^wtech journalism sites. Since protocol design is a research interest of mine, I did some casual analysis based off the documentation and publicly available source code. Disclaimer: Analysis was casual and not massively in-depth though I believe it to be correct. Known issues are highlighted as such, though there is a decent amount of new material. References to how Tor approaches certain design problems are provided as appropriate. TLDR: Do not use this if your threat model includes active attackers, adversaries versed in cryptography, those with lots of money, or if you wish to be anonymous. Material covered: * The protocol documentation located at https://github.com/Tribler/tribler/wiki/Anonymous-Downloading-and-Streaming-specifications * The source code of the "devel" branch https://github.com/Tribler/tribler/tree/devel/Tribler as of commit a98db38f60550dd304d1e329e16a41a683666c15 Protocol flaws: * There is no built in safeguard against creating circuits of arbitrary lengths. The subset of the Tor protocol the Tribler designers implemented is lacking a RELAY_EARLY type construct. Active adversaries can exploit this flaw to create substantial load on the Tribler network, and mount certain kinds of attacks. See: * Proposal 110 " Avoiding infinite length circuits" (https://gitweb.torproject.org/torspec.git/tree/proposals/110-avoid-infinite-circuits.txt) * Evans, S., Dingledine, R., Grothoff, C. "A Practical Congestion Attack on Tor Using Long Paths" (http://grothoff.org/christian/tor.pdf) * The symmetric encryption is ECB-AES128, without authentication. The former is a documented flaw in the specification and is claimed that it is "for testing", with what looks like a skeletal attempt to use OFB-AES128 present in the code. ECB should not go on the wire ever and is only useful as a building block for other modes. Even as a "for testing" this is rather sloppy, and is something that should have been addressed way before real users start using the protocol. The skeletal OFB-AES128 implementation included in dead code is not any better as it reuses a hard coded initialization vector for every single encryption operation. IV reuse within a given key across encryption operations breaks the confidentiality of the mode. The lack of authentication is flat out inexcusable for reasons that should be obvious. It is worth noting that this is one of the kludgier bits of the Tor wire protocol currently (see the 'digest' and 'recognized' fields in each RELAY cell, and proposals/ideas/xxx-new-crypto-sketch.txt), so improvements over "what Tor does" are possible and recommended. Implementation flaws: (As an aside, it's somewhat difficult to sort through which parts of the cryptography code are actually used and which are not.) * When gmpy is not present, Diffie-Hellman keys are generated with python's random.randint(). This is issue #874, and it should be evident why this is incorrect, and utterly terrible. The fact that developer comments regarding this bug note that this fallback is present only because gmpy did not work on Android should raise massive red flags in light of the next issue. * When gmpy *is* installed, Diffie-Hellman keys are generated with gmpy's "rand()". while dh_secret >= DIFFIE_HELLMAN_MODULUS or dh_secret < 2: dh_secret = rand("next", DIFFIE_HELLMAN_MODULUS) As far as I can tell, gmpy's rand() is either unseeded or is seeded via the following idiom that is scattered throughout the code (I suspect it is the latter, due to the Paillier cryptosystem code being cross referenced from other modules, but it's hard to tell): # The definition of StrongRandom changes depending on the file. # But every file that uses the construct illustrated here pulls it # in from optional_crypto, which looks like: # try: # raise ImportError() # # Dead code, this would be slightly less horrific, maybe. # from Crypto.Random.random import StrongRandom # except ImportError: # # ... Words can not describe how sad I am. # from random import Random as StrongRandom from optional_crypto import StrongRandom from sys import maxint rand('init', 128) rand('seed', StrongRandom().randint(0, maxint)) The unseeded case results in a LCG of the form: x = 1 // Yes, a hard coded seed. x = (29CF535 * x + 1) % (2^32) It should be obvious as to why this is totally broken. The seeded case results in a LCG of the form: x = (48A74F367FA7B5C8ACBB36901308FA85 * x + 1) % (2^128) This is fatally broken and insecure on several fronts. a) "StrongRandom" is Mersenne Twister seeded once via os.urandom(). Wha