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 >> >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging >> >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
