"Natural Rights" in the sense that Americans understand them were discussed at length by John Locke back in the late 1600's.
If you get a chance to check out his Second Treatise, you will see these writings that heavily influenced America's founding fathers. In fact, if you read the Declaration of Independence closely, you will find that some of it was cribbed word for word from Locke!
The problem with adding random delays is that it doesn't really help much (as long as you actively spin).
Let's say that x is the amount of time it would have normally taken for an operation, and R is a random delay. Through various means (for instance, by reading the source:), we determine that R gets mod'd by a constant (k) in order to bound it (don't want those processes spinning for 15 minutes!)
So total time (T) = x + R % k
Assuming a good random number generator, over many iterations (R%k) will average out to ~(k/2)
You can now calculate x using:
x = ave(T) - k/2
A few extra steps, but we got back what we were looking for.
If you used actual sleeps (ie - usleep(2)) instead of active sleeps, the scheduler and background contention would likely normalize the numbers to the clock ticks and diminish the effectiveness of these attacks.
The recent SSL timing attacks I've seen have had their fixes be of the sort "Make the failure scenario take the same amount of time as the success scenario", which essentially causes certain paths to waste compute cycles purposely and unnecessarily.
By gathering the max possible invocation time, opeenssl could just grab the time at invocation, then call usleep up till its max.
This offers distinct overall advantages over the lengtening in that it causes the implementation to use processing resources much more efficiently (the scheduler will run other jobs while openssl sleeps), and also gives coders the freedom to implement the application in an optimal manner and still reap the benefits.
Besides, users can't really tell the difference between 30ms and 70ms anyhow:)
Slashdot Mirror
"Natural Rights" in the sense that Americans understand them were discussed at length by John Locke back in the late 1600's.
If you get a chance to check out his Second Treatise , you will see these writings that heavily influenced America's founding fathers. In fact, if you read the Declaration of Independence closely, you will find that some of it was cribbed word for word from Locke!
On second thought, this works best when defending against network attacks.
If on the same system, then a user could examine the total amount of compute time the process had taken with ps(1), then go from there.
The granularity may or may not be good enough.
The problem with adding random delays is that it doesn't really help much (as long as you actively spin).
:), we determine that R gets mod'd by a constant (k) in order to bound it (don't want those processes spinning for 15 minutes!)
Let's say that x is the amount of time it would have normally taken for an operation, and R is a random delay. Through various means (for instance, by reading the source
So total time (T) = x + R % k
Assuming a good random number generator, over many iterations (R%k) will average out to ~(k/2)
You can now calculate x using:
x = ave(T) - k/2
A few extra steps, but we got back what we were looking for.
If you used actual sleeps (ie - usleep(2)) instead of active sleeps, the scheduler and background contention would likely normalize the numbers to the clock ticks and diminish the effectiveness of these attacks.
The recent SSL timing attacks I've seen have had their fixes be of the sort "Make the failure scenario take the same amount of time as the success scenario", which essentially causes certain paths to waste compute cycles purposely and unnecessarily. By gathering the max possible invocation time, opeenssl could just grab the time at invocation, then call usleep up till its max. This offers distinct overall advantages over the lengtening in that it causes the implementation to use processing resources much more efficiently (the scheduler will run other jobs while openssl sleeps), and also gives coders the freedom to implement the application in an optimal manner and still reap the benefits. Besides, users can't really tell the difference between 30ms and 70ms anyhow :)