BriarProject Messaging 1.0 Released

[juan]

On Thu, 10 May 2018 18:56:24 -0400
Steve Kinney <admin at pilobilus.net> 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.

	...is the very same thing as proving positive propositions.
	
	it should be obvious that I can rephrase "prove X is NOT
	compromised"(allegedly a 'negative') to "prove X IS
	secure"(a 'positive').

	in this case, I think it's fair to ask "prove tor isn't
	compromised" because there are tons of evidence showing that tor
	is shit, just like its pentagon funded developers.

	

> Cases like the one
> at hand, presenting numerous variables and many of them hidden, do not
> permit negative proofs.

	Let's say you're doing chemistry and you require your reagents
	to be 90% pure, 99% pure, 99.999% pure with no more that 0.0001%
	of impurity X, Y, whatever. 
	
	That's the sort of basic soecifications you would expect in any
	'scientific' or engineering project. 

	but looks like basic engineering practices don't apply in
	crypto la la land. Especially government funded crypto la la
	land.


> 
> 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.


	That's one option. Traffic analysis is another option. The oh so
	famous "global passive adversary".

	

> 
> 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.


	I think that 'high latency' networks and networks that use fill
	traffic are harder to attack. 

	But unsurprisingly, the tor scum isn't interested in that sort
	of thing. They want a 'low latency' network that allows retards
	to watch HD video on jewtube. And allows people in 'repressive
	regimes' to watch pentagon propaganda.




> 
> :o)
> 
> 
>