I'm telling you I'm leaving, and why. 1. The list appears to be USA-centric, and Internet covers the whole world. 2. I'm not bragging around about what illegal I did (if I ever did) and why I think I'm right (of course I am! ;->) and why the other guys are wrong (of course they are, indeed! ;->) 3. I expected a lot of tech issues and found instead a bunch of: -discussions on racism, religion, gov't behavior worldwide -"we hate pigs" -US local laws discussions (see 1) -simple fluff and/or flaming. 4. Some smeghead is boycotting the list by subscribing it to other lists, or the list address went into some spammer's archive spreaded worldwide. Sorry, but I don't like all that and can't stand the flow of a list that massively talks about anything else than crypto: that's why I'm leaving (now). For the nuisance of having read this apparently off-topic e-mail message, you should be at least rewarded with a poor man's crypto solution. :-) In Italy we don't seem having a corpus of laws about/against crypto, so it's possible to develop almost anything. Not being linked to general concepts and standards about what crypto is or should be, that's how I figured out the concept of "brute-force key". It's the trivial usage of large keys in non-public key environments, at the expenses of weakening the encryption algorythm. It may seem stupid, but current technology makes it possible and very effective, depending only on the ability of generating good random byte sequences. Let's say you store your key on a diskette that carries at least 170Kbytes (I can, so you should, too ;->). Well, a 170Kbytes key _is_ strong, and performance can be achieved by using a trivial XOR algorythm, in circular or bustrophedic (back-and-forth) sequence if the message to be sent is larger. XOR implies that the key MUST be a long random string, because you might want to transmit a file with long 0x00 sequences, too. XORing 0x00 exposes parts of your key, so they should look undistinguishable from non-null encrypted data, that will appear as random rubbish (that's the purpose of crypto, right? :->). Let's say someone sent you an encrypted file via e-mail. After the file is decrypted (you met in person one night, let's say eating some pizza, and passed the key; it's safer than passing it via modem), you can simply pass it through a Unix-like 'file(1)' utility and establish which program should read it (the message can be a text file, an archive or an executable; cryptanalysis is almost impossible when the spy doesn't know what the output looks like). A neat trick could be using a random sequence that is larger than any message you'll ever transmit (let's say you're using a Zip cartridge, a tape or a CD-Rom instead of a diskette). Another one would be interleaving random "disturbing" data while producing the encrypted file, by all means inflating it, in order to make cryptanalysis much harder. Fantasy is the only limit. Pass the encrypted stuff under stego, and you're 99% save because few people can detect stego and the transmission itself will be hidden for most Bad Guys. If you don't care about ITAR laws (and it seems that you, being the Cypherpunks, actually don't), then you can start developing your own "final" encryption system at any time, being sure it has no backdoors. 1M44, a nowadays' diskette size, is a very good key size that is REALLY impossible to brute-force attack by Your Enemy (that can be, i.e., your Big And Bad rival corporation on the market). For any developer not at a beginner level, the key doesn't need to physically fit in RAM memory and can be directly read from its physical support at need. For smart and very distant geeks, it's possible to use as a key some compressed (pseudo-random) files widely available (a game, an MP3 or such; even operating system portions) and use that "safer-than-nothing" channel to exchange the big key. bye, and have fun with crypto stuff! RDO P.S.- Legal disclaimer: this message and its contents were not developed in the United States. In no way the author is responsible for the use or misuse of this message or contents, nor for the message itself.