I should just shut up but this is bugging me and I haven't done the math yet. Hopefully this will be a good question. On Wed, Nov 29, 2000 at 06:22:01AM -0800, John Kennedy wrote: > As far as a real (but not mathematical) brute-force attempt goes, > it may do some good. If all they have is the data encrypted by the 2nd > key, it (the 2nd key) has more entropy in the cipher key (and presumably > passes on the benefits of that in a mathematically tangible way). > They have to have possession of the 2nd key encrypted with the 1st key > to exploit the lack of entropy in the 1st key. The 2nd key (encrypted) > is more mobile than the data encrypted by the 2nd key, which means that > it is physically much more difficult to get (something that can't be > factored into the mathematical attacks, but may be irrelevant from their > point of view anyway). Right now, we're operating under the assumption that the serpent cipher is secure and that I could encrypt gigabytes of zeros securely and it wouldn't do any good to a brute-force attacker, at least directly. The easiest way in is still through attacking the key. The key is just a bitstream, X bits long. I could try all 2^X possible values to try and brute-force it, knowing I got it right when I see the gigabyte of zeros. That should be made computationally infeasible for a reasonable period of time, so the trick is to really cut back and find the smallest possible subset of 2^X to try. [tradeoff between security and the time it takes to decrypt the data. typically you want it to decrypt as fast as possible and still keep it as painful as possible for the brute-forcers, trusting that the cpu-expensive key generation will stop people from generating and trying to use a lot of keys very quickly.] The hash that makes the key is there to make that difficult. It takes a small amount of human-friendly bits and converts it into a much longer bitstream with a wide output-value range. It won't be any more random, but it hopefully guarantees you that brute-forcers can't eliminate any of the 2^X possibilities for the cipher key. The brute-forcers then have to attack the key itself. It is a one-way hash and should be computationally expensive to generate, which cuts down on the number of attempts you can make in a time interval. Once again, you're trying to figure out ways to cut down on the possible input. [this can be very painful to generate, since it is a one-time cost if you know the correct password and it is good to make it as painful as you can if you don't.] Here is where the entropy comes into play and where I start to tie knots with my brain, tongue and fingers. You want N bits of entropy (good, random numbers). If those N bits are from a keyboard, you only get ~1.3 bits per key (byte). If they're a nice secure number from /dev/random (presuming it has good entropy) you should be able to get all 8 bits/byte. The only trick is that you have to remember those bits or you won't be able to decrypt your data. Is the cipher-encrypted data any more secure with less entropy than with more entropy? I think the bit that I have to bend my brain around is that the answer is *NO*. Less entropy just means that the attacker has to try fewer hashes, and in the end fewer cipher keys. As an example, if I got *really* unlucky and my high-entropy bitstream happened to be all zeros, the data isn't encrypted any more securely than if I had a really bad hash generator that only let me pick a single digit between 0 and 9 as the bitstream. It makes a great deal of difference to an attacker that is thinking about trying to brute-force me. 2^X vs. 10. It seems like it really doesn't matter what I use as the hash input, so long as it has sufficient entropy to provide a good range of output. In my original email, above, I'm protecting a key (key2, with a good range of input) with encryption, that is decoded by another key (key1, with a smaller range of input). If I knew I had decrypted key2 correctly with key1 then I would have a weakest-link situation. If I don't know, then an incorrect key2 complicates the hell out of finding the correct cipher key. It may not magnify it, but I doubt if it helps to eliminates anything. It may not contribute a whole lot to the security, but if key2 is disposed of the pulling-fingernails approach won't work for decryption. (: Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
