As always, the devil is in the details. Keyboard smashing can be made quite unpredictable if implemented correctly. The randomness should come from time differ

As always, the devil is in the details. Keyboard smashing can be made quite unpredictable if implemented correctly. The randomness should come from time difference between keystrokes, not from the key values. I have used the Unix signal(3), using SIGINFO, in conjunction with a tight CPU loop to generate random numbers for e.g. WiFi passwords. The technique is something like this: volatile int signal_info = 0; void sighdlr(int sig) { signal_info = 1; } int main(...) {... unsigned count = 0; signal(SIGINFO, sighdlr); ... for(;;) { count++; if (signal_info) { signal_info = 0; ... } } Before running this program I use stty -kerninfo to avoid seeing CPU statistics. Then every time I press ^T I display a new random number displayed based on the LSBs of the count. E.g. to simulate a die roll I print count%6. This technique is good for not just a few bits of randomness per ^T, it is good for over 20 bits. That's because when I examine the timing of the inner loop generated I find it taking about 2 or 3 CPU cycles per increment (depending on compiler). So on a 2 GHz machine the counter is incremented at a 1 GHz rate. That's about 30 binary bits, the least significant of which are the most unpredictable. Assuming you press ^T at about a 3 Hz rate, you're probably getting over 20 bits (more or less) of randomness each time you do so. The above only works if your system supports a decent SIGINFO setup (works fine on OpenBSD and OS X, I don't know about Linux). It probably has serious problems in a virtual machine, I use a real keyboard that has its own independently clocked CPU.