> 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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users