arc4random vs timing attacks
Here at 31C3, Sebastian Schinzel just gave a presentation based on Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks. The particular attack that caught my eye was the failure to generate a fake PMS before checking for bad padding, not after. Doing it afterwards exposes a timing difference of up to a few microseconds which can be measured over the network.
Of course, this depends on the OpenSSL RAND_pseudo_bytes function taking a measureable amount of time. In LibreSSL, we replaced the random number generator with arc4random which should be much faster. Time to measure. Thanks to benno for setting me up with a 5.5 test machine. (5.5 is the perfect release to test: new chacha20 arc4random, but still vanilla OpenSSL.)
#include <openssl/rand.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <machine/pctr.h>
int
main(int argc, char **argv)
{
uint64_t before, after;
int i;
char buf[48];
for (i = 0; i < 100; i++)
RAND_pseudo_bytes(buf, sizeof(buf));
before = rdtsc();
for (i = 0; i < 10000; i++)
RAND_pseudo_bytes(buf, sizeof(buf));
after = rdtsc();
printf("RAND_bytes duration: %f\n", (after - before) / 10000.0);
for (i = 0; i < 100; i++)
arc4random_buf(buf, sizeof(buf));
before = rdtsc();
for (i = 0; i < 10000; i++)
arc4random_buf(buf, sizeof(buf));
after = rdtsc();
printf("arc4random duration: %f\n", (after - before) / 10000.0);
return 0;
}Results:
RAND_bytes duration: 24759.2385000
arc4random duration: 2376.207000010x faster. Not bad. That microsecond timing attack is now a nanosecond timing attack (albeit for larger values of nanosecond.)