3 ms·

Isn't this basically another take on HAVEGE[1]? I'm not sure I'd call that a true random source. [1] https://www.irisa.fr/caps/projects/hipsor/; https://www.ir

by qrmn 11y ago

Isn't this basically another take on HAVEGE[1]? I'm not sure I'd call that a true random source. [1] https://www.irisa.fr/caps/projects/hipsor/; https://www.irisa.fr/caps/projects/hipsor/; see http://www.issihosts.com/haveged/ http://www.issihosts.com/haveged/

AlyssaRowan 11y ago
As I've said before: look out for side-channels! The RF/electrical/other emissions from general-purpose CPU cores and their supporting circuitry tend to have major features with good correlations to execution timing and pipeline stalls, which they are not designed to treat as secret. This is one reason why crypto implementations should be written using techniques that avoid table lookups or branches based on secret data: another is of course that the resulting timing variations may be visible on another core, over a network, etc. Systems which treat the TSC (etc) as such secret data that they effectively seed a PRNG with it should therefore be treated with a very considerable degree of caution considering just how (literally) squeaky some cores/boards can be about leaking it. Further research is needed.
JoachimS 11y ago
There are several entropy sources like this -Havege, jytter and Dakarand all tries to use jitter and unpredictable behavior in CPUs. The chief advantage is that they don't need another HW source beside the CPU itself. I've been sceptic to how well they work on simpler architectures like ARM. (Havege for example tries to force cache misses in multi level memory system, which implies a need for caches). But at least Jytter actually seems to work fairly well on embedded CPUs too. What to remember is to use these as entropy sources, not source for random numbers. Seed a proper csprng and use that to generate numbers. Quite a few CPUs today can implement AES efficiently so AES-CTR is probably a good choice in many systems.

by qrmn 11y ago

AlyssaRowan 11y ago

As I've said before: look out for side-channels! The RF/electrical/other emissions from general-purpose CPU cores and their supporting circuitry tend to have major features with good correlations to execution timing and pipeline stalls, which they are not designed to treat as secret. This is one reason why crypto implementations should be written using techniques that avoid table lookups or branches based on secret data: another is of course that the resulting timing variations may be visible on another core, over a network, etc. Systems which treat the TSC (etc) as such secret data that they effectively seed a PRNG with it should therefore be treated with a very considerable degree of caution considering just how (literally) squeaky some cores/boards can be about leaking it. Further research is needed.

JoachimS 11y ago

There are several entropy sources like this -Havege, jytter and Dakarand all tries to use jitter and unpredictable behavior in CPUs. The chief advantage is that they don't need another HW source beside the CPU itself. I've been sceptic to how well they work on simpler architectures like ARM. (Havege for example tries to force cache misses in multi level memory system, which implies a need for caches). But at least Jytter actually seems to work fairly well on embedded CPUs too. What to remember is to use these as entropy sources, not source for random numbers. Seed a proper csprng and use that to generate numbers. Quite a few CPUs today can implement AES efficiently so AES-CTR is probably a good choice in many systems.