standard for stegonography?
sergey at delbruck.pharm.sunysb.edu
Tue Mar 1 01:07:59 PST 1994
On Tue, 1 Mar 1994, Matthew Gream wrote:
> Earlier, Sergey Goldgaber wrote:
> > Wasted bandwidth does not a poor method make!
> No, but in the case of steganography it does make it an impractical
I dissagree. You may waste a few bytes, or maybe several Kb, but it would
be worth it.
> No, I outlined two reasons. Firstly, an offset method such as you mention
> wastes a lot of bandwidth. Say you take a conservative 16 bits as offset
> (which is already too easy to brute force), there you have up to 64kbit of
> potentially wasted bandwidth in a transmission medium that needs as much
> as it can get. See for example pixel 'stegging', you'd need exceeding large
> pictures just to overcome the offset noise let alone modulate data of any
> practical length in. The second reason, which yes can be construed as more
> a personal dislike, did regard the prerequistite for a PKCS. In retrospect,
> I'll retract that.
As I said in an earlier post: you can either sacrifice space for security; or,
sacrifice security for space!
Now that I think about it, one wouldn't have to sacrifice any bandwidth
whatsoever! As, the stego program could be made to do wrap-around
encoding. Meaning that, as the end of the file is reached, encoding
continues from the beginning until the appropriate offset is reached.
This would loose none of the additional security offered by the original
On a related note, someone has mentioned that fractals have a great
ammount of potential for stego. Their noise-threshold is much higher.
You may want to look into that if you're concerned with conserving space.
> I agree with the first and foremost as well, steganography is there to
> hide data. But by the same token, if the data is hidden, how do you know
> there is any there ? Isn't the idea that _you_ have a quick means to
> determine whether something has been hidden there, else it looks like
> harmless information ?
It _should_ look like harmless information! It would be _nice_ to be able
to know which files have been stegg'ed; but, that would either have the
potential to tip off one's opponent as well or, it would require secure
channels to propagate header keys (see previous message in thread for
comments to this effect).
> With your method, you're leaving it up to whatever particular information
> has been stegged in to have some inherent integrity check. Ie. this would
> work if you stegged in PGP data or signed data.
I do not advocate stego'ing data with telltale headers. That combination is
self defeating. It must be noted that encrypted headers, as per your
advice, would allow one to know that decription was successful, without
> But what if you stegged
> in something else, how do you know it was stegged data ? All I was
> proposing was a method of providing a header encrypted so you _know_ that
> what follows is stegged information, that was my original intent.
You would have to decrypt it to find out. The only problem may lie in
figuring out the file-length. Possible solutions are:
1 - Put in some kind of EOF marker. Scatter a some more through the file
just in case, as well. You may thus be required to make several
attempts at decryption.
2 - Have a standard file length. Break the original file into standard
length packets. Pad with noise, if neccessary. Then send it through
via multiple successive files.
> Those first few bits are decrypted to either
> reveal a structured header, in which case you can proceed to remove
> the rest of the data, or to reveal junk, in which case there is nothing
> there, at least nothing for you.
This is much clearer, thank you. However, I'm sure you realize that
if the key used to encrypt the header is standardized, and it's location
of the header is standardized as well, much security is lost. If its not
standardized, secure channels must exist for its propagation (ie: no need
> > So that this question may be asked: if you have secure channels, why do you
> > need encryption?
> I have seen this point, and yes, I guess it is a problem. You would need to
> at some stage in the past agree on a key to use. How about changing that
> from IDEA to RSA then ?
> > It would be even easier to get the same picture and run it through your
> > stego software which would look at your public-key and extract the file
> > automatically. This would be pretty secure, easy to use, and require no
> > secure channels!
> But then why offset in the first place? What is going to be at the offset
> that can't be at the front of the file ? If something structured is going
> to be at an offset, then it's easily susceptible to being brute force
Yes, stego is all but invalidated if you try and hide patterned information.
That is why I recommend using "Stealth PGP" and/or a Mimic-function in
combination with the standard stego we've been discussing.
> Okay, how about giving up using some form of offset and just RSA encrypt
> a header with the intended recipients key.
You need not give up the offset-method to do this. They should work
together for additional security.
> To check, you'd get your stego
> software to pull out the first 2048 bits and decrypt the first X bits
> corresponding to whatever your modulus length is with your private key,
> if the result is "*STEGO FOLLOWS*+other", then theres a file there, else
> you know nothing exists there (at least not for you ..).
This is a good idea. It will save you time you would have otherwise used
to try and decrypt the whole file. However, this should only be used if
the header fits in uniformly with the rest of the file. Otherwise, the
file will stand out as encrypted. Of course, the data should be
uniformly encrypted with Stealth PGP or its equivalent, as well.
> However, this is half hearted because after thinking about it, I've come
> to the conclusion that it's probably best if all the software does is
> push the bits in and leave it up to Stealth-PGP (or other software) to
> provide a means of creating the header and the proceeding data in a way
> so that no key-ID's or so on exist.
The function of Stealth PGP, as I understand it, is not only to encrypt
without information as to the intended reciever, but to leave no trace of
encryption whatsoever. Thus the need for a seperate, encrypted, header.
I think your modified proposal should work just fine.
> Then you could just
> "desteg < art | stealth-pgp > out" and watch Stealth-PGP's exit code.
If the desteg program automatically checks for encrypted, hidden
fileheaders via un-stealth-pgp, it may be as simple as you've pointed
> The desteg software shouldn't attempt to put anything in to identify
> the presence of stegged data tho.
Your idea will save time at no loss to security, if the header is encrypted.
I see a problem only if the header is:
1 - unencrypted
2 - encrypted with a non-public key
3 - encrypted but anamalous
If its encrypted with a public-key and blends in with the rest of the
data and the rest of the file it should be fine.
More information about the cypherpunks-legacy