On 05/10/2018 06:56 PM, Steve Kinney wrote: > > > On 05/10/2018 05:21 PM, juan wrote: >> On Wed, 9 May 2018 13:07:28 -0400 >> grarpamp <[email protected]> wrote: >> >>> Briar 1.0 for Android has been released. >>> >>> Briar is a secure messaging app that uses peer-to-peer >>> connections between mobile phones to implement decentralised >>> messaging, forums and blogs. It operates over Tor, >> >> >> hey grarpamp where is the proof that tor isn't compromised? >> >> the scum who 'develops' the system obviously is. See the >> applebaum affair. > > The problem with "proof that TOR is not compromised" comes in a much > broader context: Proving negative propositions. Cases like the one at > hand, presenting numerous variables and many of them hidden, do not > permit negative proofs. > > However, I can show how a State or Corporate actor with moderate > resources can compromise the TOR network. I call this a hydra attack, > because one body many heads: > > First set up a cloud server to run thousands or tens of thousands of > modified TOR routers under hypervisor control. That's the hydra's body. > > Then connect these TOR instances to remote machines acting as > transparent proxies via botnets, dedicated applicances etc., distributed > worldwide, with a statistically normal amount of relay and exit nodes. > These are the hydra's heads. > > Viola. Roll out the deployment gradually to avoid spooking people (as > happened in 2013 when a botnet deployment accounted for 3/4 of the > client nodes) and in due time you will own and control a majority of > nodes in the TOR network with no one the wiser. > > From here to a better than 90% 'unmasking' rate per TOR connection is > left as an exercise. Note that due to customized routers on the cloud > server, any message that touches the hydra will not be allowed to leave > it until outbound to its final destination: The hydra's owner > determines whether or not packets in transit cross the open network or > just get passed around inside the cloud server. > > This solution generalizes to /all/ distributed mix routing network > protocols, as far as I can tell. > > :o)
Heh. I just noticed a couple of flaws a.k.a. major oversimplifications in the above model. Again, left as an exercise. :D
