At 11:26 AM 3/24/00 -0500, Marcel Popescu wrote: >From: David Honig <[EMAIL PROTECTED]> > >> >Er.. do you mean that if I encrypt a 64-bit counter equal to zero, and >then >> >I increment it (and re-encrypt), I should get two very different values? >> >> Think about it. If you *didn't*, then there would be a >> useful distance metric, where an output is related to its >> input in a way you could see without the secret key. > >I know that hashes have this property - one flipped bit in the input changes >a lot in the output - but I thought ciphers don't have this requirement. A hash needn't have this property. A hash is just a mapping with a smaller output space than input. A cryptographically-strong hash does have this property. >I'm using someone else's implementation. Trust no one is the rule. Be glad you discovered the flaw through your observations. Skepticism + observation is a good thing. >Looks like I'll have to roll out my >own... Download the cipher code from some library. Most of the work in applied crypto is using these components properly, e.g., secure protocols, key management, UI. >Ok. I guess it's time to download the counterpane specifications again :) Presumably you mean download the code for whatever component (yarrow, *fish, etc.) you need. Learning how to use some implementation of a cipher is like learning any API. Learning how to build a secure *system* is harder. You only need to dig inside a cipher to study it, optimize it, or to port it to some funky language (e.g., verilog, perl, etc). And then, you have to really get into it. IMHO. dh
