I was able to reproduce this issue on the latest sccKit 1.4.2. You are correct about /dev/random being the interface to the random number generator. If there is enough entropy in the kernel's pool, it returns random data; otherwise, it blocks until the pool has been filled again. Unfortunately there is no "real" workaround for missing entropy; after all, computers are deterministic (at least we hope so ), so they cannot generate "random" data if there is no source of white noise.
As for the issue with /dev/random, we can cheat. If you do not need real random data and are fine with what /dev/urandom produces, you can just use that. I'd think this is the preferred method, because it makes clear (in the application's configuration, or maybe even its source code) that it uses pseudo-random data.
If this is not possible, e.g. because you cannot recompile, you can still redirect /dev/random to /dev/urandom. I tried two methods, and both of them worked:
- "rm /dev/random", then "ln -s /dev/urandom /dev/random". That should make all applications referring /dev/random to use /dev/urandom instead. However, applications can detect this change (e.g., because "random" is now a symbolic link, not a device node), and it would not help for programs creating their own "random" device node (whose major and minor function numbers are well-known).
- Install rng-tools on the SCC cores (in the buildroot directory, make menuconfig, Package Selection for Target, Hardware Handling, rng-tools; recompile), then start "rngd --rng-device=/dev/urandom". That fills the kernel's entropy pool with data from /dev/urandom, so you can now read /dev/random without ever having to wait again.
Inevitable disclaimer: Please note that, in both cases, data read from /dev/random is now only as good as /dev/urandom; i.e., pseudo-random and predictable. Using such data is strongly discouraged for any security-sensitive work. You can still use it to generate keys, but I suggest never to use such keys outside of a lab environment.
Last but not least, there is also a method for inserting real entropy into the pool that does not require such tricks: connect to the SCC core using sccDisplay (sccGui must be closed first), then work a bit from that console session. The emulated keyboard and mouse produce entropy that can be read using the default /dev/random.
Perfect. Thank You.