Linked by Thom Holwerda on Mon 11th Jul 2011 21:29 UTC, submitted by sawboss
Permalink for comment 480482
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
More News »
Sponsored Links



Member since:
2011-01-28
lemur2,
"There was reduced security for SSL on Debian while this bug was in the code, not zero security."
From what I've read, there were only 15 bits of seed material per key.
"Q: How long does it take a crack a SSH user account using these keys?
A: This depends on the speed of the network and the configuration of the SSH server. It should be possible to try all 32,767 keys of both DSA-1024 and RSA-2048 within a couple hours, but be careful of anti-brute-force scripts on the target server."
http://digitaloffense.net/tools/debian-openssl/
"The only thing guaranteed by having the source code visible is that there will be no intentional malware. (By its very nature malware cannot be unintentional)."
But why not? If a developer was able to introduce a bug which seriously broke security, what prevents someone from doing the same thing deliberately?
A regular contributer (as opposed to a one time patcher) is in a great position to add obscure vulnerabilities. I would hope that regular project contributers are unlikely to have malicious intent, but that's simply an assumption on my part.