December 2003 - cypherpunks-legacy

Goodbye, Xenon
by Peter Nestor 17 Dec '03

17 Dec '03

Goodbye Xenon! Some parting thoughts: (1) Stealth PGP -- while the idea is laudable, the "thousand year technology" won't last as long as the "thousand year reich" in the proposed implementation. Steganographically hiding messages in "noisy" channels like JPEG files is easily thwarted by the powers that be. They merely need identify those channels, intercept them, and retransmit the noisy data with their own random noise added, effectively jamming the channel. (2) Anonymous Remailers -- This world is made up of many different types of people, including tight-assed control freaks. If they want to carve out a little nook of cyberspace and control it, why shouldn't theybe able to? Why shouldn't they have their privacy there too, and be allowed to dictate who can and cannot come in? Its all very well to tell them they need locks; but unless and until it is easier for them to install those locks than to raise hell, they will solve the problem of inappropriate posting by raising hell.

1 0

Re: STEALTH OCEANS
by Sergey Goldgaber 17 Dec '03

17 Dec '03

This is my first post to this list, so please don't flame me if I make some trivial mistake. %-> IDEA Re: making random noise files "undetectable"... ~~~~~~~ On many machines the file system allows users to "delete" files without actually deleting them. This is usually accomplished by simply marking the disk blocks that make up the file as free. Thus it should be possible to write an encrypted (noise) file on to disk, pad the rest of the disk with more noise and "delete" the whole thing, making the disk look blank to all casual observers. PROBLEM: If the above idea is implemented, one could not write on to the ~~~~~~~ the disk for fear of accidentaly overwriting the "free" disk blocks. SOLUTION: Knowing the _exact_ location and size of the file, one could write ~~~~~~~~ directly to those block which are _really_ free. 2nd PROBLEM: In order to decrypt the file, one needs to know it's ~~~~~~~~~~~ _exact_ location and size (or use some undelete util)... Which brings me to the... 3rd PROBLEM: An undelete utility could make recovering the encrypted ~~~~~~~~~~~ file trivial for _anyone_. SOLUTION: Make the file undetectable to udelete utilitys by modifying ~~~~~~~~ the FAT table, or equivalent. One would, of course, have to keep track of the file in some other, non-standard, way. FINAL(?) PROBLEM: Implementing the above idea is trivial for the average ~~~~~~~~~~~~~~~~ user. Making and recovering truely undetectable files may not be. All feedback welcome, Sergey

2 2

MONEY: cryptocash is transaction money
by hughes＠ah.com 17 Dec '03

17 Dec '03

I've been getting questions about digital money lately which indicate a basic misunderstanding of its most important feature. Crypto cash is a way of moving money, not a way of holding money. Crypto cash is like a check or a note rather than like the dollar, franc, or mark. Crypto cash is a way of increasing one person's balance and decreasing someone else's balance. Since it's not a currency, it's not sensible to talk about its exchange rates. Digital money can be denominated in any currency you like, so long as you have a bank or other financial institution to handle it for you. This is only an obvious distinction if you already know it. "Money" is such an overloaded word that it's easy to get confused. If this isn't clear, _please_ let me clarify. If you don't get this, none of the rest of the digital money discourse will be understandable. Eric

3 2

Enuf is enuf!
by Bruce C. Dovala 17 Dec '03

17 Dec '03

Hi all! I _pay_ to read what's on this list. I was hoping that it would concern cryptography, remailers, etc. Detweiler was gone for a time. Now apparently it's the current fashion to flame him since he's returned. I'm not gonna pay to read rants against him. Do _something_ or talk in private. Does any of this shit belong on the list? And should I have to pay for it? I _know_ there are good minds out there, but why do I get all of these flames? Not quite what I was expecting. If you wanna talk crypto, post here. If you wanna beat Detweiler into the ground, please do it in private email! I _really_ don't care to hear attacks on another person. (Like that's why I subscribe? NOT!) Bruce

7 6

STEALTH OCEANS
by Gary Jeffers 17 Dec '03

17 Dec '03

note: This letter is composed of 2 different ideas: FIRST GREAT IDEA & SECOND GREAT IDEA. Firstly, congratulations to the cypherpunks that are realizing that strong civilian crypt needs "stealth". For some time I have thought that a crypt file with a crypt header on it was like saying "yes, I am in contempt for refusing to give a password" or "yes, I do require surveillance". A crypt file should look like random bits. The only problem is that files of random bits are not usual & might look a little suspicious. The cypherpunk needs to be able to deny having crypt files even if he is found with random bite files. So how do we do that? Then an idea came into my head! Why not make random bit files rather popular? Then, we would be like stealth fish swimming in stealth oceans. So, how do we make these files popular? Some may find the following ideas foolish. Others may find them unethical. Still others may find them both foolish & unethical. 1. Write a "wipe" program & put it in the public domain. The wipe program uses md-5 to generate random numbers over the user file & then delete the file. A very nice wipe program. However a bug is put into the program: a random number generator is used to decide that in a small number of cases, the new random number file is not deleted! This would leave around a lot of random number files if the program were to become popular. 2. Modify existing programs to generate random number files on occasion. Programs to be found on boards; loose diskettes; etc.. 3. Viruses that generate small numbers of random number files per disk partition or diskette. 4. send random files anonymously over the internet. 5. think up some of your own. note: in all the above, the file lengths should vary randomly & should be well tuned to avoid extremes. SECOND GREAT IDEA (self extracting encrypt/decrypt programs) (when an encryption program is itself an embarrassment.) A self extracting encrypt/decrypt program. That is,like, change PGP so that it looks like a random number file. But with a few cycles would start to unravel itself. Suggestion: 2 "random Number" files that when XOR'ed yields PGP. Probably nothing quite this bare bones & simple. Although something this simple could save your ass if your interrogators were technically unsophisticated, lazy, short of time or short of investigation funds. To do this very nicely would mean some tricky programming & would make the reputation of the programmer/ cypherpunk who did it. IMPORTANT NOTE: I am not a lawyer & do not know the law. In no case do I advocate breaking any law. I see that great idea first may be of questionable legal value. The cypherpunk is urged to consult with local, state, & federal authorities before pursuing these suggestions. Admittedly, that idea could also just be dumb & improper. Think about it. I heap big blessings on the heads of my fellow cypherpunks. Yours truly, Gary Jeffers

2 1

Dos Stego
by Brian D Williams 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Bruce C Dovala asks: Does anyone know of a Stego program for Dos? Well, the only Stego program I've seen other than Mistress Romana's for the Mac is by Black Wolf, here's the readme file; Black Wolf's Picture Encoder (for 320x200x256 ONLY!!!!) Version 0.90a Released into the Public Domain All Code Written By Black Wolf Disclaimer: This program is hereby released into the public domain. I take no responsibilities for any damages it might cause. Use it at your own risk. Description: This picture encoder consists of a group of programs designed to let you capture a picture, encode a message in it, and display it so that it may be captured again into another format with a third-party program, then recapture it and decode the message previously place inside it. It is at a bare-bones stage right now, and includes source code if you would like to tailor it to your own needs. Uses: If you have a need to send sensitive data, but don't want it to be obvious that that is what you are doing, this might be a good program for you. The sender can encode anything he/she wants into the picture and then convert it to .GIF format, .PCX format, or whatever (using a third part program). Not many people will look twice if you receive a picture, whereas an encrypted message might raise an eyebrow or two. Then, the receiver is free to decode it at will. Anything under about 8k can be recorded into one picture - - important letters, lists, small programs (viruses), or just about anything else. If you are sending text, my recommendation is to encrypt with via PGP or some similar program, then encode it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ya gotta love this guy! into the picture for added security. Tech: The programs encodes data into the LSB's (least significant bits) of the picture file - thus, roughly 50% of the colors are changed, but if they are it is only by one pallette value (0-255). If the picture's pallette is based on gradients, then this will most likely be undetectable. Also - ENCODE will put an EOF at the end of the message, so that while there will be garbage at the end of the decoded message it will not be displayed if the file is opened with edit or typed, etc.... The files are as follows: GETSCR - Captures a picture into MESSAGE.SCR when you press PRINTSCREEN while in graphics mode 13h (320x200x256). PUTSCR - Puts the picture in MESSAGE.SCR onto the screen, generally so that it may be re-captured into another program. ENCODE - Encodes the data in the file MESSAGE.DAT into the picture in MESSAGE.SCR. DECODE - Decode the message in the picture MESSAGE.SCR and puts it into NEWMESS.DAT. Example: Say you want to send text to someone, but you don't want it to "appear" that way to anyone who may intercept the message. First, what you'd want to do is find a picture file (like a GIF). Then, run GETSCR and pop the picture up into any picture viewer. While the picture is on the screen, hit PRINTSCREEN and GETSCR will create a file called MESSAGE.SCR for you containing that picture. Then, write your message and save it as MESSAGE.DAT. Run ENCODE - this will take your message and encode it into the picture file. At this point, you need to find a third-party screen capture program that wil work with the format that you wish to use. Run it to make it go memory resident, then run PUTSCR and capture the picture it puts onto the screen. Now you can send the picture to your friend. When he receives it, he can display it, showing that it is, indeed, just a picture file. When he wants to decode it, all he has to do is run GETSCR and display the file - hitting PRINTSCREEN while it is displayed. Then, he should run DECODE and it will create a file called NEWMESS.DAT that includes the message you originally put into the file. I can send this to anyone interested UUencoded, It's about 30k. Brian Williams Extropian Cypherpatriot "Cryptocosmology: Sufficently advanced comunication is indistinguishable from noise." --Steve Witham -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLWPgvdCcBnAsu2t1AQE5zAP9FV1EaJoCJA71LRA5WAmImQG7CrjTo9iW XgqkdfL4sgNQwk0X+jWTel3P8FGSPgQ9CIjRAH8+LVAeFjnQ1X+7ZN6dijcGm09v si6zQQzVWqlM2zcQmep4Gl+wUMNvMUoOShaaYvfbiKBksxTgTHYcVRyjBuCND9fE R02BDtjeDv0= =F/RU -----END PGP SIGNATURE-----

1 0

SENDMAIL: a tutorial on how to add + to your addressing
by hughes＠ah.com 17 Dec '03

17 Dec '03

Here's a little tutorial I just wrote on how to get + syntax in your email addresses. It's a more reliable way of inserting aliases into a remailer than using the comment capability of the address format. This way mail to, say, hh+joebob(a)soda.berkeley.edu could get delivered to whoever was behind the joebob name, by whatever arrangements have been made. The document is written in such a way that you can send this to your sysadmin intact and ask them to install it for you. Eric ----------------------------------------------------------------------------- How to add + to your email syntax --------------------------------- Ever wanted one of those cool <user+@domain> addresses? So you can use <user+loud_mailing_list@domain> and get a filter to easily move the list out from your regular mail? Now you can. This tutorial works if you're running a fairly standard version of sendmail. It requires some hacking to sendmail.cf, so you need the permission to do that; that's usually root. The modifications are fairly straightforward. I. Add + to the list of operator symbols. The sendmail 'o' macro determines how to break up strings in sendmail.cf rules into tokens. In order to be able to recognize + specially, you'll have to add to the operator symbols to make it separately recognizable. So, first do a % grep -n ^Do sendmail.cf 116:Do.:%@!^=/[] Now, go in and edit line 116 and add a + sign at the end: Do.:%@!^=/[]+ That's all. Now sendmail will not include + inside of its tokens. II. Duplicate local delivery rules to accept + syntax. Sendmail is a delivery multiplexer. You want to change the syntax for local deilvery, so all you need to change is the local mail specifications. First, make sure your local mailer is called 'local'. You can search for the mailer definition as follows: % grep ^Mlocal sendmail.cf Mlocal, P=/usr/libexec/mail.local, F=lsDFMmn, [...] I've elided the tail end of the line, because all you really need to ascertain is that the local mailer has the right name. Now you want to search for all the delivery rules that deliver mail to the local mailer: % grep -n '#local' sendmail.cf 563:R$-<@$w> $#local$:$1 585:R$-<@$D> $#local$:$1 user(a)ah.com 614:R$+ $#local$:$1 everything else I have three rules for local delivery. (The second one is custom, and allows for delivery to a domain address for which no IP address exists.) All you do now is to add a rule for '+' delivery for each kind of existing local delivery. After I changed mine, it said: % grep -n '#local' sendmail.cf 563:R$-<@$w> $#local$:$1 564:R$-+$*<@$w> $#local$:$1 586:R$-<@$D> $#local$:$1 user(a)ah.com 587:R$-+$*<@$D> $#local$:$1 user(a)ah.com 616:R$-+$* $#local$:$1 everything else 617:R$+ $#local$:$1 everything else Rules that matched "$-", a single token, I changed to match "$-+$*", a single token followed by "+" followed by zero or more tokens. Rules that matched "$+", one or more tokens, I changed to match "$-+$*", same as above. I added the changed rule _before_ the original rule because otherwise the $+ would swallow up everything. The $1 in the second column refers to the first macro to match in the pattern in column one. That's the username the mail gets to delivered to. If you have more complicated usernames, you're likely already a seasoned sendmail trooper. III. Install and Test You should probably increment the version number when you make the change. It's in the 'Z' macro, do % grep -n ^DZ sendmail.cf 104:DZ2.06 Freeze the sendmail configuration with sendmail -bz otherwise your changes won't take effect. Now send yourself some test mail and make sure it works. Eric Hughes hughes(a)ah.com 17 February 1994

1 0

Re: Enuf is enuf!
by walter kehowski 17 Dec '03

17 Dec '03

I use NeXTmail so I just sort (by subject, name, or use the finder) for detweiler and put everything involving him in my ---JUNK---.mbox. I trash my ---JUNK---.mbox periodically. Solves that problem. However, maybe ignoring detweiler would be the best thing to do. Walter A. Kehowski <wak(a)next0.math.pitt.edu>

1 0

REAL WORLD ENCRYPTION
by Sandy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, Here are some more digital banking thoughts for you to chew on. DEPOSIT INSURANCE--Private, Lloyds-type deposit insurance is readily available internationally. We will have such private insurance. In addition to guidelines mandated by our insurer, we will also be under the regulatory oversight of the jurisdictions in which we operate. Finally, an more importantly, we will operate under very conservative internal policy constrains and will maintain extremely high reserves to avoid problems in the first place. Stay tuned. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLWQ53U5ULTXct1IzAQH0vgQAmEbjA7Gtu0f/4vGolhdGkI5pQ+bswBbS PY36O78/zYXPgU1pW7qC6ztmVrsjS//+WBjkAGCnyzp0VQAnMHlEuSZ6vhMVQZ22 diXysLI80VEjPFnb2skvQHaFNp1e38rlk0WPE2rTi6MGIYor2+G5/gcAtd8gDixA wyMqL4oFlio= =Djs0 -----END PGP SIGNATURE-----

1 0

remailers going down
by Eric Hollander 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- the remailers pmantis.berkeley.edu and cicada.berkeley.edu are going to be phased out. too much garbage has gone through them, and it has caused too many complaints, and these are bio research machines, so that's not what they're for anyway. i will leave the software running on them for a while longer, but please stop using them. 00x@uclink has been shut down. the sysadmin on uclink set it up so that no user may have executable files in his account. this meant that it didn't work, so for a while i was just forwarding it to soda, which then remailed, but i just shut it down because the account is going away soon anyway. soda.berkeley.edu is still up and running strong, and it will be for the indefinite future. also, a new alias-based, pgp-encrypted remailer is coming on line soon. in fact, parts of the code are already in testing. the code will be quite portable and relatively easy to install. when it is completed, hopefully other people will set up alias remailers from their accounts. e -----BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLWQX+5SNMq4JDJ1TAQE8WgH7Bz3yPyBQ03Q3SAzTH6diMLB68JOsGMSP 7nNo1LOupPpUM8r0hAeLo9DWx23y92HlCjSmtwW//pEIIP/ef3XRRw== =DHV3 -----END PGP SIGNATURE-----

1 0