Hi Lennart, Thanks for publicly posting this question. Below are some papers. Perhaps I have missed something and someone on this list will hopefully decide to be helpful and tell us.
Roger of Tor Project wrote a blog post on this topic: https://blog.torproject.org/one-cell-enough-break-tors-anonymity In that post he mentioned several papers: The Traffic Analysis of Continuous-Time Mixes by George Danezis https://www.freehaven.net/anonbib/cache/danezis:pet2004.pdf Approximating a Global Passive Adversary Against Tor by Chakravarty, Sambuddho; Stavrou, Angelos; Keromytis, Angelos D. https://academiccommons.columbia.edu/doi/10.7916/D82J6QBM How Much Anonymity does Network Latency Leak? by NICHOLAS HOPPER EUGENE Y. VASSERMAN ERIC CHAN-TIN https://www.freehaven.net/anonbib/cache/tissec-latency-leak.pdf I continued looking for more papers and found this: Analyzing the Effectiveness of Passive Correlation Attacks on the Tor Anonymity Network by Sam DeFabbia-Kane https://pdfs.semanticscholar.org/17a6/736b5b8d9a2e516adbebb338e3265681b1c9.pdf Sincerely, David On Sun, Jan 27, 2019 at 01:20:57AM +0100, Lennart Oldenburg wrote: > Hi David, > > Could you (or the larger group here) point me to the paper that > trivially deanonymizes Tor users with timing attacks in a few seconds > once conducted by a global adversary? > > I heard that argument before and am currently trying to find the > academic reference it is based on. > > Thanks a lot in advance! > > Best > Lennart > > On 24/01/2019 21.56, dawuud wrote: > > > > Hi Markus, > > > > It's kinda cool your thorough defense of endpoint security. > > Certainly I agree with you that endpoint security is important. > > But since we are on a mailing list that is obstensibly about > > solving messaging problems I will focus my comments on these issues instead. > > > > I'd like to point out that the secure messaging problem isn't really solved > > yet > > because there is currently no deployed encrypted messaging applications > > that provide > > traffic analysis resistance against global adversaries. This of course > > includes Tor > > which can trivially be broken in just a few seconds using timing > > correlation. > > And to make a more nuanced point, so called "secure messaging" applications > > should be using multiple security domains; currently this is my main > > criticism > > of Signal messenger besides requiring the use of phone numbers. > > > > I feel totally justified on harping on this one point until we arrive > > at a good solution because ex-NSA director, Michael Hayden is famously > > quoted as having said: "We kill people based on meta-data". > > > > Onion services do hide geographical location from adveraries that > > are unable to break Tor. But is this really an appropriate threat model? > > Do you think colluding nation state adversaries cannot break Tor? > > The conclusions of the academic literature on these points are quit clear > > and there is over 37 years of published academic literature on the topic > > of anonymous messaging. Many of these papers describe systems that > > have far stronger threat models than Tor, things like: > > > > * decryption mix networks > > * verified mix shuffles > > * private information retrieval > > * dining cryptographer networks > > * broadcast based designs (with trial decryption) > > * oblivious random access memory > > * secure multi-party computation > > > > I don't understand why you decided to use the term "traffic masking". > > Isn't this "traffic padding"? > > > > Without a proper statistical model to assist in tuning it's not clear > > how much this will help. I should mention that Tor Project is very > > interested in using traffic padding in future versions of Tor and > > they wish to encourage academics to explore this possibility. Clearly, > > it will take at least one PhD worth of research to establish safety > > margins in the use of traffic padding for Tor and I suspect discrete > > network event > > simulators will help with this. > > > > > > Cheers, > > David > > > > On Thu, Jan 24, 2019 at 05:27:39PM +0200, Markus Ottela wrote: > >> Hi! > >> > >> The traffic here is quite low so I hope it's ok if I post my work: > >> > >> TFC (https://github.com/maqp/tfc) is something I've worked on since spring > >> 2012. The idea was to create a messaging system that splits the TCB on two > >> airgapped computers that communicate with a networked computer via > >> unidirectional gateways. To enforce the unidirectional behavior it's using > >> a > >> simple circuit that for each direction uses an optocoupler as an optical > >> repeater in the middle of a serial gateway: The photoelectric effect in > >> LEDs > >> is inefficient, and the photodiodes do not emit light, so the IC only works > >> in one way. > >> > >> This hardware layout prevents remotely inserted malware from entering the > >> Source Computer (that outputs ciphertexts). It also prevents the malware > >> from exfiltrating keys/plaintexts from the Destination Computer (that > >> decrypts incoming messages). The Networked Computer only ever sees > >> non-sensitive data like ciphertexts and public keys. > >> > >> On Networked Computer the relay program runs a v3 Onion Service and web > >> clients needed to request data from Onion Services of contacts. In this > >> respect it's similar to Ricochet: There is no server in the middle to tap. > >> > >> As for cryptographic primitives, TFC uses single X448 (OpenSSL > >> implementation) that by default prompts the user to verify base10 > >> fingerprints. XChaCha20-Poly1305 (libsodium implementation) has per-message > >> forward secrecy that relies on BLAKE2b hash ratchet. Keys are generated > >> with > >> GETRANDOM syscall. All sensitive persistent data on endpoints is encrypted > >> with the same XChaCha, and the key for it is derived from salt and password > >> using Argon2d. > >> > >> Since during key exchange the public key needs to be typed manually into > >> the > >> Source Computer, DH ratchet and thus future secrecy isn't practical. The > >> user can of course re-exchange keys whenever they like it. The lack of > >> future secrecy is compensated by the architecture that prevents key > >> exfiltration. > >> > >> The application is written in Python (3.6), is FOSS, and the HW is Free > >> Hardware Design (circuit diagrams and step-by-step build instructions are > >> available). The code has type annotations and I've tried to make good unit > >> tests for it. > >> > >> For metadata protection I tried to make TFC to install anonymously. Onion > >> Services hide geo-location and identity of the users. I've also added an > >> optional traffic masking feature that locks Transmitter Program to a > >> selected contact/group, and sends a continuous stream of noise packets to > >> those recipients. Files and messages are inserted into the noise stream > >> when > >> needed. This should hide quantity, schedule, and type of communication even > >> from an adversary that compromises the Networked Computer of sender / > >> recipient. > >> > >> It's not perfect however. There's a bunch of attack vectors from Source > >> Computer compromise during install to covert exfiltration channels in > >> Destination Computer. I've tried to be as thorough as possible about these > >> risks in the threat model / security design articles, which you can find > >> from the project's wiki: https://github.com/maqp/tfc/wiki > >> > >> Any feedback / criticism is more than welcome! > >> > >> Markus
signature.asc
Description: PGP signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
