IM demo for TOR coming soon The TOR project is about to join the world of secure instant messaging, laying out a roadmap that would see its first code for a new project delivered by the end of March 2014. The first aim of the Tor Instant Messaging Bundle will be to get experimental builds happening with Instantbird providing the messaging interface. …
...people in countries where communication for the purpose of activism is met with intimidation, violence, and prosecution will be able to avoid the scrutiny of criminal cartels, corrupt officials, and authoritarian governments.
Don't see how one can escape scrutiny in a place where the mere use of encryption (which is part of how TOR works) immediately raises a red flag.
And that, sir, is the question. Which is exactly why all nations - including our own - are very big on making people feel like encryption will get them in shit. I start by installing hte HTTPS everywhere Firefox plugin everywhere I can. When I have the opportunity, I do more. It's all I know to do. What ideas do you have?
I start by installing hte HTTPS everywhere Firefox plugin everywhere I can. When I have the opportunity, I do more. It's all I know to do. What ideas do you have?
That would work in the context of a truly oppressive, technology-aware regime? None that I can think of right now.
And even if I did, security as we all know is a game of cat-and-mouse: someone would eventually develop a counter for them, and force "us" to think of something else.
Which I guess is the spirit of our time: no clear-cut solutions, and often the best we can do is stall for time, waiting for something to show up.
It can only do so much. A savvy power would know real binary data would be formatted. That's why the "magic numbers" technique works. Attempt to obfuscate and they'll try to parse it, which will likely produce telltale clues. As for steganography, mangling inputs should break all but the most robust (and lowest bitrate) systems.
I'm beginning to wonder if it's possible to utilise part of the udp/tcp header flags as part of the encryption/decryption process - there are quite a few fields that aren't used much.
You could also use port numbers in the process, mix up udp and tcp connections to obfuscate the stream further. That might mean you lose the odd connection, but it might make it trickier to intercept.
Last but not least, wrap it all up in what appears to be a typical unencrypted http session - that just happens to contain what appears to be random data. Imagine the overhead in trying to not only capture the data, but also the headers, and then work out if the payload is encrypted or not. Lots of extra CPU :)
There are bound to be flaws, I'm just speculating off the top of my head.
The real goal is to make the connection look like an innocuous connection like a web session. Trouble is, innocuous sessions are typically wide-open and easy to inspect. Trying to do anything outside that purview, such as using exotic flags, is going to trip flags.
Frankly, given the current state of the Internet, I don't think it's possible to "hide in plain sight" and get a detailed message anything past a knowledgeable and savvy power who outlaws all encryption as a matter of course and can routinely sniff connections. The reason being just about anything you try will either (a) leave telltale clues when you try to parse it as it appears, or (b) is vulnerable to mangling such that the end product retains purpose as it appears but ruins stego (ex. whitespace-washing text, resizing images, resampling/recoding audio, etc.). You could probably get away with pre-arranged signal images and the like, but anything spontaneous or detailed would probably require another approach (if any is possible).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
