December 2003 - cypherpunks-legacy

No Subject
by cowen＠glia.biostr.washington.edu 17 Dec '03

17 Dec '03

about joe6pack>>> though joe 6-pack might not vote, and likely won't even understand about the crypto of it all. he would understand the police listening in on his conversations with jill 6-pack. and not like it to well. i do think though that the ge that the general public should know, what the congress is getting itself into other topics before congress get aired why not this one. making it simple for simple minds, might be beyond some folks though there has been talk here about how to go about the process. which on the surface looks so easy. but the general populace of the US of A has a bit of problem with concepts at times. big bangs and lots of noise and death, that sure does catch attention, for about 20 seconds. the computer folks are going to be fighting with the gov't types til the end of time and the joe 6-packs are going to be stuck in the middle. but we need them more than we need to alienate them. they do pay taxes, some of them do vote, and some of them are the rich and famous we want to get our point across to. not every rich man knows about computers. we as a group or as individuals should at least try to let the joe 6-packs that we know in on the secrets the gov't and the FBI and the NSA are trying to hide from him. maybe that is the point of a so called free nation. and sure we might not run this country, but public outcry most times turns heads in congress. charles the monster maker

1 0

RE: New mailing list?
by Blanc Weber 17 Dec '03

17 Dec '03

"I want each reader of these words to reflect on the phrase "implementing culture". If you do not realize the magnitude of this principle and have some respect for its enormity, I would sincerely suggest that your time would be better spent reading some political philosophy and some technological history and pondering over your desires, to make sure that you know them." Okay, Teach. :>) Thanks for the clarification, Eric. I remember some critical statements made about your attitude toward modifications to list and the suggestions which you apparently shot down. I remained silent but wondering. "Cypherpunks is where the politics meets the code. .... Policy separated from development lags the reality of deployment, and necessarily. " These are some things I have thought about, upon reading complaints against the tangential discussions which come up on the list: It is not unimportant to engage in these conversations as they develop, to allow for the associated efforts to achieve precision on attitudes/expectations which counter the rest of the intellectual atmosphere of acceptance, especially when one might be required to produce just cause why things should go in one direction (yours) rather than another (theirs); when you might have to answer to 'authorities' for non-complicity to collectivist programs. Some people do (and some should) struggle for better justification in their own mind, of their position relating to what they themselves do (writing & distributing code which permits alternatives to government-supplied arrangements), of what they advocate to others that they ought to do (positive or negative support for a method/plan of action), or would prevent (as in thwart the progress/implementation of Clipper). It is not unimportant to be clear about the propriety of the motives behind an argument, to be satisfied that one is correct - that it isn't merely 'whining' because one is not getting one's way, or because the government & its advisors are not sufficiently lenient in their outlook; that there is philosophical, logically consistency in the actions/solutions proposed. It is not unproductive to maintain a general awareness among all those who would deem to be of the same "attitudinal alignment". Else how could such a group survive as advocates of ideas promoting complete independence & total autonomy. (euphemism) I myself would welcome the existence of a more thorough elaboration on this subject, from yourself and the others who founded the list: an explanatory FAQ for reference, especially on the matter of "implementing culture", since this implies more than simply effects dealing with government. Blanc

1 0

Stealth PGP
by Hal 17 Dec '03

17 Dec '03

I never saw the posting below here, only on sci.crypt. It seems relevant to the present discussion. I did take a look at the source code to stealth pgp; it is quite simple and nicely done. However it doesn't do anything special about disguising the encrypted session key. It just strips off the two length bytes PGP puts at the front. Not only is this revealing, it also doesn't always work. Apparently the program can't always reconstruct the original mpi length if the encrypted key's size happens to be much less than the modulus. It does print a warning in that case that the file won't be able to be de-stealth'd successfully. Stealth PGP is a nice start but it needs to be improved to be truly stealthy. > >From: qwerty(a)netcom.com (-=Xenon=-) > >Subject: Stealth for PGP Available. > >Message-ID: <qwertyCLpztC.4n8(a)netcom.com> > >Organization: PGP Info Clearinghouse. > >Date: Thu, 24 Feb 1994 08:34:24 GMT > >Lines: 188 > > -----BEGIN PGP SIGNED MESSAGE----- > > I have placed Stealth1.0 up for anonymous ftp at netcom.com in > /pub/qwerty as stealth.tar.Z. I am not the author of Stealth. "Henry > Hastur" is the author. I will gladly forward mail to him if you tell me to > do so. My address is qwerty(a)netcom.com. So far it is only written for > Unix, so don't e-mail me asking for a DOS version or whatever. I'm just a > cheerleader and propagandist, who finally got some very kind soul to > "write me a real encryptor". > > Why Stealth? Wired magazine just gave a plug for the Mac program "Stego" > (ftp to sumex-aim.stanford.edu in /info-mac/cmp) by Romana Machado, which > will, like any steganograph, hide a message in a carrier message. Problem > is, anybody can reverse it, and if you are using PGP, immediately tell > you are one of those drug dealing, child molesting, cryptography users ;-). > Once Stealth is incorporated into such steganographs, then people can't > easily tell that what they've extracted out of that picture of Madonna is > even a message at all. If they don't have the right secret key to decrypt > it, then all they get is garbage. "What message?!" > > Questions: > > 1) What does Stealth have to do with farming? > 2) How do stealth encryptors make the Clipper chip look like a stupid > waste of YOUR tax money? > > [Answers: 1) Zip, 2) By demonstrating that even if the Clipper keys are > stolen, without your secret key they can't even tell you are using PGP]. > > -=Xenon=- > > Stealth V1.0 by Henry Hastur > ---------------------------- > > Stealth is a simple filter for PGP which strips off all identifying header > information to leave only the encrypted data in a format suitable for > steganographic use. That is, the data can be hidden in images, audio > files, text files, CAD files, and/or any other file type that may contain > random data, then sent to another person who can retrieve the data from > the file, attach headers, and PGP decrypt it. > > Stealth is not intended to replace the standardized methods of using > encryption (e.g. ASCII-armoured PGP email) ; in an ideal world we would > all be able to send openly encrypted mail or files to each other with no > fear of reprisals, however there are often cases when this is not possible, > either because the local government does not approve of encrypted > communication, or perhaps because you are working for a company that > does not allow encrypted email but doesn't care about Mandelbrot > GIFs. This is where Stealth and steganography can come into play. > > > Compiling > - - --------- > > Stealth has currently only been tested on BSD and SVR4 Unix (and as > such should work with most varieties of Unix), with both non-ANSI > compilers and ANSI compilers with 'minimal ANSI' flags. In order to > compile the program, you should just be able to extract the files > from the tar file provided, then type 'make'. If that fails you may > need to change the definition of CC and CFLAGS in the makefile to > get it to compile. On machines with gcc, the GNU C compiler, Stealth > can be compiled by simply changing the 'CC=cc' line in makefile to > 'CC=gcc'. > > Stealth has not yet been tested on MS-DOS, but the only likely problems > are with 16-bit integers (you may need to change some occurrences of > int to long in order to get stealth to work), and you will need to > remove the -DUNIX flag from compilations. Hopefully, version 1.1 > will be released shortly with full DOS compatibility. > > > Usage > - - ----- > > Stealth always reads from its standard input and writes to the standard > output, though when adding headers to data the data has to be stored in a > temporary file (see Security Concerns below). > > Command line arguments : > > -c Conventional encryption used rather than public key > -a Add headers (defaults to strip headers) > -v Verbose output. > > Stealth needs to be able to find your pubring.pgp file, which it does > by first checking in the directory pointed to by $PGPPATH, then the > current directory. > > > Examples > - - -------- > > To encrypt a file with PGP and store it in the file pgp.stl prior to > sending : > > pgp -ef < secrets.dat | stealth > pgp.stl > > To encrypt a file with conventional (IDEA) encryption, and pass to a > steganography program called steg_program : > > pgp -fec < secrets.dat | stealth -c | steg_program > > To take the output from a steganographic extraction tool, add headers > for key "Your Id", and decrypt : > > steg_program | stealth -a "Your Id" | pgp -f > secrets.dat > > To take the conventionally encrypted output from a steg program, attach > headers and decrypt : > > steg_program | stealth -ac | pgp -f > secrets.dat > > > Limitations > - - ----------- > > Files can be signed, but can only be encrypted to one recipient - extra > RSA headers for all but the first recipient will be stripped from the > file. In addition, if you specify conventional encryption but pass an > RSA-encrypted file into the filter the RSA-block will be stripped. In > either case, stealth will print out warnings to inform you of this. > > Stealth provides no support for ASCII-armoured PGP messages - it will > only work with the binary output format, and the output will have to > be converted to a useable form after processing, either with a > steganography program or a standard utility such as uuencode. > > Finally, for technical reasons there are potential problems with public > keys of size (typically) 2^n + 1 or 2^n + 2 (e.g. 513 or 1026). If you > are encrypting to a key of a peculiar size, it's possible that the algorithm > used to add headers could fail, but fortunately this can be detected while > stripping the headers, and a warning will be printed. If this warning > appears, > you will probably want to encrypt the data again until a suitably sized > RSA-block is created. > > It is NOT neccesary to remove garbage data that the steganography program > may have added to the end of the PGP-encrypted data. PGP output contains > an encrypted end-of-file mark that allows the program to decrypt correctly > and ignore any trailing garbage. > > > Security Concerns > - - ----------------- > > After passing through the stealth filter, the PGP-encrypted data is > essentially white noise, with no identifying marks, and whilst it may > well have enough peculiarities for an expert cryptanalyst to recognize > it as encrypted data, the probability is much less than would be the > case with a PGP header identifying the recipient attached. > > One other concern is that stealth has to create a temporary file when > reading in data to attach headers, and depending on the build options > chosen the program will store it in either $PGPPATH, the current directory > or /tmp. On Unix machines, the file will be deleted as soon as it is opened, > making it difficult to capture, but on other operating systems the file > will only be deleted when it has been used. (In either case the file will > be zeroed before being closed). > > In addition, some operating systems will use temporary files on your disk > to emulate unix pipes (e.g. MS-DOS) - these files will not be zeroed when > finished with ! > > > Export Restrictions > - - ------------------- > > Stealth is probably not covered by current export restrictions under the > US ITAR regs, but I'm not a lawyer, so if in doubt check it out yourself. > It was written outside the US and imported, so should soon be available > on some European ftp sites as well as US sites. > > > Henry Hastur > > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.3 > > iQCVAgUBLWwfawSzG6zrQn1RAQEjlQP/d85opZ6aMXfFpDu/KQz0DAzFxXNjiSZy > 9l56kIUkmAx0aT5qF3UAg2UTDagiJlFNz6UXFhEKBkDV4JLJPq5C8HtsdpCiSLWr > vVD2IEdASEd9ALCQMLS/YxVv6GG85n+phyoEV5ALsD1f0y4Nbk2Gfb+rexk5rN3a > hFYRUekVuNY= > =pkdK > -----END PGP SIGNATURE-----

2 1

stego
by Loren Fleckenstein 17 Dec '03

17 Dec '03

I'm a newspaper reporter researching a how-to story on crypto. 1) Besides RIPEM, PGP and ViaCrypt PGP, any suggestions for capsule reviews of other public-key products? I'm interested only in public-key implementations. 2) Are there stego programs out there that will weave cipherdata into digital pictures or audio? 3) Has anyone reviewed the AT&T secure phones & modems? Your thoughts? Please reply by e-mail as I am not a list subscriber. I also am a big believer in encrypting all traffic, so here is my public key. I am not looking to quote anyone -- all I need are ideas. However, if you say something temptingly quotable, I'll email you back for permission. Short of your grant of permission, I consider your material for background purposes, i.e., I'm free to use it without attributing where I got it. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.4 mQCNAi16V84AAAEEAMNVRFU+CqFRhaOnnZ5hdY8D0o/3tdwzV08D1p/gLP9l8fYZ LKVFsuIQKzna4PSMoJyeUVWUcBftLQCNX0K+phzqTdpMPEnH82ToH8JGgRg873Fq WaQkzj3M+K3ExYVC2EVFfAvOa1iCyRCSrEr2hfQOP99XYMFS7w8UUf0SamE5AAUR tAVsZGZqcg== =nH+6 -----END PGP PUBLIC KEY BLOCK----- -- Loren Fleckenstein 37211.3713(a)cserve.com reporter, The Press-Enterprise office tel. (909) 654-0564

2 1

Re: some technical steganography
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Eric Hughes wrote: > > >What does "appears relatively random" really mean? How do you > >measure the randomness of a sequence of bits? > > Randomness is the wrong measure. Suppose I take 2^10 > random bits and prepend 16 zeros. How random is this? > Almost as random, and this can be made precise. How > compressible is it? Almost incompressible. Now, what > about 2^20 bit? 2^30? > > It is not randomness but recognizability which is at issue. > One of my assumptions was that the stuff you're trying to hide is not recognizable. In one of my posts I used the phrase "unremarkable encrypted message". I should have said "unrecognizable encrypted message". I assert that an "unrecognizable encrypted message" will be a random sequence of bits. Is my assertion correct? Should I be using the phrase "high entropy" instead of "random"? Assume for the moment that there is a way to produce an unrecognizable encrypted message using public-key encryption. (I leave it to the experts to figure out the best way do that.) I still believe that if the reverse stego process frequently produces high entropy bit sequences, even if there is no hidden message, then the steganography system is successful. If the reverse stego process *always* produces a high entropy bit sequence, then the steganography system is perfect. Of course, this assumes there is no other way to detect a hidden message besides reversing the stego process and testing the result. Obviously, if the forward stego process (inserting the bits) leaves telltale traces, then it doesn't matter what the reverse stego process produces. To summrise, I believe a successful steganography system will include the following steps and have the following properties: step 1) encrypt you plaintext. step 2) hide the encrypted message in a public message (duh) property 1) the result of the encryption step should be a random sequence of bits. property 2) the bit insertion process must not leave telltale traces. property 3) the reverse stego process should product frequent "false hits". In other words, the reverse stego process should frequently produce high entropy bit sequences, even if there is no hidden message. Am I correct? Jim_Miller(a)suite.com

2 1

better way to generate a permutation?
by Jef Poskanzer 17 Dec '03

17 Dec '03

I'm putting the polish on pnmstega/pnmdestega. Currently they spend the largest part of their time generating the permuted list of bit positions to use for storing the data bits. Not surprising, I knew the first version would be slow - it actually mallocs an array, fills it with numbers, and shuffles them. Now I'm looking for suggestions on better methods. I looked in Knuth, Sedgewick, and Schneier, and didn't find anything. Send email if you've got an idea. Something with a bit vector might work. --- Jef

1 0

Update on user-level hack to do telnet encryption posted recently
by hughes＠ah.com 17 Dec '03

17 Dec '03

Perry doesn't like Graham's hack for telnet style encryption. Graham doesn't like Perry's attitude. Such a _small_ teapot. For the forseeable future, there will be the need for link encryption where one is connecting to a site where the far end doesn't have encrypted telnet available, _for_whatever_reason_at_all. There are lots of reasons, e.g. site managers are busy and the user did not plan in advance. It doesn't really matter. If you can't alter the remote end except by a user process, that's what you use. Perry is absolutely correct that this hack is very bad as a long-term solution, but it is labelled a hack, after all. Nevertheless, there is need for a short term solution. Graham seems to have provided one part of that. Great. Just because you shouldn't need to be using it in two years is no reason to say it shouldn't be written. Eric

3 2

No Subject
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Everyone's talking about encrypted telnet. Has anyone at least READ the Kerberos FAQ? It's been in use for a while, and, to quote... > Kerberos is a network authentication system for use on physically > insecure networks, based on the key distribution model presented by > Needham and Schroeder.[3] It allows entities communicating over > networks to prove their identity to each other while preventing > eavsdropping or replay attacks. It also provides for data stream > integrity (detection of modification) and secrecy (preventing > unauthorized reading) using cryptography systems such as DES. > Practically speaking, Kerberos is mostly used in application-level > protocols (ISO model level 7), such as TELNET or FTP, to provide user > to host security. It is also used, though less frequently, as the > implicit authentication system of data stream (such as SOCK_STREAM) or > RPC mechanisms (ISO model level 6). It could also be used at a lower > level for host to host security, in protocols like IP, UDP, or TCP Being more 'official' than PGP, only a totally export-safe version has got out to ftp.funet.fi. Of course, it could be possible to patch PGP or something else into Bones, as the non-encrypting Kerberos is called. > An experimental Telnet Authentication Option has been > defined, and is described in RFC1416. (see also RFC1411). > These RFC's only define how > /authentication/ is to be performed; the standard for full encryption > is still under development. > An implementation of Kerberos V4 telnet is available via anonymous ftp > from ftp.uu.net, in /networking/telnet.91.03.25.tar.Z, but it predates > The IETF Common Authentication Technology Working Group is > currently defining security extensions for the FTP protocol. An > Internet Draft describing their work, and the source code for a > modified ftp/ftpd with the extensions, are now available > thumper.bellcore.com:pub/lunt/ftp.tar.Z > net-dist.mit.edu:tytso/ftp-wg/ftp.tar.Z ----------------------------------------------------------------------- Rishab Aiyer Ghosh "What is civilisation rishab(a)doe.ernet.in, rishab(a)dxm.ernet.in but a ribonucleic Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" H-34C Saket New Delhi 110017 INDIA -----------------------------------------------------------------------

1 0

No Subject
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

sdw(a)meaddata.com (Stephen Williams): > on pictures with few colors and a large amount of a small number of > colors (like cartoons, etc. with a backround), you could use the > unused color table entries. You set these to be the same colors as > the correspondingly largest used colors and use them when juxtaposed > with their color. This, and other similar methods will of course only work with GIFs; the problem is that GIFs compress, and the loss of compression caused by adding to the color table could be noticed, as could the fact that there are multiple entries with the same value. It's also somewhat more complicated for stego users to figure out where the data is - unless you use a 'standard' header or format, which is as known to the NSA as to cypherpunks. What worries me more about many stego methods is their assumption that 'stegging' a picture will not be noticed. I am not so sure, even if you stick to the LSB of an 8-bit blue channel of a 24-bit hi-res scan. Things like the abnormal frequency of 1s as mentioned earlier, are almost as easy to build into your stego program as to detect. I've worked a lot with images, particularly image recognition, and have seen many surprising similarities among pictures of some category that are human-noticable only after considerable statistical analysis (or filtering through sophisticated neural networks). It may well be possible to develop highly CPU-intensive techniques that can detect, or indicate suspicion towards, 'stegged' images. Unless, of course, equally complex stego techniques are developed, which will probably have the extremely low message-to-image ratio of the old 'letter to granny' codes. (Message in third letter of alternate words, etc., in innocuous, plausible letter.) This whole cat and mouse game with the authorities reminds me of the reaction I had to the story in Wired 2.02 on the Stealth watchers. OK, intrepid renegades take zoom-lens photos and listen in to secret frequencies, but only because US authorities don't REALLY mind. Come on, if Big Brother were really serious, Phil Zimmerman (and most of us on this list) would have been shot long ago, democracy be damned. As it so happens, PEOPLE still vote, not SPIES.

1 0

Re: Stealth PGP
by Matthew J Ghio 17 Dec '03

17 Dec '03

There are actually several clever ways that you can get around the problem with the RSA encrypted data being less than the modulus. The simplest is to encrypt it more than once. Suppose you have a modulus m of legnth n. You then create a block of data to encrypt, b, of legnth n. If b is less than m, encrypt it with RSA. If not, don't encrypt it. Then take 2^n-b-1 (which, btw, is the same as xoring b with all one-bits). If that result is less than m, encrypt it with RSA. Since m is greater than half of 2^n (it must be, otherwise it would be less than legnth n), all possible plaintexts will be encrypted at least once with RSA, some twice. This does leave a somewhat uneven distribution of values when comparing plaintext and ciphertext (which can be minimized by more encryptions), but that only shows up when and if the message is decrypted; as long as you use random padding properly before encrypting, the encrypted data will look completely random. My ideal "Stealth-PGP" would work something like this: Take a file, encrypt it with a random session key, prepend the session key to the file, encrypt the first n bytes (which include the session key and part of the encrypted data) with RSA if it's less than m, XOR it (reverse all bits), and then encrypt with RSA if that's less than m. Actually, putting the data inside the RSA might not be a good idea, it would not work well for small files unless you added a legnth byte. Maybe the RSA part could just be filled with random padding...

1 0