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] |
