Re: /dev/random is probably not

From: Anton Ivanov (arivanov_at_sigsegv.cx)
Date: 07/05/05

  • Next message: ZATAZ Audits: "ekg insecure temporary file creation and arbitrary code execution" 
    Date: Tue, 05 Jul 2005 08:45:01 +0100
To: "\"Zow\" Terry Brugger" <zow@llnl.gov>

    Hi List,

    I think that the question here is different.

    Why anyone is using the old entropy based RNG at all on modern commodity
    hardware?

    It is good if you know that your hardware operates in a manner which
    provides good entropy and functions according to the RNG design. If the
    platform does not do this, you might as well stay with the hardware
    implementation present in most off the shelf hardware.

    Via (from Nehemia core and upwards) - on CPU crypto quality RNG.
     
    Intel - All chipsets from 82x onwards have a hardware RNG. It is thermal
    noise based which is still likely to be better then deterministic IRQ
    feeds from network and modern disks.

    AMD - All chipsets in the 76x series have hardware RNG.

    Others - well... Not all silicon is created equal I am afraid.

    A.

    Zow Terry Brugger wrote:

    >>- Linux? (I don't think so, If we have network and other I/O device
    >> such as keyboard, I thought that would be used, too.
    >> but I want confirmation from people in the know.)
    >>
    >>
    >
    >It's been a while since I looked at the /dev/random design on Linux (probably
    >the early 2.4 days), however one thing that was quite clear was that they did
    >not use any network I/O as entropy sources because an attacker, particularly
    >one that already had control of other machines on the same LAN segment, could
    >have a high degree of control over that source. I would be most interested if
    >that has changed since the last time I looked at it.
    >
    >
    >
    >> OpenBSD, FreeBSD, NetBSD and the like, and of course
    >>
    >>
    >
    >Checking the /dev/random manpage on Darwin, it indicates that entropy is
    >input from the system "Security Server", which uses "kernel jitter".
    >Unfortunately, a quick check did not reveal exactly what the source of this
    >kernel jitter is. Never-the-less, the manpage does indicate that this
    >/dev/random design is from FreeBSD and likely shared with other BSDs.
    >
    >
    >
    >> Windows family OSs.
    >>
    >>
    >
    >All I can observe here is that F-secure SSH still (at least the most recent
    >version I've used) collects its own entropy when running on Win2K, which
    >indicates to me that either they want to operate the same on all Windows
    >versions (as memory serves, Win95/98 does not have a RNG), or that Win2k does
    >not have a suitable RNG.
    >
    >
    >
    >>One of these days, on desktop PCs,
    >>we could add the reading of diode used for measuring
    >>CPU temperature to the mix of
    >>entropy source. (Of course, we need a good source of
    >>`entropy' to begin with, and adding another source such
    >>as diode is a good thing IMHO.)
    >>And maybe the fan rotation/speed, too. I found that
    >>they change constantly on my PC!
    >>
    >>
    >
    >You would only want to use one or the other, since the fan rotation is a
    >function of the CPU temperature measurement -- if you used both you would
    >essentially be entering the same measurement into the RNG twice, which isn't
    >very random.
    >
    >
    >
    >>Some of these CPU-bound devices may have
    >>implications when we have a dual core CPU.
    >>Reading of such device by one thread may be
    >>highly predictable by another thread running on the
    >>CPU chip.
    >>
    >>
    >
    >Indeed -- certainly the recent advisory regarding information leakage through
    >the cache between threads on multi-core CPUs (CVN: CAN-2005-0109) indicates
    >that we're starting to find problems of this nature already.
    >
    >Cheers,
    >Terry
    >
    >#include <stddisclaim.h>
    >
    >
    >
    >
    > 

    -- 
La Châtelier's Law: 
          If some stress is brought to bear on a system in equilibrium, 
the equilibrium is displaced in the direction which tends to undo the 
effect of the stress.
  • Next message: ZATAZ Audits: "ekg insecure temporary file creation and arbitrary code execution"

    Relevant Pages

    • Re: [PATCH] hw_random: add quality categories
      ... If it's gathering its entropy from the network, ... RNG because it is not a hardware random number generator at all! ... And an extension board would win over the CPU. ...
      (Linux-Kernel)
    • Re: Fury over bishops comments
      ... 'hardware' and back again. ... By people or things with access to that duplicate disc. ... information which produces patches of decreased entropy. ... the objects in the simulation won't change ...
      (uk.religion.christian)
    • Re: new /dev/random
      ... etc to provide the true random information for the RNG. ... >>into a PRNG for reasons he has failed to convince anyone but himself of. ... with input from "entropy sources" as it goes, ... In the current /dev/random implementation there is an entropy estimator ...
      (sci.crypt)
    • Re: [PATCH] hw_random: add quality categories
      ... RNG because it is not a hardware random number generator at all! ... it does not deserve to be called a real HWRNG. ... I do not believe there exist devices that deserve to be classified as ...
      (Linux-Kernel)
    • Re: [patch 2/9] Add new generic HW RNG core
      ... +void hwrng_cleanup(struct hwrng *rng) ... So it reduces syscall overhead. ... device which needs 20usecs between reads to gather new entropy. ...
      (Linux-Kernel)
    Loading