(Not a sec guy disclaimer) && (sorry I think I don’t see the full history of the thread for some reason) Hashes are indeed a compromise - don’t provide sensitive information; only provide a good enough hint that you possess that information. Storing a hash instead of the key protects the key, but if it is a pub key there’s not so much point in protecting it… still, stealing the hash is mostly useless unless the hash can also be used on other devices. In that case it is effectively the same as having the”password”. Thinking quickly it might be slightly preferable to store a hash than the pub key if you don’t need to encrypt data back to the priv key owner… (/disclaimers and sorries) *Pedro Martins Prado* pedro.prado@gmail.com / +353 83 036 1875 (FaceTime & WhatsApp) On Sun 31 Aug 2025 at 20:54, Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
On Aug 31, 2025, at 11:16, nanog--- via NANOG <nanog@lists.nanog.org> wrote:
There is currently no known way to generate a private key that would match your private key hash, faster than brute force, and MD5 still provides adequate protection against brute-force attacks.
While nobody should be designing new protocols using MD5 just because there is no reason to use a hash algorithm that has *any* known weaknesses, its known weaknesses are not relevant to this application.
A method is known to generate two pieces of data with the same MD5 hash. This isn't the same thing as saying that a method is known to generate a piece of data with any given MD5 hash, or the same MD5 hash as another piece of data.
And that’s why this isn’t a CVE with a CVSS score. It’s just an indication of someone cutting corners in a way I’ve never seen before, that makes me wonder what other choices were made. I say that much.
-Dan _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G2NJ5JEF...