At 11:23 AM 3/24/00 +0200, Marcel Popescu wrote: >From: David Honig <[EMAIL PROTECTED]> >> Each bit in the output has a 50-50 chance of flipping. If >> you flip an input bit. Look up avalanche. > >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. >This is nowhere like my experience... Did you take the red pill or the blue? You're playing with a poor cipher if its not true. If you're implementing a good cipher, you're not doing it right, you've implemented a different algorithm. See my last comment. >I think I need some test vectors for the implementations I have. Does >anybody have a few? You rely on the original author for reference code and test vectors. You verify optimizations, ports, etc. of your own against this. If you run into trouble, "instrument" the reference code so you can see what its doing internally, and do the same for your port, and see where the difference starts. Soon after the bug, your results will diverge wildly, which is again related to the properties of ciphers. Sometimes it helps to use all-zero *subkeys* to develop the round structure in your port. You can tinker with the reference code to observe its behavior with similar keys. You have got to have a 'golden standard' to verify against. Then you can set both versions' subkeys to known values and verify. Then you can verify that the right subkeys are produced by your key-scheduling code. If that all works your implementation should work. The final test is interoperation with the known good code.
