On 05/10/2018 05:21 PM, juan wrote:

On Wed, 9 May 2018 13:07:28 -0400 grarpamp <grarpamp@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)

On Thu, 10 May 2018 18:56:24 -0400 Steve Kinney <admin@pilobilus.net> wrote:

On 05/10/2018 05:21 PM, juan wrote:

...

On Wed, 9 May 2018 13:07:28 -0400 grarpamp <grarpamp@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)

On Thu, 10 May 2018 23:33:39 -0400 Steve Kinney <admin@pilobilus.net> wrote:

Back around 1999 or 2000 I documented what I believed to be an ongoing, successful attack agaisnt the Mixmaster remailer network.

First, I attempted to geolocate all the 'reliable' routers then active. I found a startling number of them in the State of Texas, suggesting one sponsor for all - therefore, capable of following the "bouncing ball" of high latency traffic in many chains.

I found others in IP ranges assigned to various countries, including ones with "mutually hostile" political and economic relations. So I created chains that crossed mutually hostile borders and started sending test messages. I sent several batches over a period of about a week. NONE ever came back to me, indicating high likelihood of deliberate interruption of that traffic - the global adversary at work.

Oh well. I must admit I haven't fully done my homework but as far I understand the system, it's supposed to work if at least one of the mixing nodes isn't compromised? Cheap intuition tells me that a low bandwith, 'high latency' system with long mixing chains has to be somewhat better than the likes of tor. Then again, I haven't done too much rigorous thinking on the matter so...

So there's nothing new about the "ha ha fuck you" nature of allegedly anonymized comms on the networks. The only real security afforded would be in the "my adversary does not want to openly disclose this capability if he can avoid it" category, which is thin cover indeed...

And they don't need to disclose anything anyway. The nsa can always tell the cops "the silk road server is here" and then the cops will come up with some 'parallel construction' fairy tale.

IMO physical opsec is the only guarantor of anonymity on the networks: Hit and run comms with a scrambled MAC address via open routers, with due attention to avoiding surveillance on the way in and out,

yeah...so it's something that the very vast majority of mortals can't do =/ and even if you can do that, it's mostly useful for sending one-off messages...

seems to be the only option where /real/ hazards from State sponsored terrorist reprisals are on the table.

:o/

On 05/12/2018 02:49 AM, grarpamp wrote:

Look to new messaging, fill, PETS and other venues, whatever, etc.. search for papers, fidn tbe bibs, see what's out there, or what you might create.

Here's a silly notion: First you need a network of servers that can store and forward large amounts of data in the form of text, and distribute it across enough nodes to make the stored data deletion-resistant and reasonably accessible to a large number of users. NNTP will do nicely. Then you need privately owned devices capable of downloading gigabytes of data daily, and applying a decryption test to millions of messages as they flow by. Today's low end PCs will do nicely. Those gigabytes of text? Symmetrically encrypted messages from the whole Alice, Bob, etc. alphabet soup of users, employing keys obtained by whatever means from their intended message recipients. Everyone participating in this network would download the whole stream, testing the encrypted subject line of each discrete message with their personal keys, looking for the flag that says "this one's for you." Those messages would be decrypted instead of discarded, and presented in a local inbox. The rest would just zoom on past. Sending a message? Encrypt it and its subject line with your recipients' keys, and send it on its way. If your recipient downloads the stream before your message expires, success. 3rd party observers? Out in the cold, unless they penetrate individual users' machines or otherwise compromise endpoints, one user at a time. This protocol presents as an application of the most time honored and reliable principle of engineering practice: Brute force and total ignorance. With a side of COTS: We already have all the parts, this could be done with shell scripts. The only counter attacks I immediately see include flooding past the breaking point with purely random bits, which may require mitigation via short cycle message expiration or some kind of registration or proof of work process for users; or interruption of traffic by a global (or local) active adversary. Call the protocol and associated tools TPC: An acronym for Totally Protected Communication or, for those in the know, The Perfect Crytocrime. Bonus: Quantum cryptanalysis can't touch that, far as we know. :o)