4 ms·

To generate a secure 2048 bit RSA key (or ElGamal or whatever) you do not need 2048 bit truly random data. RSA keys are generated like this: 1) Choose 1024 ran

To generate a secure 2048 bit RSA key (or ElGamal or whatever) you do not need 2048 bit truly random data. RSA keys are generated like this: 1) Choose 1024 random bits. 2) Set the first and last bit to "1". 3) Check if the generated number is prime (this is probabilistic and also needs random numbers!). 4) Repeat until you have two primes, generate public key by multiplying the two primes and generate private key using the factorization. So if you really want to use true randomness for every random bit in the key generation then you need a lot more than 2048 random bits. What you actually want to do is generate 256 bit of randomness and use that to seed a good cryptographically secure pseudo random number generator (AES Counter Mode, Salsa, Fortuna) to generate the necessary random bits. For 256 bit of randomness you need about a hundred D6 die rolls, probably a little bit more, as your dice are probably not perfect. The easiest way would be to feed the result string ("6216543155314"...) into a hash fuction like sha256 and use the output as a key for the ciphers mentioned above (Fortuna is not a cipher, I know). But honestly, that is really a bit too paranoid (and impractical). It's much faster and probably equally secure to take 256 bit of randomness from /dev/random, concatenate that with the output of one minute of keyboard smashing and feed the result to sha256 to generate your PRNG seed. (I propose the use of both randomness sources because taking bits from /dev/random is so easy and it can only increase randomness)

venomsnake 13y ago
Keyboard smashing is surprisingly predictable by the views of what I smash when a program ask for entropy. You have the center row over represented with a lot of asd clustered (old gamer hehe)
- PhantomGremlin 13y ago
  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.

venomsnake 13y ago

Keyboard smashing is surprisingly predictable by the views of what I smash when a program ask for entropy. You have the center row over represented with a lot of asd clustered (old gamer hehe)

PhantomGremlin 13y ago
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.