handling weak keys using random selection and CSPRNGs

[Leichter, Jerry]

| Given how rare weak keys are in modern ciphers, I assert that code to cope
| with them occurring by chance will never be adequately tested, and will be
| more likely to have security bugs.  In short, why bother?
Beyond that:  Are weak keys even detectable using a ciphertext-only
attack (beyond simply trying them - but that can be done with *any* small
set of keys)?  If not, what's the attack?  One could posit an attack
in which some of the plaintext is known, and an attacker could detect
the weak key from known ciphertext/plaintext pairs and then use the
detected key to attack the rest of the ciphertext.  But that's an odd
attack to defend against - why not just try all the weak keys (or,
again, any small subset of keys) and see if they work?

The only kind of weak key that would matter is one that leaves the
ciphertext mainly or entirely unchanged - e.g., leaves most of the
bits unchanged or most of them always flipped.  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.

							-- Jerry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com