"A sleep(1) is put into all SSL_read() and SSL_write() calls..."
1–10 of 52 posts
Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#2Wow I wonder how many people gave up using the ssl lib as too slow due to this bug?
Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#3I love Ben's response in the discussion prior to the SVN check-in.
Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#4I bet removing this causes something somewhere to break.
Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#5I bet removing this causes something somewhere to break.
is sleep(1) noisy?
if so, it might be vs timing attacks
Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#6Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#7It looks like someone forgot to remove the "speed-up loop".
Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#8Earlier quoted context omitted.
is sleep(1) noisy? if so, it might be vs timing attacks
on second thought, my comment makes little sense, if they wanted noisy sleep, it should be something like sleep(func(rand()))
That makes no sense either, an attacker can usually average such things out. Besides, there are better (faster) ways to guard against timing attacks.
Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#9Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."
#10Earlier quoted context omitted.
on second thought, my comment makes little sense, if they wanted noisy sleep, it should be something like sleep(func(rand()))
That makes no sense either, an attacker can usually average such things out. Besides, there are better (faster) ways to guard against timing attacks.
People seem to have a skewed perception of how to defeat timing attacks, generally. At the end of the day, it's more about making things constant time than trying to make the timing difficult to detect. Simple example:
You have two hashes and want to see if they're equal. The naive approach is to iterate over each byte in both hashes and compare them, then break when you find a byte that doesn't match. That approach, however, could be vulnerable to a timing attack because you could potentially measure how many times it iterates. An implementation that's resistant to timing attacks could XOR each byte of each hash and accumulate across them; if that accumulator is zero at the end of the loop, it's equal. That approach is constant time, rather than being dependent on the data you're dealing with.