| > This suggests that,
| > rather than looking for weak keys as such, it might be worth it to
| > do "continuous online testing": Compute the entropy of the generated
| > ciphertext, and its correlation with the plaintext, and sound an
| > alarm if what you're getting looks "wrong". This might be a
| > worthwhile thing to have, not just for detecting weak keys, but
| > to detect all kinds of software and hardware failures. Since it's
| > outside of the actual encryption datapath, a bug either fails to
| > sound an alarm when it should - leaving you where you were without
| > this new check - or sounds a false alarm, which unless it occurs
| > too often, shouldn't be such a big deal.
| >
| This is a very interesting suggestion, but I suspect people need to be
| cautious about false positives. MP3 and JPG files will, I think, have
| similar entropy statistics to encrypted files; so will many compressed
| files.
I'm not sure which direction you want "false positive" to refer to. If
the input is already random-looking, then any encryption of it, good or
bad (other than very silly ones which grossly expand the input) will
also be random-looking. So you'll never trip the "output doesn't look
random enough" detector. On the other hand, some simple correlation
analysis between input and output *might* detect some simple failures.
(You could also look for the non-random pieces, like the headers on
JPG's. Not sure it's really worth it - about the only time you're
going to find that is when the output and the input are essentially
identical.)
-- Jerry
| For a more substantive, less hand-wavey analysis, see
| http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf
| which has actual file system entropy measurements.
|
|
| --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
|
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
