🚀 go-pugleaf

     Greetings.  I've spent a deal of time researching an encryption
method used for encrypting computer files.  I've decided to make this
program available to the public (maybe the United States public should
it be illegal to export this software outside the US - I'm still
awaiting confirmation on this from NSA authorities.)

     Regardless, I was asked to release a "simple explaination" of
the Mass Encryption program I've been working on to sci.crypt so that
people can bang on it and tell me if there are some gaping holes
in my implementation.  Part of this is literature I typed up for
vague descriptive reasons, and the following parts are more detailed
analysis.  

-----------

     Mass Encryption is used to scramble large files of data to the point
they no longer are recognizable by onlookers.  This particular system of
encryption keeps the files at nearly the same size as they were prior to
undergoing the encryption process.  This makes mcrypt a much more practical
method of protecting your important information.

     This particular encryption has the following parameters that relate
to how secure it is:

Password Length:                   up to 1024 letters
Case Sensativity:                  YES
Alpha Letters:                     YES
Symbols:                           YES
Space Bar:                         YES
Control Characters:                NO 
Permutations:                      254 ^ 1024 (?? -- see below) 
                                   (password line: 95^1024! (factorial) )
System of Encryption:              Bitwise Matrix Substitution
                                   with Byte Substitution
                                   prior to bitwise.
Password Validation:               NONE
Encrypted Data Specification:      Packets of Data 64-1024 bytes in length
                                   (64, 256, & 1024 .. 2^6, 2^8, 2^10)     

Description:

     Mass Encryption deviates from the standard encryption processes in the
way that it treats all calculations in base 2.  Previous encryption standards
dealt with data in either base 10, or in byte sized chunks (base 2^8).  By
using the smallest donomination of mathematical unit, Mass Encrypt has the
advantage of being extremely complete in the shuffling of data.

    Also, because computers work faster with base 2 numbers (given that the
most basic and shortest cycle manipulations are bitwise in any CPU) the
encryption methods used in Mass Encryption are optimized to reasonable
speeds despite the security of this program.

    The first argument of "mcrypt" would be the password.  This password
is then converted to a matrix which attempts to shuffle the information
provided to the point that the password line itself cannot be recreated
from this, the "key" grid.

     The incoming packet is then reassigned bytes.  The key to this
is generated off of the password line.  The reason this is done is due
to the fact that mcrypt's bitwise encryption doesn't alter bits, it
places them differently.  Therefore, it is reasonable to assume if you
total up all the 1's and 0's in a large file, and find they are
identical to the total 1's and 0's in an encrypted file, they are
probably the same file.  By reassigning each byte a different value,
the total bit counts will be altered making file comparison impossible.

     The Key Grid is then used as a template to place bits from the
incoming data packet into the encrypted packet.  The assignments of
bits happens twice, once for each positive bit and once for each
negative bit.  This means that the first byte could have data from
up to 8 different bytes, but no less than 2.  Under no circumstances
is any complete byte placed in a sequence of 8 bits in the encrypted
packet.

     The encrypted packet is then written out, in the case of this
varient of mcrypt, to the file.  The byte offset is stored in an
encrypted packet at the end of the file.  The reason why it doesn't give
a straight filelength is because verification of password attempts
adds an additional way for people to break mcrypt.

     Besides Mass Encryption having a huge permutation set (DES is only
2^47 and that takes an "unreasonable amount of time to break"), it also
is disk based.  Because of that, it is unreasonable to even use a
dictionary to break encrypted files.  Even though CPU speed has increased
many hundreds (if not thousands) of times in the last 10 years, the
speed of disk based I/O hasn't made as great of strides. 

     Even were RAM disks used, or even a single packet monitored, because
there is no validation method used anywhere in this program, a program
would have to be written in order to validate.  100% validation is not
possible, due to the fact bits are shuffled so badly.  If something did
appear, it could be argued that after manipulating bits the way they
were doing, it could just be coincidence.  

    After the encryption of the file is finished, the key grid and
all tables generated from the password are discarded.  They will be
properly recreated when the same password is used to decrypt it.
No random numbers will be used anywhere in this encryption.

-----------------

     Here is more information for people who wish to examine the
inner workings of mcrypt.  This part gets somewhat technical.
The following is a computer generated report using DEBUG mode on
my Mass Encryption program.  It explains where each bit is placed
an why.  I've set it to use only 4 bytes of data and a 4 digit
password (I used "pass").  After "pass" was used to create the
KEY (Called "reference grid" below), what remains is the bit template
used to place the bits in the outgoing data grid.

     Basically, Inverse mode explains that the computer will now
stop placing data in locations of 1 bits, and then place data in
locations where 0 bits are.  This is kicked in twice (second time has
no effect) because it activates when the end of the key grid is 
reached (which happens once for each type of bit.)

Key:

x, y         =  position of current uncrypted data being worked on
p            =  which bit is currently being worked on
ex, ey       =  encrypted grid data -- what byte is being altered
  

CURRENT VALUE OF ENCRYPTION REFERENCE GRID

244 143 
236 11 

INCOMING DATA:
10 42 
47 32 

ASCII:


/* 

Total Bytes in Block: 4

Inserting 0 (pos x:0 y:0 p:0) bit @ (ex:0 ey:0 p:2)
Inserting 1 (pos x:0 y:0 p:1) bit @ (ex:0 ey:0 p:4)
Inserting 0 (pos x:0 y:0 p:2) bit @ (ex:0 ey:0 p:5)
Inserting 1 (pos x:0 y:0 p:3) bit @ (ex:0 ey:0 p:6)
Inserting 0 (pos x:0 y:0 p:4) bit @ (ex:0 ey:0 p:7)
Inserting 0 (pos x:0 y:0 p:5) bit @ (ex:1 ey:0 p:2)
Inserting 0 (pos x:0 y:0 p:6) bit @ (ex:1 ey:0 p:3)
Inserting 0 (pos x:0 y:0 p:7) bit @ (ex:1 ey:0 p:5)
Inserting 1 (pos x:1 y:0 p:0) bit @ (ex:1 ey:0 p:6)
Inserting 1 (pos x:1 y:0 p:1) bit @ (ex:1 ey:0 p:7)
Inserting 1 (pos x:1 y:0 p:2) bit @ (ex:0 ey:1 p:0)
Inserting 1 (pos x:1 y:0 p:3) bit @ (ex:0 ey:1 p:1)
Inserting 0 (pos x:1 y:0 p:4) bit @ (ex:0 ey:1 p:2)
Inserting 1 (pos x:1 y:0 p:5) bit @ (ex:0 ey:1 p:3)
Inserting 0 (pos x:1 y:0 p:6) bit @ (ex:0 ey:1 p:7)
Inserting 0 (pos x:1 y:0 p:7) bit @ (ex:1 ey:1 p:0)
Inserting 0 (pos x:0 y:1 p:0) bit @ (ex:1 ey:1 p:1)
Inserting 1 (pos x:0 y:1 p:1) bit @ (ex:1 ey:1 p:3)

********** Inverse mode is now on! **********

Inserting 0 (pos x:0 y:1 p:2) bit @ (ex:0 ey:0 p:0)
Inserting 1 (pos x:0 y:1 p:3) bit @ (ex:0 ey:0 p:1)
Inserting 0 (pos x:0 y:1 p:4) bit @ (ex:0 ey:0 p:3)
Inserting 1 (pos x:0 y:1 p:5) bit @ (ex:1 ey:0 p:0)
Inserting 0 (pos x:0 y:1 p:6) bit @ (ex:1 ey:0 p:1)
Inserting 0 (pos x:0 y:1 p:7) bit @ (ex:1 ey:0 p:4)
Inserting 0 (pos x:1 y:1 p:0) bit @ (ex:0 ey:1 p:4)
Inserting 0 (pos x:1 y:1 p:1) bit @ (ex:0 ey:1 p:5)
Inserting 0 (pos x:1 y:1 p:2) bit @ (ex:0 ey:1 p:6)
Inserting 0 (pos x:1 y:1 p:3) bit @ (ex:1 ey:1 p:2)
Inserting 0 (pos x:1 y:1 p:4) bit @ (ex:1 ey:1 p:4)
Inserting 1 (pos x:1 y:1 p:5) bit @ (ex:1 ey:1 p:5)
Inserting 0 (pos x:1 y:1 p:6) bit @ (ex:1 ey:1 p:6)
Inserting 0 (pos x:1 y:1 p:7) bit @ (ex:1 ey:1 p:7)

********** Inverse mode is now on! **********

OUTPUT OF OUTGOING DATA GRID:

82 11 
193 40 

--------------------------------

On the first pass through the encryption, where it uses only the
ON bits as reference to data location, the data is placed like this:

          7  6  5  4  3  2  1  0     < - bit position

byte 0-0  0  1  0  1     0      
byte 0-1  1  1  0     0  0
byte 1-0  0           1  0  1  1
byte 1-1              1     0  0

Notice, this encryption method leaves at least a single blank element
in each byte for the second pass, and uses at least one element from
the first pass.  This makes sure no "strings" that might have an
important piece of information visable to people examining the code
very carefully.

The second pass completes the grid:

          7  6  5  4  3  2  1  0

byte 0-0  0  1  0  1  0  0  1  0    =  82
byte 0-1  1  1  0  0  0  0  0  1    =  193   (hand checked)  
byte 1-0  0  0  0  0  1  0  1  1    =  11
byte 1-1  0  0  1  0  1  0  0  0    =  40

This matches my computer generated report from mcrypt while in
(grealy scaled down) debug mode.

Basically, the data is scattered but the size of the information is
not changed.  Due to the fact these manipulations are the most basic
CPU functions, most of the instructions used to make the grid are
executable at a single instruction cycle.

The reason I have a hard time placing exactly the true permutation
set on this is because there are some distinct rules.  However, they
alter from bit to bit (!).  For example:

1)  The first bit of the first byte MUST be placed within the first
    byte of the encrypted grid.

2)  The second bit can be no more than 15 bits of the first bit.
    (this holds true for all data in the grid)

3)  The second bit has a maximum of 8 possible positions to be if
    the first bit was placed in the 7 field.  Therefore, the second
    bit can have no LESS than 8 possible positions to be placed.

4)  The last bit must be placed in the last byte, the second to last
    bit must be in either the last byte or the second to last byte.

5)  The middle bit of the entire series can go anywhere.

Due to the fact that 2 out of 256 possible values of the key grid 
are invalid (0 & 255), I figured the base number would have to be
254.  There are 1024 bytes in a STANDARD PACKET.  This 2x2 stuff isn't
that secure.  However, 254^1024 doesn't seem logical to me.
I'm not that advanced of a mathematics student.

Thank you very much for your time and trouble, and I'd appreciate all
the commentary that you can give on the subject.  I'm wondering if
this encryption hasn't been tried before, and if you know of where
I can find information on this style of encryption, I'd be most
grateful.


--- Eric Knight

"These opinions are mine, not that of my employer, dog, plants, 
 etc."