🚀 go-pugleaf

 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