| > 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
                                                        -- 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]

Reply via email to