Hi, Regarding the recently reported Debian patch of OpenSSL issue, the affected keys would seem to be well known and with the metasploit site hosting pre-computed keys and a number of scripts around various sites available to take advantage of the specific problem, it would seem like just a matter of time before these keys become the first port of call for a malicious user looking to compromise any arbitrary key (in the hope that it's from an affected system).
Should these compromisable keys now be considered in the same light as a password of "password" on otherwise unaffected systems? In other words - if these keys could now form the base of a dictionary (of sorts) for an attack, should we consider also checking generated private keys (by OpenSSL in this instance) much as some systems check for silly passwords? If so: Would the key space be narrowed materially if these keys were removed from the "allowable" private keys in 2048 RSA for example? Could a 128bit MAC of the keys be used (or the like) instead of actually looking up against the full keys? From a runtime perspective, distributing the full pre-computed keys and checking could be prohibitive for some solutions, vs. say a binary tree of 128bit hashes. How significantly would a 128 bit MAC of the key reduce the allowable key space? Is there any intention that OpenSSL do such a "bad key" check (much as the OpenSSL-blacklist for Ubuntu presumably does), or would it be something that users concerned enough would look to do themselves? With all the posts around why the Debian issue may have occurred, I'd hate to be trail blazing... Finally - how real is this concern? What is the probability that say a 2048bit generated key could fall into the 32,767 keys in the metasploit SSH example on unaffected systems? Best Regards, Deane ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
