CDR: about this list, and a poor man's crypto

Marcello 'R.D.O.' Magnifico marcello.magnifico at rccr.cremona.it
Sun Sep 3 16:06:47 PDT 2000


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.







More information about the cypherpunks-legacy mailing list