🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: sci.crypt
Article #717

Growth of mcrypt due to packets

#717
From: Knight of Tossing and Turning
Date: Sat, 15 Aug 1992 16:29
50 lines
2824 bytes
Okay, there has been some debate about "how" my encryption causes the
file to grow.  I'm sorry this took so long for me to post, I've been
spending more of my time writing this program and showing relatives
around my home town of Pueblo (send for your free government catalog)
since they are up from Texas.

To show how this works, lets take a file 1025 bytes long.

Since the encryption deals with 1024 byte chunks, the first "block"
of 1024 bytes is encrypted so that it only needs 1024 bytes to store
all the information..  Basically, same size or one-to-one.

The next block consists of only a single character.  Of course, this
is really bad since this character (or small string of characters
if it is more) could (and probably will) give away methods to solve 
the entire system if mcrypt kept this data the same size prior to
encryption as it would be after the encryption.

To solve for this problem, I opted to just fill the rest of the
data (unused) with garbage, and use the file length to tell the
decryption routine to stop.  Nothing fancy there -- it can be 
drawn straight out of a random number generator.  All the garbage
will be intermixed with plaintext and thereby keeps it protected.

The filelength itself will be placed in a final packet at the end
of the grid (haven't gotten around to placing this yet, I've only
used an integer for testing.)  I figured this number would be
best to encrypt as well because knowing the true file length could
also be considered a 'weakness' of the system.

I'm not worried about the 1-2K of extra data, at least the value 
of growth is a reasonable X+2, and not X1.5 or X^2 or something
that will explode in the long run.  It isn't even a matter of
principle. 

On the "help from others" note:

I've been running benchmarks on mcrypt today, and it runs at 
about 10K/sec on my 386-33 running Linux.  I'll compile it
for single user mode soon.  If anyone has some benches for DES
I'd be interested in knowing how fast it is on your CPU.

Finally, I've grabbed several books on cryptanalysis and hopefully
I'll be able to discuss my idea a little closer to "normal".
Thank you people who have suggested books to read.

Source code will soon be available for people to kick around.

--- Eric Knight
Technical Details
Message-ID: <1992Aug15.162947.688@mintaka.lcs.mit.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!knight

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!knight
From: knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning)
Newsgroups: sci.crypt
Subject: Growth of mcrypt due to packets
Summary: Some more clarifications
Keywords: mcrypt
Message-ID: <1992Aug15.162947.688@mintaka.lcs.mit.edu>
Date: 15 Aug 92 16:29:47 GMT
Article-I.D.: mintaka.1992Aug15.162947.688
Sender: news@mintaka.lcs.mit.edu
Organization: MIT Laboratory for Computer Science
Lines: 50