Jeremy Cooper writes:

I think the whole idea behind stego is that it is non-standard. The way in which you setgoize something must be constantly changing, otherwise the point of stego (hiding information inside other information) would be contradicted. If there was a standard for hiding something, you would always know where to look.

Not necessarily. Recall that one of the main stegonagraphic approaches is to place signal bits in the "noise" bits of digitized audio samples, digitized camera images, etc. Provided the bits "look like" noise bits (lots of interesting issues here, which we've discussed many times on this list), then the placement can be 'standardized" so long as the key (of whatever type) is kept secret. I agree that changing the placement/format of stego signals adds to the security by a slight amount, via the usual "security through obscurity," but the the type of stego we believe is quite feasible with modern DATs, CDs, GIF images, etc., allows the signal bits to be "hidden in plain sight." I'm sure this is the "standard" being talked about. (BTW, I agree that including trivially-readable messages like "***Begin Stego Block Now*** is a dumb idea....with reasonable standards for block size, e.g., the signal bits are the LSBs of the largest sub-block that's an even power of 1, no such headers are needed.) --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

On Mon, 28 Feb 1994, Matthew Gream wrote:

How about something like small random pad, maybe one octet, then a signature (such as "***Begin ...") with this header information being encrypted via IDEA CFB. You could also include a more structured header after this, ie. an ID for the software that created it, so the correct demodulation technique can be applied, or at least warned about if not available.

With this type of method, unless you can pre-supply the key, the stego header should look like noise.

Matthew. -- Matthew Gream. ph: (02)-821-2043. M.Gream@uts.edu.au. PGPMail and brown paperbags accepted. - Non Servatum - ''weirdo's make the world go around'' - A.Watts

If you're using one-time pads, why use PGP? _Public_ Key Cryptography...? Sergey

On Mon, 28 Feb 1994, Matthew Gream wrote:

Earlier, Sergey Goldgaber wrote:

...

If you're using one-time pads, why use PGP? _Public_ Key Cryptography...?

Huh ? The discussion was about a standard format for stego'd files, so that different software could interoperate, unless I wildly misinterpreted.

Matthew.

-- Matthew Gream. ph: (02)-821-2043. M.Gream@uts.edu.au. PGPMail and brown paperbags accepted. - Non Servatum - ''weirdo's make the world go around'' - A.Watts

Didn't you mention something along the lines of hiding "---BEGIN PGP" headers by using one-time pad encryption? Or did I wildly misinterpret you? Sergey

On Tue, 1 Mar 1994, Matthew Gream wrote:

Earlier, Sergey Goldgaber wrote:

...

Didn't you mention something along the lines of hiding "---BEGIN PGP" headers by using one-time pad encryption? Or did I wildly misinterpret you?

No. I said that, and I was referring to the case where you have a particular stegonographic technique such as pixel modulation, it could be an idea to place an encrypted header using something like IDEA in CFB that not only encrypts a signature but an identifier so as to know which program actually ^^^^^^^^^ You were originally referring to PGP in particular, were you not?

did the stego, and hence be able to demodulate with that particular technique. Therefore if you had seperate programs, each could interoperate.

Yes, I understand that your proposal is compatible with a variety of other schemes. However, as you note below, this provides very limited security, unless the key is _non_standardized.

Even though the essense of stego is to not know a message is hidden in a particular medium, whenever specific software comes out to do certain stego (jpegs etc), I can see NSA spooks adding it onto their short list of s/ware to run across any pictures they get. Stego becomes sort of pseudo-Stego and loses a certain amount of gain it once had (of course, if all you do is Stego an encrypted file without any structure, it'll be safe).

"Pseudo-Stego" can be relatively secure as long as a large number of different hiding schemes/standards are used by the public. An effective means of ensuring this would be to use the reciever's public-key checksum-value as the standard offset for stego. The large number of public-keys available make it rather infeasable for one's opponents to try them all. This, I believe, provides pretty adequate security (assuming one strips any telltale headers off the hidden file beforehand).

My 5c.

Matthew. -- Matthew Gream. ph: (02)-821-2043. M.Gream@uts.edu.au. PGPMail and brown paperbags accepted. - Non Servatum - ''weirdo's make the world go around'' - A.Watts

On Tue, 1 Mar 1994, Matthew Gream wrote:

Earlier, Sergey Goldgaber wrote:

...

You were originally referring to PGP in particular, were you not?

Nope.

In that case, I retract my statements. Sorry, I was under the impression that you were.

What do you mean by non-standardised ?

In your message you made a proposal to the effect of implementing a stegonagraphy standard whereby a standard header is encrypted. I thought you were implying that the key should be constant for that stegonagraphy program. I simply noted that security would be limited if this were the case. Using a new key every time one encrypted would be an example of what I meant by a "non-standardized" key.

...

"Pseudo-Stego" can be relatively secure as long as a large number of different hiding schemes/standards are used by the public.

This is limited by the availability of software and the inherent qualities [of the] medium being used to carry the hidden information.

Of course. Most everything computer related is limited by those same factors.

In any case, if the modulation method(s) is/are public, it by itself can't be used to provide any means of security.

I disagree. If a great number of methods are available, using one will provide some measure of security, regardless whether or not it is public. Only in the case where the _exact_ (public) method and _exact_ (public) key one has used is known to one's opponents that there is some loss of security. Knowing a hundred different methods and tens of thousands of different keys doesn't get one's opponents anywhere.

As for offset, do you mean that the public-key checksum value determines how much prepended 'garbage' to skip over before the real stego data becomes available ?

Yes. And, the great variety of different offsets made available through the use of public-key checksum-values provide the increase in security. Of course, for the greatest security no standard whatsoever should be used.

This still doesn't work, because it means not only a lot of wasted bandwidth,

Wasted bandwidth does not a poor method make!

but makes it a requirement to have a public-key in the first place -- any unnecessary tie in.

The method I outlined does indeed require a public-key. Using the method is, as you have pointed out, not necessary. You have not, however, shown why you believe the method doesn't work. You have simply outlined what you _don't_like_ about the method.

All you want is a quick means to determine whether data has been modulated into the medium, and if it has by what particular item of software.

Ah! This is where we don't see eye to eye. I believe that the purpose of stegonagraphy is to hide data. Having "a quick means to determine whether data has been modulated into the medium, and if it has by what particular item of software" is a detriment to that effect. We were speaking of standards, however. Thus my proposal to offset data by the checksum-value of the reciever's public-key. If one must use a standard of any kind this one would, I believe, provides enough variation for moderate security. Please note that this standard, and the one you've presented are not mutually exclusive. I simply believe that a standard stego-function which hides the data in a constant location makes for a poor stego-function. That's where my proposal comes in.

This needs to be hidden

If the information that informs one that something is hidden in the media is itself hidden, how can it be a means to determine if something is hidden? How would you determine if there is information that informs one that something is hidden in the media, hidden in the media? See the problem? Your whole purpose is cancelled out by your method. Fortunately, there is no need for this convention. One would have determined that there is at least a possibility of data having been hidden in the medium before one attempted to use a de-steg function anyway.

by some means (eg (cheaply) : s/ware_id + sigma(i=0-n) passwd[i] + csum) and, as you say, the information itself needs to be unstructured.

As long as you're proposing header encryption via IDEA, why not consider doing the same to the whole file? It would increase security. There are objections to be levied against any non-public-key system, however. Namely: That it would require either: 1 - A standard password (SEE ABOVE). or 2 - Dissemation of the password through secure channels. So that this question may be asked: if you have secure channels, why do you need encryption?

Therefore, you can pull pictures off alt.binaries.pictures.contemporary, run it though something w/ a password "russian_mole" and see whether your software says "I see this looks like it has a file created by program #s/ware_id, let me extract it".

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! Sergey

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 requirement.

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 method. 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 sacrificing security.

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 for stego).

...

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 ?

hmmmm.....

...

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 searched.

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 out, anyway.

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 or 2 - encrypted with a non-public key or 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. Sergey

On Mon, 28 Feb 1994, Jeremy Cooper wrote:

How many possible checksums are there? If you use a one byte checksum, there are only 256 possible combinations right? Maybe what I am asking is, 'How big is the checksum?'

Good question! Anyone out there know what the practical/secure limit is? Sergey

On Mon, 28 Feb 1994, Arsen Ray Arachelian wrote:

The less standard a stego program is, the safer. Rolling your own would probably be the best way to keep the bad guys out of the way. As far as sharing stego'ed stuff, you can 1st send your program over with PGP, so the other side also has the same stego program you're using...

I agree that standardization is not something you want for stego, but on the otherhand, if you can send a PGP message, why bother using stego? _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -===

Jeff Poskanzer caught the typo in my post:

I'm sure this is the "standard" being talked about. (BTW, I agree that including trivially-readable messages like "***Begin Stego Block Now*** is a dumb idea....with reasonable standards for block size, e.g., the signal bits are the LSBs of the largest sub-block that's an even power of 1, no such headers are needed.) ^^^

Obviously I meant even power of 2. While I'm at it, I'll elaborate for a bit. If an image file or audio sample file of, say, 12319 bytes is received, one might "standardize" (voluntarily, of course) on the first 8192 bytes as representing the place to look for the LSB message. Alternatively, *all* of the LSB bits could be looked at, with messages just padded-out with random bits to fill out the full amount. Lots of options for standards. As others have noted, you just don't want to have to flag what standard you're using in the message itself (in plaintext, else why bother?) as that means the stego use is not longer plausibly deniable. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."