To clarify: There is not, and cannot be, a universal DissidentX encoding detector. It will always, always, be possible to iterate arbitrarily on the encoding technique, and this iterating is easy to do.
Every time someone iterates and releases the code on github, law enforcement will then be capable of writing a DissidentX encoding detector for that encoder. Every time you publicly release stego code, that stego code becomes ineffective.
At best, this framework provides a way for people to write stego encoders that they don't plan on releasing publicly. But you should say that! Warn people how dangerous it is to be releasing their stego code. And warn people not to trust any of the default encoders.
It's not as easy to iterate on stego techniques as you're implying. There are only so many ways to creatively hide a message. And if people happen to come up with a scheme which has already been broken in the past, then their encoder will provide no security at all. They'll trick themselves into believing they're secure, when they're not.
The endgame of effectiveness of stego with this framework of published techniques versus customized detectors for those techniques specifically is going to be much, much more difficult for the detector than it is today, if not outright losing. As for your claim that it isn't easy to stego techniques: Seriously, go read through the docs before making claims. You're just plain wrong, and obviously so.
Can you elaborate? I don't see why this must be true. Just as good encryption is indistinguishable from random data, good steganography should be indistinguishable from whatever universe of target plaintexts you've chosen. In both cases, the code is public, but the secret key is needed to see that the message is non-random, or non-plaintext.
Here's one way it might go down in practice. After law enforcement seizes your computer, they'll scan your computer for any encrypted containers, along with any code that looks like it's used for steganography. They'll find DissidentX, since its README mentions "steganography," which is a keyword that their forensics tools will search for. Then they'll use each encoder in your DissidentX folder to scan your computer for any encoded messages. Unless the message is trivially short (<50 bytes) then they'll come up with a list of suspect messages. This list will include any encoded message you've created using DissidentX, along with some false positives. Then, if you're in the UK, they'll have a judge demand you cooperate with them; any plausible deniability you may have had is gone at that point. It's "cooperate or go to jail."
Shannon provided us with a proof that
such systems are secure regardless of the computational
power of the opponent [43]. [...] Yet we still
have no comparable theory of steganography.
The problem is that there's no such thing as perfectly secure stego (undetectable covert messages), even though there is perfectly secure encryption (unbreakable encrypted messages, regardless of the computational power of the adversary, when implemented correctly, and when not defeated via side channel attacks, and when not compelled to cooperate by a judge).
I just read it, and you are completely extrapolating what that paper says. It does not say steganography is hopeless. It contains no mathematical proofs, and it's also from over 15 years ago.
More generally, "we do not have a proof" does not mean "we disprove". You also completely ignored my point about the secret, without which the encoder will not work when an attacker tries to run it.
So can't you just embed messages in every file you own? Then when asked for the keys, give out fake keys for the really really secret stuff. So law enforcement ends up with a few sensitive documents and a whole bunch of random bytes where you cannot distinguish between "actual random bytes" and "bytes decoded with the wrong key". And there is your plausible deniability.
Obviously it's not perfect. Obviously a totalitarian regime which suspects you of dissident activity will pick any reason out of thin air to lock you up for as long as they like, or just execute you.
But being able to say "here's the keys" with them having no way to know if they are all the right keys, is at least something.
Though of course at best you won't keep those files on your PC in the first place. You'd keep them on a microSD card that you keep in a tiny pouch under your skin. You'd keep them encoded in photos you have printed out and hung as wall pictures. You'd have them embedded in a well-torrented movie and backed up willingly by hundreds of thousands people (though not you). And if you just use them to send encoded messages, neither you nor the recipient will ever store them on an hdd.
I'm terribly confused by your argument. Who's talking about equipment seizure here? What does that have to do with the on-the-wire security of the encoded messages?
Your argument appears to concern only the risk in openly publishing encoders. Are you also arguing that Bram's framework encourages such publishing? If not, then what exactly is your beef with it (the framework)?
OK, so when you're talking about seizure of equipment, with all the tools and past encodes just sitting there on the machine for the taking, you're really far afield of the kind of argument you had seemed to be making. I understand now why you seem to assume that the adversary is near-omnipotent here - because you're assuming that the user is a dolt who is doing most of the hard work of damning themselves for the state.
An effective dissident is going to employ some reasonable opsec practices and have multiple layers of security, they're not going to be foolish enough to think that one program is a magic bullet.
There was a CIA contractor who outright defrauded them claiming that he had tools which were detecting steganographic messages used by terrorists on the internet. He didn't get prosecuted because they were too embarrassed to admit that they'd been completely bamboozled.
This is a framework for steganographic schemes, not a specific steganographic scheme. The specific ones thrown in are just for demonstration purposes. The versatility of this approach is a major step forward in defeating statistical detection schemes. You of course don't know this, because you haven't read through the page and figured out what the code does.
You of course don't know this, because you haven't read through the page and figured out what the code does.
Let's not get personal. I only mentioned your name because it was in the headline, not to bully anyone.
I know this is a framework. But the problem with stego is that as soon as you release your code, you make it almost trivial for law enforcement to detect that you're using stego. It's a catch-22: you want people using the code, but you don't want law enforcement knowing what code you're using, because then they can just use the same code to detect that you're using stego, which defeats the purpose of stego.
This isn't theoretical. Each time someone releases a new stego tool out into the wild, forensics companies add it to their own frameworks for detecting stego.
Let me be clear: I want you to succeed, and I think it's a great thing that so much effort is being put into developing these sorts of tools. But you have to say something like "Don't use this tool yet! It's not ready for production!" ... The way it was presented here made it sound as if it's ready to be used, but anyone who uses it in its current state will be swiftly detected by law enforcement.
Let's put it another way. Do you think the 120 people who upvoted this did so because they understood this is "just a framework / reference," or because they were hopeful this actually works? It's not fair to them not to include a disclaimer saying this shouldn't be used. The way the README is written makes it sound like you're encouraging people to use it, even though it's not intended to be used.
I feel bad about it. I shouldn't have called him out by name; I should've concentrated solely on why this tool falls short. Sorry, Bram.
I'm just worried that people will see his name, see that he's saying things like "this tool is ready to be used," and then actually use this, just because "It's Bram Cohen," and end up getting themselves caught.
I don't see anything wrong with pointing out that a famous person's work is below par, particularly when said person decides to show up in the thread and ignore what you are saying and act like a jerk in response. You shouldn't retreat so easily.
This tool allows for the specifics of how the encoding is done to be changed without the decoding algorithm needing to be changed ever, so yes in fact it is ready to be used, although better encoders are both easy to write and welcome.
There are two possibilities. Either you've created a tool which enables people to covertly send messages without being detected, which every publicly-released stego tool thus far has failed to do, or you haven't.
Have you spent much time researching why current stego tools have all failed? The way you're endorsing this makes it sound like you haven't, and you're putting people in danger by pretending like law enforcement is incompetent.
Remember, law enforcement somehow managed to acquire an image of Silk Road's server, even though they were running it as a Tor Hidden Service, and they also managed to recover >100k bitcoins from DPR. All of this was done through forensics. Are you claiming that this tool is secure against such an adversary?
Hopefully someone will write a program called "DissidentXDetector" before law enforcement does. The myth that this generates undetectable messages needs to be debunked before people start trusting this.
Q. Can someone detect that a file has messages encoded in it?
A. That depends on the encoding used and the properties of the file the data is being encoded in. There's a whole field of academic literature on steganography, none of which is invalidated by this code. What this code does is vastly simplify the implementation of new steganographic techniques, and allow a universal decoder and encoding of multiple messages to different keys in the same file.
Q. Can someone detect that a file has messages encoded in it?
A. If the file was generated with an encoder whose code is public (i.e. Github, bitbucket, ...) then yes. Always. And even if the code is private, it may not be secure. Unless you come up with an encoding scheme that's never been thought of before, then law enforcement will likely be able to detect the encoded messages unless they're trivially short.
I have been working on a new steganography algorithm that I believe is secure. I plan to make it open source in the new year. Would you like to review the design and code when it is released?
Low enforcement might start issuing warrants to hand over your customer list as a list of potential suspects. If I were you I'd start that rumor myself.
The rumor would presumably help him because it would discourage his clients from committing crimes, because they would be under additional scrutiny from law enforcement. It seems unlikely that it would actually matter though, since law enforcement already has a database of convicted felons that they go to first for crimes.
>The rumor would presumably help him because it would discourage his clients from committing crimes,
That rumor would most likely discourage people from becoming clients in the first place.
While "getting out of the building" and talking to our assumed target demo, one of the reservations people had was the belief that we were working in concert with law enforcement.
The traditional overlay approach involves a bunch of full trees, and uses multiple trees as a way around dealing with leaf nodes being unutilized. My approach uses multiple groupings, which do not overlay, screams within them, and does something completely different for the last hop. They're completely different architectures. I have trouble taking seriously any paper which says that it makes heavy use of multiple description coding. If you have congestion control, skips should be an extreme and bad event.
I don't know why this got downvoted. It was a legitimate question. I've been involved in patent filings and unless you are a one-man operation, there are always other people that contribute to the key insights needed to come up with a novel, useful invention.
Over time I've made interview challenge problems progressively easier, as I've found that the trickier ones don't give any more information than the easier ones. My challenge now basically amounts to 'read this doubly nested for loop and tell me what it does', equivalent in difficulty to fizzbuzz.
If you can't solve that, even in the pressure of an interview, then I'm sorry, but you have no business working as a programmer, and I'm offended that you even applied.
There's such a high correlation between an individual student's score from one year to the next, and the number of data points is so small, that trying to tweeze out the teacher's contribution in a statistically meaningful way is fairly hopeless.
What I'd like to see are correlates with a teacher's own scores on the tests of the material they're supposed to be teaching (oh you think they all can get perfect scores easily? Hah!) and whether teachers banned from giving homework do any worse, and whether dumping the enforced curriculum in favor of letting students study at their own pace makes any difference. Given how little what the teachers actually do seems to make, it would be logical to at least dump the things which make school dull and unpleasant.
