|
in reply to Re: Web Cryptomatic
in thread Web Cryptomatic
I just had a look at Crypt::OTP. Gack. Let's just say that the author was cryptographically unsophisticated.
Ouch. That's a little uncalled for, I think. As I said in the POD for Crypt::OTP, the safest method (that is, the method that should be used) is to use a large pad file. I take for granted that you're referring to the second, substantially less secure method that I worked into Crypt::OTP. Again, as I said in the POD, it is substantially less secure. That method, quite obviously, isn't intended to be used for anything that requires any serious degree of security. I included it in the module because 1.) it was already there because I used it for testing purposes; 2.) some people are going to use the module that way anyway; and 3.) it is handy for things that really only require the most modest level of security. Your point on the proper use of one-time pad encryption is absolutely correct. You aren't supposed to reuse anything. Period. End of discussion. But as with any tool, it is only as good as the way that you use it. If you use it in an insecure fashion, it will be insecure. The shortcoming is not a result of being "cryptographically unsophisticated." I'm not about to sit here and claim to be an international authority on the subject of cryptography. However, I have more than my fair share of experience in the field. I've read the books, attended the seminars, taken the classes, had memberships at one time or another in probably six or eight security related organizations, etc., etc., etc. At no time have I ever claimed that my implementation of OTP is the cryptographic magic bullet, so to speak. If you use it correctly, it will serve you in good stead. If you use it incorrectly, well, you're doing it at your own risk. Taking all of that into account, that you would make assumptions about my level of cryptographic sophistication without knowing me or anything about me, I find rather disturbing.
___________________
Kurt
|
Re: Re: Re: Web Cryptomatic
by no_slogan (Deacon) on Apr 07, 2002 at 07:40 UTC
|
Maybe I was a bit too harsh. Sorry about that. But I'm going to stick to my guns and maintain that Crypt::OTP is deeply flawed. It solves the easy problem (xoring the pad into the message), but provides no help at all on the difficult problem (key management). If a one-time pad is going to be secure, it is absolutely critical that no part of the pad ever be reused to encrypt a second message. Recovering plaintexts encrypted with the same key is easy for a cryptanalyst (try it sometime, it's kind of fun). It would be useful if Crypt::OTP would help remember which parts of the pad have already been used, but it doesn't. Even if I remember which parts I've used, there's no way to tell Crypt::OTP to seek to the unused parts. I have to extract the unused portion into a temp file, then pass that to Crypt::OTP, and wipe it afterwards. I also need to make sure there are enough bytes left in the pad to encrypt the message, or Crypt::OTP will happily recycle key bytes. It's a lot of work to use this module securely.
To make matters worse, none of this is explained in the module documentation. And there's some rather bad advice in there to boot. You suggest that the pad file be a "semi-random text file." Wrong -- in order to be secure, a one-time pad must be completely random. Any patterns in the pad provide a handhold for the cryptanalyst. Also, a lot of people are going to interpret "text file" to mean "a file of English text." You reinforce that idea by showing an English phrase as the key in your less secure example. However, recovering an English text message encrypted with an English text running key is an easy problem for someone who knows what they're doing. So maybe you really do know your stuff, but you sure didn't show it in Crypt::OTP. | [reply] |
|
|
Valid points, all. I believe, to some degree, this boils down to a semantic disagreement. I left the matter of key management up to the user. After re-reading the documentation, you're right...I wasn't sufficiently clear for users who have little or no experience. My thoughts were (and still are, to a point) that this is a tool, and how a person chooses to use the tool is up to them. I guess the closest thing I can compare it to is purchasing, say, a band saw. The assumption is that you already know a bit about woodworking or you wouldn't be buying a band saw in the first place. And while the manual for the band saw shows you how it works and encourages you to wear eye protection, etc., it doesn't actually teach you how to do woodworking. In Crypt::OTP, I encouraged people to use it safely, but I didn't think it was my place (and I didn't want to insult the folks who do know what they're doing) to presume to teach cryptography.
With regard to the matter of the "semi-random text file," again, it is a semantic issue. First, unless someone intends to get genuinely random numbers from somewhere like Random.org or HotBits, random data generated any other method will be nothing but semi-random, given that built-in random features use the likes of lagged Fibonacci generators or some other random number algorithm, which unless I'm mistaken (quite possible), will always yield numbers in a pattern eventually. Hence my use of "semi-random". Obviously, genuinely random data would be preferred, but provided that the method for generating random numbers has a respectably long period before the pattern emerges (i.e., the period is greater than or equal to the length of the message), semi-random data will suffice. With regard to interpreting "text file" to mean "a file of English text," we're back to 1.) the fact that I made assumptions about the cryptographic background of the people using the module; and 2.) to further the band saw metaphor, my goal was to show how the band saw works, not to teach woodworking. My use of an English phrase in the example was to illustrate the usage, not to tell people how to employ good crypto practices, which as I said, isn't really my place. So would I use the second, less secure method to encrypt anything of any importance? Not a chance. Would I use the primary method to encrypt fairly short messages using a semi-random pad? Provided I was confident that the period of the semi-random (or pseudo random, which is, I believe, the more correct term) numbers was at least the length of the message, absolutely. So I would strongly argue that Crypt::OTP isn't flawed, though it can very easily be used incorrectly.
Btw, don't get me wrong. I do appreciate the feedback, positive or no. It is always good to rethink one's position from time to time. I just wanted to explain my thinking to (hopefully) clear up the issue a bit.
___________________
Kurt
| [reply] |
|
|
The problem with your band saw is that it doesn't include any safety restraints, and the manual doesn't tell you to wear eye protection. In fact, it shows the little stick man just about to feed his hand right into the saw blade.
Any random number generator with a finite internal state must eventually fall into a cycle. Anyone who uses a lagged Fibonacci or other insecure PRNG to generate one-time pads deserves to lose. If you really knew anything about crypto, you would know that a long period is not sufficient for security. Anyone who downloads one-time pads from the web deserves to have their traffic sniffed by Carnivore. About the best us mortals can hope for is Math::TrulyRandom or
open RAND, "</dev/random";
read RAND, $key, length($message);
I'm done with this thread. You get the last word. | [reply]
[d/l] |
|
|
