Article View: sci.crypt
Article #717Growth of mcrypt due to packets
From: Knight of Tossing and Turning
Date: Sat, 15 Aug 1992 16:29
Date: Sat, 15 Aug 1992 16:29
50 lines
2824 bytes
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!knightShow 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