From: bfairlan@isis.cs.du.edu (Brian Fairlane)
Subject: Re: Simple encryption(?)
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Sat, 11 Apr 92 17:03:01 GMT

>>Then, it is Exclusive-Or'ed with one or more keys, with different
>>lenghts.
>Where do those keys come from? Are they specified or generated.

Of course they are manually specified.

>Of cource you can claim "but if I use enough different and long keys" but
>either the key defenition becomes large or there is a statistical weakness.
>When the keydefenition becomes large you might as well make it as large as
>the plaintext and random as well than you encryption system is flawwles
>without needing the permutations.

Well atleast you got a sense of humor.

>>Can somebody please, with a mind for mathematics, calculate how
>>many combinations there are, considering a EOR-key can be of
>>any length, as well as the mix-sequence, as well as the number of EOR-
>>keys differ, and the lengths of all keys can be of (any) size/length.
>>(if somebody feels like challenging their intellect, let's say
>> the mix-sequence may be, at most 128 bytes, and three EOR-keys can
>> be at most 16 bytes each).
>Well the mix would be 128! is about 3.8E215 possible permutations (notice
>that you need 90 bytes to define such a permutation).
>The number of length combinations would be 16*16*16 is 4096 possible length
>combinations with in the worst case (all length 16) 2^48 is 2.8E14 possible
>EOR key defenitions.

90 bytes to define where to put each byte in a 128 byte block? How the heck
did you do to get that number? You'll need 127 bytes to define where
to put each byte in a 128 bytes block. (since the last byte can only be
placed at one not-so-far-used position)

>>Then add that number to the number of combinations possible from
>>three individual-length (let's say up to 16 bytes) keys, put
>>together!
>OK so you get an impresive high number. But that is not important. Important
>is how easy one can crack it. 3 keys of at most 16 bytes are locatable if
>the encrypted text is long enough (statistics and the always amazing
>determination of a cracker). You don't BTW explain how you chose the order
>in which you use the 3 keys. If you just use them cyclic you could also call
>it a sibgle key so there should be some "mixer" as well for that.

currently like this:

                     data : This is the text I want to hide from the NSA
            key1 (nisse)  : nissenissenissenissenissenissenissenissenisse
            key2 (bagare) : bagarebagarebagarebagarebagarebagarebagarebagare
   key3 (towerofeiffel's) : towerofeiffel'stowerofeiffel'stowerofeiffel's

And is after this, misplaced within the block. You cannot find patterns
of words or anything, before you have tried (many/all) combinations of
how to place each byte within the block (which the "enemy" doesn't even
know the size of).

Statistics of this wouldn't help anyone... would it? (I'm the one to be
taught, you know)

>The 128 byte clusters are very sensitive for plaintext attacks. If a 
>cracker knows or guesses part of the text ( by e.g. throwing parts of
>an English dicto\ionary at the problem) he can deduce (again hard to do but
>definitely not impossible) find out what permutations you used.
>You might try to "solve" the problem by chosing even larger numbers but
>your key is unaceptable large for most aplications already.

I would have guessed. For My information, how large may a key be without
being unacceptable? And who decided that? (sounded a bit sarcastic,
I apology, but it isn't)

>Most existsing encryption schemes are much more complex than yours. For
>start they operate at bit level which makes statistical tricks harder.

I know that. I was trying to show that one doesn't need a very complicated
algorithm to encrypt data, but still consider it "safe". (w/o having to
EOR the data with files as long as the original file).
 
>>To clear a few things here. I hope it's not your "goal" to
>>have an algorithm, that makes the use of one-key encryptions
>>safe? That's kind of stupid, I'd say... I'll appreciate anyone who'll
>>enlighten me on this one as well...
>Probably pure stupidity on my side but what do you mean by this?

When creating encryption algorithms "out there in the world"... do one
have the rule, that there may only be One key?

   Brian