🚀 go-pugleaf

Mr. Ritter:

    Thank you for your reply, I greatly appreciate it (and thank you
to the other people who have helped out!  I take back my previous
comments.)  I've taken this information into consideration and I'm
going to answer a few of questions and ask a few questions about
some of your answers.

> If the scheme kept files at *exactly* the same size, I would agree.
> But if the file size changes (increases) at all, then we cannot
> (say) simply encipher disk sectors, and what really matters is
> exactly *how much* the increase is.  Perhaps we should consider DES
> to be equivalently "much more practical" since it also does not
> expand files (except for blocking and size indication).

     The increase is the excess blocking.  I encrypt in exactly 
1024 byte (1K) blocks.  I created this method for telephone and disk
based encryptions -- a "packet" style encryption method.
The excess is never more than 1023 bytes and can be as little as 0.
This all depends on (filelength % 1024) and so only that area is
increased in size.  And DES has that problem as well, maybe not to
the same degree, but due to computer file clusters, this block doesn't
take up any additional space from the drive.   

> >No random numbers will be used anywhere in this encryption.
>
> Normally, random numbers are used as part of a cipher system
> to *solve* serious problems.  A problem which comes to mind
> in this system is whether the internal key-space is provably
> uniformly distributed among the possible states.  If not, then
> we need to assign individual probabilities to the possible
> states in order to understand the overall strength, and this
> can get very complex.

Okay, I can understand this perfectly.  I'll write up an explaination
on how my encryption converts the password line to the 'template'.


> *  Without specific algorithms to examine, key-space limitations
>    cannot be understood, and this is really the heart of any
>    cipher.

I'm assuming everyone knows what a simple shuffle does.  I've already
included an example of my bit substitution.  I'll post the key
generation method soon.

> *  Because of a lack of any statement otherwise, apparently the
>    scheme always enciphers in the same way with the same User Key.
>    If so, this is a serious weakness because it allows anagramming
>    between different messages (and this is the classical method of
>    breaking transposition ciphers).  In general, no cipher scheme
>    should "ever" re-encipher the same data in the same way even
>    with the same User Key.  (One way around this is to first encipher
>    a "really random" Message Key, and use the plaintext Message Key
>    as the internal key for ciphering the actual data.)

You'll have to explain this to me, because I'm wondering if my
implementation doesn't completely by-pass this possibility.
Yes, the 'keys' are the same.  They are also disposed and are not
located anywhere within the file.  PASSWORD and PASSWORDPASSWORD 
are not the same, due to the fact password length is included as
part of the generation of the template (key) but only in manipulation
and not in deducable mathmatical values (you'll see.) 

I've never seen DES encrypt a binary file before, I believe that is
why you refer to it as "plaintext" cyphers.  I could be missing the
point, but I'm not just encrypting data strings that match ASCII.
Every attempt made to crack mcrypt will result in a file that will
be produced as a result of the key.  To prove you have 'broken' the
encryption you MUST create your own way of verifying -- which in
itself is just a guess at the contents.  Even filelength is variable
because failure to give the right key will cause the 'excess blockage'
value to be altered.

The basic random influence is "lack of content knowledge" or human.
If I had a file called "secrets.E" with a filesize of 8192 bytes
it could be decoded into ascii, zip, arc, arj, tar, shar, pak, zoo,
Z, z, or even be DES encrypted or encrypted twice with mcrypt.
This could also be ROT-13 or something just as cheezy.

Even were there as few as a million permutations, how do you
determine if its right?  This is a bad excuse, as I was trying
to gain permutations to the point that technology won't catch
up with this system any time during my lifetime.  I'm still
confident there are more than DES.

Yes, I was attempting to create an encryption that would become
I/O bound as the limit to its speed.  Most other systems become
CPU bound (DES, great example.)  I/O is significantly slower than
CPU and that causes problems repeatitively trying to guess it.

> ---
> Terry Ritter    ritter@cactus.org

-- Eric Knight
   knight@gnu.ai.mit.edu