19 expanded posts ยท every known parent and child
Is there a standard for stego yet? I just added stego and de-stego filters to my pbmplus image toolkit, using a simple protocol I made up on the spot. Now I'm wondering if I should make them compatible with existing stego tools. --- Jef
> Is there a standard for stego yet? I just added stego and de-stego
> filters to my pbmplus image toolkit, using a simple protocol I made
> up on the spot. Now I'm wondering if I should make them compatible
> with existing stego tools.
> ---
> Jef
>
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.
_ . _ ___ _ . _
===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-===
===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -===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."
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."Earlier, Timothy C. May wrote: > 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.) 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
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
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
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
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 did the stego, and hence be able to demodulate with that particular technique. Therefore if you had seperate programs, each could interoperate. 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). 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:
>
> > 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
>Earlier, Sergey Goldgaber wrote: > > encrypts a signature but an identifier so as to know which program actually > ^^^^^^^^^ > You were originally referring to PGP in particular, were you not? Nope. > 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. What do you mean by non-standardised ? > "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 medium being used to carry the hidden information. In any case, if the modulation method(s) is/are public, it by itself can't be used to provide any means of security. > 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). 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 ? This still doesn't work, because it means not only a lot of wasted bandwidth, but makes it a requirement to have a public-key in the first place -- any unnecessary tie in. 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. This needs to be hidden 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. 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". 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
Earlier, Sergey Goldgaber wrote:
> 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.
I did mean the former, yes a standard header, but obviously a user
defined/supplied key -- the system would be worthless otherwise.
> > This still doesn't work, because it means not only a lot of wasted
> > bandwidth,
>
> Wasted bandwidth does not a poor method make!
No, but in the case of steganography it does make it an impractical
requirement.
> 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.
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.
> 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.
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 ?
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. 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.
> 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.
No. You see it works like this. When you go to insert data ('stego it')
into the medium, you prepend some header, but you encrypt the header
under a cipher. This header contains a signature plus other information.
Because it's been encrypted, it looks like junk, it shouldn't be (within
limits of your stego medium) discernable from the original bits that
where there. After that header follows the stegged data.
When someone wants to remove stegged data from the media, they then
pull out a certain number of leading bits using a pre defined steg
method for that media. 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.
> 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.
Yes, that would be a good idea too (excuse the pun .. :-).
> 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
searched.
Okay, how about giving up using some form of offset and just RSA encrypt
a header with the intended recipients key. 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 ..).
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. Then you could just
"desteg < art | stealth-pgp > out" and watch Stealth-PGP's exit code.
The desteg software shouldn't attempt to put anything in to identify
the presence of stegged data tho.
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.WattsOn 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>
> "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).
>
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?'
_ . _ ___ _ . _
===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-===
===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -===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
Guys, I thought the whole point of stego was to hide the fact that you're hiding data in a file. Having a "standard" for this is a bad idea i the sense that if you have a standard, you make it that much easier for the bad guys to intercept and find what you are trying to hide! Now I'd certainly like to see MANY stego programs out there, however making any of them a standard is a bad move. 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...
On Mon, 28 Feb 1994, Arsen Ray Arachelian wrote: > Guys, I thought the whole point of stego was to hide the fact that > you're hiding data in a file. Having a "standard" for this is > a bad idea i the sense that if you have a standard, you make it > that much easier for the bad guys to intercept and find what > you are trying to hide! > That is correct. The standard should be to have no standard! :) But, if you must have a standard, some variability would help. I outlined a "variable standard" in another recent message in this thread. A fictional example of a legitimate need for standardization and a possible solution follows: Feb. 1998 Jack and Jill are both readers of cypherpunks and long-time users of PGP. "Stealth PGP" and "Stego+" have become very popular. Unfortunately, Clipper is a legal necessity for all computer communication. Jack wants to send Jill a _truely_ private message. Using only Clipper is not an option; neither is "Stealth PGP", on its own; as, meerly owning non-Clipper encrypted files has recently been successfully used as grounds for search warrants, equipment confiscations, and miscellaneous court sanctions. Luckily, it has become particularly popular to use "Stealth PGP" in combination with "Stego+" to hide messages in PictureCD files. Knowledgeable users regularly scan alt.videos.binaries.misc for messages. Although Jack would like additional security that he would obtain from using a non-standard stegonagraphy program, this is his first message to Jill. He can not simply send plain-text email to Jill telling her to use the new "SuperStego", for obvious reasons. Jack therefore uses the standard, relatively secure, method and sends the message via "Stealth PGP" & "Stego+" in TEST.CD on alt.videos.binaries.misc; thereby evading the ClipperCops. 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! -===