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

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

In article <1992Apr11.170301.4743@mnemosyne.cs.du.edu> bfairlan@isis.cs.du.edu (Brian Fairlane) writes:
>                     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

This was discussed recently, and I think I can recount the discussion
fairly easily.  Basically, the use of the three keys in this context,
of length 5, 6, and 15, respectively, is equivalent to the use of a
single key of length of the least common multiple of these, i.e. 30.
Thus, the unicity distance will be 30. Given a sample of say 60
characters of output, you would almost certainly be able to discover
this unicity distance by shifting, xoring, and then computing
frequencies. (The redundancies are quite significant; it came as a
surprise to me that so few characters would enable one to spot the
unicity distance.)

So then you are down to a polyalphabetic cipher, that is, effectively
30 separate ciphers. (Actually 29, as the combination 'sae' occurs
twice each thirty characters, another not-very-surprising
demonstration of redundancy at work.)

The permutation at this point contributes relatively little to the
security, as permutation of groups of say 5 characters merely means
checking 120 possible permutations. This is well within the bounds of
brute force, and I imagine that digram or trigram frequencies could be
used to unravel much larger permutations once the individual
characters are back in the right "alphabet". I don't think
permutation-only ciphers have ever been used successfully, although I
an happy to be proven wrong on this.
--
Greg Rose                 Australian Computing and Communications Institute
ggr@acci.com.au                                              +61 3 282 2517