However the article and comments finish up by explaining that these weak keys are only on embedded systems (routers, switches, etc...) which lack battery backed clocks and create certificates soon after booting resulting in the certificates being generated from an extremely weak pool of entropy and the primes ending up similar (in terms of what a PRNG would generate).
Also this is not specifically a SSL/TLS/HTTPS issue. It's a generic one for asymetric/publickey cryptography and affects SSH as well as TLS. In short... Double check any embedded systems you're using is not generating its keys weakly and get back to trying to replace HTTPS' dependence on an untrustworthy Certificate Authority system ;) ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] On 2013-10-28 7:16 PM, Tyler Romeo wrote: > Antoine pointed out I should probably have a quick summary of the article: > > Organization performed a mass analysis of public TLS keys across every IPv4 > address using Amazon EC2 to grab everybody's certificate. They found that > around 0.5% of all keys shared a prime number, causing both keys to be made > vulnerable. The process can be performed by anybody and only takes a day or > two of processing along with an hour of computation (about $5 on EC2). > > *-- * > *Tyler Romeo* > Stevens Institute of Technology, Class of 2016 > Major in Computer Science > > > On Mon, Oct 28, 2013 at 5:04 AM, Tyler Romeo <[email protected]> wrote: > >> About time another issue with TLS popped up. Thought I'd share it here: >> >> http://bit-player.org/2013/the-keys-to-the-keydom >> >> *-- * >> *Tyler Romeo* >> Stevens Institute of Technology, Class of 2016 >> Major in Computer Science >> > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
