Thread View: sci.crypt
2 messages
2 total messages
Started by Knight of Tossing and Turning
Tue, 11 Aug 1992 00:11
Mass Encryption System -- Help Requested
Author: Knight of Tossing and Turning
Date: Tue, 11 Aug 1992 00:11
Date: Tue, 11 Aug 1992 00:11
254 lines
11560 bytes
11560 bytes
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."
Re: Mass Encryption System -- Help Requested
Author: Terry Ritter
Date: Wed, 12 Aug 1992 05:55
Date: Wed, 12 Aug 1992 05:55
92 lines
4535 bytes
4535 bytes
In <1992Aug11.001118.28760@mintaka.lcs.mit.edu>
knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning)
proposes an encryption scheme he calls "Mass Encryption," and
solicits comments:
> 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 . . .
Basically, the scheme is bit-transposition, with a prior Simple
Substitution step. I was unable to decipher the algorithm used
to transform the User Key into the substitution and transposition
permutations, and this algorithm, is, of course, crucial to
understanding the strength of the system.
>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.
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).
> 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).
Bit-transposition is known. I published a paper on "Dynamic
Transposition" bit-transposition in the January 1991 Cryptologia,
and released a full source, "reduction to practice" implementation
to sci.crypt about a year before that.
>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.
> . . . 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.
Well, yes, Simple Substitution makes it somewhat more difficult
to tell whether an enciphered file is the same as a given plaintext
file by bit-counting. But unless all the files are of the same
length, we can probably identify a plaintext/ciphertext pair by
*size* (the ciphered version will probably have a fairly-constant
or otherwise identifiable overhead).
Also,
* Without specific algorithms to examine, key-space limitations
cannot be understood, and this is really the heart of any
cipher.
* It is unclear whether multiple blocks of the same message
will be enciphered with the same transposition, but the use
of the term "key grid" might lead one to think so. If so,
this is a very serious weakness because it allows anagramming
even within a single message (file).
* 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.)
---
Terry Ritter ritter@cactus.org
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads