Weak encryption keys

[jsmith9810 at gmx.com]

> The problem is that a private key protected by a weak cipher is still
> potentially compromised if an attacker can get any copy of the key prior
> to migrating it to a stronger cipher.  In other words, if an attacker is
> able to obtain your current key blob, the attacker can still compromise
> your key by cracking that copy, even after you have migrated your copy
> to a stronger wrapping.
>
> If an attacker was interested in you, your key is lost and the best path
> forwards is to revoke it and generate a new key.  You could sign the new
> key with the old one before revoking the old key.
>
>
> -- Jacob
>

A private key protected by weak blowfish cipher is by no means more at risk
compared to an unencrypted key, which GnuPG has no problem with.

Also, from what I've read about blowfish weak keys (and I admit I didn't spend
too much time on it), the attacks are unrealistic in that even though they
reduce the complexity compared to brute forcing a 128-bit key, it's still
near-impossible to retrieve the plain-text or the key itself within reasonable
amount of time. And I also recall reading that it requires a large amounts of
known plain-text and corresponding cipher-text data. In this case, it's a
unique key that's only used to encrypt a few hundred bytes of data. So the risk
of an attacker being able to just "crack" your private key based on the weakness
of the cipher key seems to be quite an overstatement.

Besides, shouldn't the assessment of the security of the key be better left to
the user? It would be totally reasonable to warn the user about the potential
risks and even make a recommendation to revoke this key. But not allowing them
to decrypt something that was previously encrypted with this key doesn't seem
justifiable even if the risks were as high as you stated.