December 2003 - cypherpunks-legacy

Re: standard for steganography?
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 0:56 3/1/94 -0500, Sergey Goldgaber wrote: >On Mon, 28 Feb 1994, Norman Hardy wrote: > >> Has anyone done statistical studies of low bits of pixels or sound samples? >> I suspect that they are often far from random. A flat 50% distribution in >> the low bits might standout like a sore thumb. I can imagine the the low ... >Yes, pure white noise would be anamalous. I have suggested that one use >a Mimic function with a "garbage grammar". Implemented correctly, it should >withstand statistical analysis. > >What is an AD converter? And what are the techniques you speak of that >mimic those AD converters? 'AD converter' = 'Analog to Digital converter'. Here are three schemes each with flaws: Consider an alphabet of 10 bit characters with a probability distribution such that each bit has an expected value of .6 (instead of the normal .5). The character 000000000 has a probability of .4^10 = .000105 and p(1111111111) = .6^10 = .006046. Do a Huffman encoding on this alphabet. 000000000 codes as 13 bits and 1111111111 codes as 7 bits. Take the cipher stream and execute the Huffman decode(!) operation on the cipher stream. Out comes a sequence of 10 bit bytes with 60% ones. To retrieve the original cipher stream execute the normal Huffman coding algorithm and get the original stream. The flaw here is that Huffman assigns some probability to each of the 10 bit characters which is 2^-7, 2^-8, ... 2^-13. The intermediate probabilities are not represented. This would show up without too much data. Another scheme is called 'arithmetic coding'. It avoids the above probability quantization but is tricky to program. I can't find a reference to it just now but it should appear in any modern book in information theory. Unlike Huffman it does not code each character into a definite number of bits but codes a sequence of several characters into a 'real number'. Adapting this to numbers that real computers can use is tricky. Again you feed the flat cipher stream into the decoding end of the algorithm and get biased bits. The above two schemes are information efficient. With a 60% bias you get 97% efficiency. If you are willing to settle for 80% efficiency you can merely establish a RNG synchronized at sender and receiver that sends a bit from the cipher stream with probability .8 and sends a one with probability .2.

1 0

The answer.
by Jeremy Cooper 17 Dec '03

17 Dec '03

I think I have found the way to end all our problems: ESP. Consider a secure public-key ESP connection from your head to mine. It's perfect. I think that we should work on developing this right away! _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -===

1 0

Re: DES Question
by smb＠research.att.com 17 Dec '03

17 Dec '03

Mainly to sabotage the performance of DES software implementations. Even back then the government knew it was much easier to control the dissemination of hardware than software. Are you sure? I got the distinct impression it was related to serial/parallel conversions on the chips of the time.

1 0

Re: standard for steganography?
by norm＠netcom.com 17 Dec '03

17 Dec '03

Has anyone done statistical studies of low bits of pixels or sound samples? I suspect that they are often far from random. A flat 50% distribution in the low bits might standout like a sore thumb. I can imagine the the low bit can be distributed dependently on such things as the next to low bits or 60 cycle power at the recorder. Some AD converters are known to produce 60% ones or some such. Like mechanical typewriters, AD systems probably have there own idiosyncrasies. Given a flat stream of cipher data, there are techniques to reversably introduce such variations to mimic the biases of real AD converters without much data expansion. It is my wild guess and conjecture that with such statistical variation built in there would be no effective statistical test for a given file containing hidden messages.

3 2

DES Question
by Matthew J Ghio 17 Dec '03

17 Dec '03

When using DES to encrypt email addresses, the total amount of data to be encrypted would be only 3 or 4 eight-byte DES blocks. My question is: Would CBC or CFB really be effective for such a small amount of data? Or would it be better to encrypt multiple times with transpositions in between (ie '4x3' DES as was described earlier in cypherpunks)? Second question: The DES code that I have (not written by me) has a comment section which describes filling all 16 subkeys seperately, thereby allowing a 128 byte key. Is there any significant advantage to doing this? Is there any reason that I should not do it? What is the purpose of the initial and final permutations?

3 3

Re: ditz in office
by smb＠research.att.com 17 Dec '03

17 Dec '03

`Hillary's Ominous Quotes of the Day': "AT A CERTAIN POINT, YOUR RIGHTS MUST BE ABRIDGED FOR THE PUBLIC GOOD." Sorry, that's a statement of fact. The interesting question is where one draws the line. Assume, for example, that you are a fervent believer in some religion that requires the sacrifice of unwilling outsiders. Should you be permitted to practice that religion? (Note: I said ``practice'', not ``believe in''.) Would the anarchist liberatarian next door to you be abridging your rights if he or she shoots back when you come to collect some victims? Even your own note acknowledged that rights aren't necessary absolute; you noted, in an exculpatory context, that The statement might simply be her response to a question about convicted rapists not having to submit to an AIDS test. As I said -- the interesting question is how and where one draws the line.

1 0

T-Shirt stuff...
by Christian Void 17 Dec '03

17 Dec '03

Greetings. Could anyone who has order a t-shirt, but has not gotten a order confirmation PLEASE send me mail. I have a few orders sitting here that I have no size information or e-mail addresses for. Unless you want an XL, send me a note. Thanks. :) Christian Void /T71 | "I don't like it, and I'm sorry I | V/M/Research, Inc. cvoid(a)netcom.com | ever had anything to do with it." | P.O. Box 170213 Tel. 1+415-998-0774 | -Erwin Schrodinger (1887-1961) | SF, CA 94117-0213 * PGP v2.3a Public Key Available Via Finger *

1 0

Re: standard for stegonography?
by Jef Poskanzer 17 Dec '03

17 Dec '03

>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. Indeed, that's what I implemented. The current man page is appended. --- Jef pnmstego(1) USER COMMANDS pnmstego(1) NAME pnmstego - insert a stegonographic message into a portable anymap SYNOPSIS pnmstego [-offset n] [-components rgb] [-bitsched 10010...] file [pnmfile] DESCRIPTION Reads a portable anymap as input. Hides another file within the anymap by changing the low-order bits of each pixel, and writes the modified anymap to standard output. Stegonography means "hidden writing" - it's for storing a message in such a way that an opponent won't even be sure that the message is there, let alone be able to extract, decrypt, and read it. Pnmstego lets you store a file in the low-order bits of a PPM or PGM image. For a typical maxval of 256, this means the pixel values will be changed by only 1/256, which should not be noticable to someone viewing the image. Only PGM and PPM images may be used - trying to hide a file in a PBM image would be easily visible, so it's not allowed. OPTIONS The program has a bunch of flags that let you specify varia- tions on exactly how the bits are hidden in the image. If you don't specify any flags, the default options give you a reasonable storage method, to wit: -offset 0 -components b -bitsched 1 Letting the options default like this has the advantage that you can send a stegoed file to someone without having to specify what flags you used. You can also put the file on a public FTP server for people to retrieve, without needing any other communication. However, there is a disadvantage: people who the file is not intended for will be able to extract it too. If the resulting file is recognizable in some way, for instance if it's encrypted by PGP, then some of the purpose of the stegonographic storage will have been compromised. (A PGP file has a standard header and stores, in cleartext, the keyid needed to decrypt a file.) So, if you want the file to be absolutely positively hidden, you can use non-default settings for the options. Just don't forget what settings you used, and remember that if you want to send the file to someone else you will have to communicate the necessary settings somehow. Now, as for what the options do: -offset Specifies how far into the image to start. If the file runs off the end of the image, it wraps around back to the beginning, so don't worry about specifying too large an offset. In fact, you can even specify an offset larger than the image size - the initial value gets wrapped around too (modulus). Basically, any 32-bit number can be used. -components This lets you specify which of the red, green, or blue color components is used for storing bits. You give it a string made up from one or more of the letters r, g, and b. The default is b, use only the blue component. See the section below on quantization for why the default isn't rgb. If the input image is a PGM file, instead of PPM, this option is silently ignored. -bitsched This lets you skip using some possible bit posi- tions in the image. If the file you're hiding is not so big that you need the whole image to store it, you can use this option to hide it better. The argument is just an arbitrary- length string of 1's and 0's - the 1's say which bit positions should be used, and the 0's which should be skipped. The default is to use all bit positions. QUANTIZATION Normally, to store an image in a colormapped file format such as GIF, you first run it through ppmquant. However, if you try to quantize, then stego, and then convert to GIF, you will find that the ppmquant step will fail with an error about too many colors. This is because the stego step increased the number of colors. You might think, ok, stego first, then quantize; nope, the quantization would destroy the stegonographic message. Here's what you do instead: quantize down to half the number of colors you want in the final file, and then use only one of the three color com- ponents to store the hidden file. Using only one bit per pixel, the number of colors can at most double. This is why the default for the -components flag is to use only blue. So, the pipeline to use is: ppmquant 128 image.ppm | pnmstego message.txt | ppmtogif > hidden.ppm SEE ALSO pnmdestego(1), pnm(5) AUTHOR Copyright (C) 1994 by Jef Poskanzer.

1 0

Re: ditz in office
by Duncan Frissell 17 Dec '03

17 Dec '03

Even if the normal parts of the Bush and Clinton Administrations are equally fascist, the Clinton Administration would win in net fascism since it includes an added (unelected) fascist element missing from the Bush administration: Linda Stasi reports in her column "Hot Copy" in the New York Daily News today (Tuesday, March 1, 1994) that she and some other gossip columnists were invited to have tea with Hillary Clinton yesterday. [Hillary was in town to boost her health care program with a visit to a very recently improved Kings County Hospital. The units Hillary visited were specially scrubbed for her visit and contained fewer patients than usual.] Linda says Hillary "...never wants to run for public office herself. But she'd probably get elected in a minute." Think again Linda. You also provided us with another one of those `Hillary's Ominous Quotes of the Day': "AT A CERTAIN POINT, YOUR RIGHTS MUST BE ABRIDGED FOR THE PUBLIC GOOD." The statement might simply be her response to a question about convicted rapists not having to submit to an AIDS test. And then again, it might not. --- WinQwk 2.0b#1165

3 2

Re: standard for stegonography?
by Jef Poskanzer 17 Dec '03

17 Dec '03

I wrote: >offset, wrap-around, bit schedules Actually, that interface is way too complicated and still not that secure. How about if the user just specifies a seed for a random number generator. Then that generator is used to make a *permutation* of the bit locations in the image, and the file's bits are stored in the permuted order. And look, this hides the file-length longword and any fixed file header real well, by spreading them through the image. Now I just have to find a simple but robust RNG that I can include in pbmplus, and some code to generate a permutation of a specified size. I'm not going to have ITAR problems with this, am I? RNGs are still legal to export? Oh, and to answer the original question: no standard. If this idea works, it's clearly better than existing stego systems at hiding the data; that's more important than interoperability. --- Jef

1 0