> maybe this is not leaked or it requires a read at the correct time because these buffers might be trashed by another computation.
As far as I can tell, it's certainly possible for intermediate data to be leaked, but it'd require pretty spectacular timing.
That said, I'm having a bit of a hard time understanding why this challenge exists. If the possibility (even remote) exists that key material was leaked in any form, it should be assumed that the key material was leaked in the worst possible way, and that everything is compromised. They seem to agree, having rolled their keys.
The only real effect I can see from this challenge existing is that people will see it and make the assumption that Heartbleed is "not a big deal, because Cloudflare's keys weren't leaked".
In other words, I think this challenge is harmful to security overall; Cloudflare seems to be doing the right thing, but the messaging here is going to cause people to not follow suit.
i've locally tested the BN_div function and the sdiv buffer is intact at the end of the function with a p or q value. however, the BN values seem to be allocated in some kind of pool and they are reused so the private keys get clobbered by another BN function soon after. also, at the end of the RSA_eay_private_encrypt function the BN values are zeroed (or written over with crap data) so unless there is another implementation bug it should be impossible to leak the intermediate values in a single threaded implementation.
leaking the intermediate values in nginx to recover the private key looks like a dead end. however, i think this could be quite promising for apache mpm_worker. :)
So it looks like you might be right. Debian uses Apache mpm_worker by default, and after getting a test install running and using ab to provide load I managed to get the private key in under a minute on the first run: http://t.co/nYvIw7q4M8 (I was lucky the first time, usually it seems to take a little longer.)
for nginx it might not be possible for the intermediate data to be leaked. nginx is single threaded so as long as the intermediate buffers are safely freed or clobbered by the end up the ssl signing method then it won't be possible to leak the key that way. i suspect multithreaded apache would pose a real risk.
As far as I can tell, it's certainly possible for intermediate data to be leaked, but it'd require pretty spectacular timing.
That said, I'm having a bit of a hard time understanding why this challenge exists. If the possibility (even remote) exists that key material was leaked in any form, it should be assumed that the key material was leaked in the worst possible way, and that everything is compromised. They seem to agree, having rolled their keys.
The only real effect I can see from this challenge existing is that people will see it and make the assumption that Heartbleed is "not a big deal, because Cloudflare's keys weren't leaked".
In other words, I think this challenge is harmful to security overall; Cloudflare seems to be doing the right thing, but the messaging here is going to cause people to not follow suit.