Re: Standard for Stenography?
From: Jef Poskanzer <jef@ee.lbl.gov>
Firstly, congratulations for Sergey Goldgaber's stubborn pushing of this topic, for Bill Stewart's observation: "simple stego-programs, stealthy encryption programs"
I disagree with pretty much everything in your message, and since I'm the one who opened the topic and who is writing the code, my opinion would seem to count for quite a bit more than yours. I'm not going to repeat the reasons why the kind of standard you propose is a bad idea, you can fetch the messages as easily as I can.
Cc:ed to the list only so that no one thinks Gary's proposal was accepted. The permutation idea remains the best.
I share Jef's disagreement with the spectacularly bad "neon sign" steganography header, but I don't think Sergey's approach was correct and I hope he does not feel the issue is closed yet. Bill Stewart is IMO far more experienced and has far better understanding of the issue than Sergey, who has been a list member for only a few weeks and again IMO suggests a very naive security-through-obscurity approach. Bill Stewart, Norm Hardy, and other list members who have more experience and who have discussed these issues in the past will I think agree that the correct approach is to separate the function of the stegonography program to be a simple and clean insertion, and to have other components be responsible for assuring that what is inserted is statistically indistin- guishable from what is replaced. This notion that a "secret offset" will prevent the stego from being discovered is highly naive IMO. The correct approach is to make it so that the stego cannot be recognized even if the opponent knows where it is. Adding offsets is like attempting to "improve" regular RSA by putting a secret amount of noise padding at the front (not of a stego file, but of an openly encrypted file). This is unnecessary if you trust your encryption, and if you don't trust it then this approach should not make you trust it. Similarly, if your stego is so weak that knowing where it is in the file will allow the opponent to detect it, adding a random offset should not make you feel secure. The correct approach is to have statistical identity between what you are inserting and what you are removing. The stego program itself should then be as simple as possible. Now I will add my own little moral lesson, in the spirit of Tim and Jef. Sometimes when these discussions are re-hashed, old-timers are too busy or bored to join in. New list members express naive views that are not vigor- ously refuted. This is OK, but then some other new member takes these views to represent list consensus. I think it is great that Jef is working on a steganography implementation, but IMO the notion of "random offsets" is so fundamentally misguided that I hope he will reconsider. Hal Finney hfinney@shell.portal.com
On Thu, 3 Mar 1994, Hal wrote:
I share Jef's disagreement with the spectacularly bad "neon sign" steganography header, but I don't think Sergey's approach was correct and I hope he does not feel the issue is closed yet.
I never thought it was. Thank you for joining in the discussion, BTW.
Bill Stewart is IMO far more experienced and has far better understanding of the issue than Sergey, who has been a list member for only a few weeks and again IMO suggests a very naive security-through-obscurity approach.
I welcome any and all of Bill Stewart's comments on this issue. I have, since the beginning, noticed a distinct dislike of "security-through-obscurity" among the senior members of this and other similar lists/newsgroups. Many people preach this dislike. Most don't seem to understand its foundations fully; neverthelless, they consider it a closed issue and usually don't bother to explain why. I am glad that you are offering your insight on this, Hal.
Bill Stewart, Norm Hardy, and other list members who have more experience and who have discussed these issues in the past will I think agree that the correct approach is to separate the function of the stegonography program to be a simple and clean insertion, and to have other components be responsible for assuring that what is inserted is statistically indistin- guishable from what is replaced.
This is the most elegant solution, I agree.
This notion that a "secret offset" will prevent the stego from being discovered is highly naive IMO. The correct approach is to make it so that the stego cannot be recognized even if the opponent knows where it is.
That would be ideal, I agree.
Adding offsets is like attempting to "improve" regular RSA by putting a secret amount of noise padding at the front (not of a stego file, but of an openly encrypted file). This is unnecessary if you trust your encryption, and if you don't trust it then this approach should not make you trust it.
I do not trust my encryption to be foolproof. If I believed that adding noise at the front of the file would help, I would do it. I still wouldn't trust it, but I would feel safer with every new security-through-obscurity layer.
Similarly, if your stego is so weak that knowing where it is in the file will allow the opponent to detect it, adding a random offset should not make you feel secure. The correct approach is to have statistical identity between what you are inserting and what you are removing. The stego program itself should then be as simple as possible.
This is my defense of security-through-obscurity: Security-through-obscurity adds layers upon layers of potential effort needed by one's opponents to get at whatever it is that you are obscuring. A good analogy would be the length of one's secret key. A one bit key, you would agree, is not very effective. The bits in the key, the more effort your opponent would have to expend in brute-force analysis. Similarly, the more layers of obscurity one has, the more effort your opponent would have to expend in bypassing/guessing your methods. I have often heard it said that one should always assume that one's opponent knows everything except one's secret key. To me, this makes no sense! If your opponent is good enough and determined enough to get by all the layers of obscurity you may have put up, than its just one more step to getting your secret key. You have stated that my oppinion is naive. Please enlighten me.
Now I will add my own little moral lesson, in the spirit of Tim and Jef. Sometimes when these discussions are re-hashed, old-timers are too busy or bored to join in. New list members express naive views that are not vigor- ously refuted. This is OK, but then some other new member takes these views to represent list consensus.
So the views of these naive new members should be "vigorously refuted" (ie. flamed) in the intrest of other naive new members? Have you considered changing that to "constructively criticised"?
I think it is great that Jef is working on a steganography implementation,
That it is!
but IMO the notion of "random offsets" is so fundamentally misguided that I hope he will reconsider.
I dissagree. In a perfect world, with perfect encryption and perfect steganography "random offsets" may be superfluous. As it stands now, we need all the obscurity we can get.
Hal Finney hfinney@shell.portal.com
Sergey
participants (2)
-
Hal -
Sergey Goldgaber