Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: Web Cryptomatic

by no_slogan (Deacon)
on Sep 22, 2001 at 01:13 UTC ( [id://113998]=note: print w/replies, xml ) Need Help??


in reply to Web Cryptomatic

This is just simple xor encryption using a 16-byte key generated with MD5. Completely insecure. The entire point of a one-time pad is that you NEVER REUSE A KEY BYTE. Your scheme reuses the same key byte once for each 16 bytes of plaintext.

I just had a look at Crypt::OTP. Gack. Let's just say that the author was cryptographically unsophisticated.

Replies are listed 'Best First'.
Re: Re: Web Cryptomatic
by sifukurt (Hermit) on Apr 07, 2002 at 06:04 UTC
    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
      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.

        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
Re: Re: Web Cryptomatic
by oakbox (Chaplain) on Sep 22, 2001 at 18:32 UTC
    I appreciate the feedback. My original problem was "How to send short strings of text (less that 256 characters) in a hidden form field between two different web sites?" I needed to make the string encrypted enough to not be worth breaking (I'm not passing CC numbers or anything like that).

    After looking at some different schemes, my problem became 'How do I whip up a good pad?' and this was my answer. My question is, HOW secure is the above scheme? Are we talking about a couple of hours or a couple of minutes to crack? What if the pad was 32 bytes long? 64?

    I whipped up the above code so that I could get some good crypto advice and maybe make something useful. I guess my 'big' question is, can someone break into a short section of text (~256 bytes), encrypted by this engine, without the password?


    -oakbox

      It doesn't matter how long your "pad" is, if you cycle through it in a predictable fashion. If the message is longer than the key, you will reuse key bytes. If you reuse key bytes, you're a sitting duck. 256 bytes of encrypted English text would be easy to break in a matter of minutes. Half that or less would probably be enough.

      When you're doing crypto, don't try to get clever. Use a real cipher module like Crypt::Rijndael or Crypt::IDEA or whatever. There was an article on crypto modules on perl.com recently.

      If for some reason you can't use one of those, there are secure ways to use hash functions like MD5 for encryption. You have to be very careful, though, because that's not what they were designed to do. For details, see <cite>Applied Cryptography</cite>.

        >When you're doing crypto, don't try to get clever. Use a real cipher module . . .

        You know, this was a little hard to swallow, because I consider myself to be such a clever fellow. I played around with a bunch of different schemes to derive larger pads from a password and ended up feeling like my brains were turning to mush. After spending too much time on what, in the beginning, was a simple problem, I realize I don't know jack about cryptography and should leave it in the hands of people who know what they are doing :)

        Again, thanks for the advice and pointing out the correct direction to a fellow monk.
        -oakbox

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://113998]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2024-03-28 14:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found