The current discussion about breaking encryption algorithm has one common thread: random number generators. No matter the encryption algorithm, if your encryption keys are not random, the algorithm can be brute forced much easier then theoretically predicted based on the strength of the algorithm. All encryption algorithms depend on good random keys and generating good random numbers has long been a problem.

In Unix systems for example, you will have two random devices: /dev/random and /dev/urandom. "random" usually produces random numbers based on some source of entropy. In Linux, parameters like mouse movements, disk activity and interrupts are used. Older versions of the random number generator used network activity, but since the attacker may be able to affect network activity, this parameter is no longer used. The Linux random number generator was found to be not particularly well implemented, in particular on disk less systems and systems with little user activity, like for example routers [1] .

Recently, some implementations of Linux like OpenWRT where found vulnerable if they are used on MIPS based hardware. The random number generator on these systems uses the number of CPU cycles since reboot as a seed. However, the respective function always returns 0, not the actual number of cycles on MIPS. [2]

Are there better ways to collect random numbers? One of the challenges is to increase the amount of entropy (random events) collected. There are some good attempts to use microphones, cameras and other hard ware devices to improve the pool of entropy. Sadly, there are no simple "standardized" solutions to implement these techniques.

via ISC Diary | A Random Diary.



My original entry is here: ISC Diary | A Random Diary. It posted Fri, 20 Sep 2013 10:40:34 +0000.

Filed under: InfoSec, random number generation,