🚀 go-pugleaf

In <1992Apr11.120743.29655@mnemosyne.cs.du.edu> bfairlan@isis.cs.du.edu (Brian Fairlane) writes:

>I'm about to explain a way to encrypt data, and I expect interested
>people to tell me if it's safe, or under what circumstances it would
>be safe, or what makes it unsafe etc...
>People only interested in putting crypto-beginners down, can continue
>reading without replying, thank you.

>Ok.

>The data is read into memory in blocks of n number of bytes (definable)
>it is then "mixed" in a defined order, for example,
>a block length of 3 could have a key looking like "3,2,1", meaning
>that the third byte in the block will be put at position 1,
>the second byte at position 2 (i.e. at the same place) and the first
>byte at position 3. 
A permutation ob byte level.

>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.

>Even if a block isn't dividable with the longest key's length,
>the Exclusive-Or'ing will not 'wrap' (start at key's first character again)
>Example:
> 
>  Key: "nisse"
>  block: "jajdhidhd0n39dnaldk3j.djsk,dksudj"
>  E-OR w/"nissenissenissenissenissenissenissenisse . . ."
>                                           ^
>                                           | 
>                                           -- does not "wrap"
> 
>Running the null-key/null-byte-file test with this, would, as you see
>result in a null-byte file.
>But when we're talking of files (text, executables) that's been encrypted
>this way, I can't think about how it canbe done, to "crack"/decrypt this.
>Even if you know how it is encrypted/have the program/have the source code.
Whell if the permutation is not known to the decrypter it does give him
a hard time. You can however get statistics which would reveal the length
of the "nisse" string. This based on the assumption e.g. the letter e is used
most often and therefore all elements of "nisse" xored with "e" should
be more often in the encrypted text.
Once you have got the length of the key you can use the same statistics
again to find out that it is nisse and not "uoqqp" or whatever.

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.

>I mean, you don't have the EOR-key, nor the length of the mix-sequence,
>nor in what order the bytes should be placed within the mix-sequence
>(the block).

>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.

>a block length of 3 (mix sequence) can have six combinations;
>"1,2,3" "2,3,1" "3,2,1" "2,1,3" "3,1,2" "1,3,2"...

>if you begin, systematically, at block lengh 1 up to 128... 
>now tell me the number of combinations.
Done above.

>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.
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.

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

>---------
> 
>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?

> 
>      regards,
> 
>        Brian


Nico de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (comming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.