BriarProject Messaging 1.0 Released

[Steve Kinney]

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 <grarpamp at gmail.com> 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