Matt Palmer <[email protected]> writes: >I have concerns around doing so, as the data set is very large, and >constantly updating.
Ah, I didn't realise it was that big, I thought it'd be a small collection that could be turned into a bloom filter. If there's that many of them the data would be interesting, any chance of publishing stats, how many compromised keys, how many are X.509, how many are SSH, etc? >While I'm sure there are *some* things that can't make arbitrary requests, >I'm less confident about the "lots" part. I'm referring to embedded systems, which have no internet access but end up seeing keys from who-knows-where. When you see a connection with a cert issued to Some State in Some Country [0] you've got a pretty good idea that the private key is unlikely to be very private, but apart from that there's no other indication that there's a problem. That would be another reason to see what's present, although that could also be handled in the stats without having to publish actual keys/certs, what are the top identifiers used with non-private keys? That could be applied like a top-ten bad passwords filter, if you can get people to stay away from the most commonly-used insecure keys it's at least some progress. Peter. [0] For those who don't recognise this, it's the default OpenSSL cert data. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ME0P300MB071309B7D1E72DA1D0A25696EE432%40ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM.
