implementing true random numbers - Linux

This is a discussion on implementing true random numbers - Linux ; Hi all A few days ago I sent an email to this newsgroup about true random numbers. But it got a philosophical discussion. So I'd better ask my question clearly. I wanted to know if I can find someone who ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: implementing true random numbers

  1. implementing true random numbers

    Hi all

    A few days ago I sent an email to this newsgroup about true random
    numbers. But it got a philosophical discussion. So I'd better ask my
    question clearly. I wanted to know if I can find someone who helps me
    to implement a true random number generator. I'm a newbie, and just
    read this paper,www.psigenics.com/Research/Papers/US06862605.pdf, which
    claims using two oscillators we can produce true random numbers, and we
    have two oscillators inside a PC. Anyway, they,www.psigenics.com, have
    written a program under windows and claim it produce true random
    numbers.
    Actually I wanted to play with that TRN generator like this project:
    http://www.princeton.edu/~pear/ if I can't implement a software TRN
    generator I'll buy a hardware for that next month.

    Thanks for your attention,
    Hesham


  2. Re: implementing true random numbers

    Hesham wrote:

    > I wanted to know if I can find someone who helps me
    > to implement a true random number generator.


    See here: http://www.lavarnd.org/
    You need a webcam to function as a random noise source.

    --
    Markku Kolkka
    markku.kolkka@iki.fi



  3. Re: implementing true random numbers

    Hesham wrote in part:
    > A few days ago I sent an email to this newsgroup about true
    > random numbers. But it got a philosophical discussion. So I'd
    > better ask my question clearly. I wanted to know if I can find
    > someone who helps me to implement a true random number generator.


    Already in the kernel: man 4 random , and of course the source.

    There are also thermal diodes inside some chipsets
    which will also generate true random numbers.

    The problem with all such generators is the amount of entropy
    they receive is limited. The diodes give ~10 Mbit/s, the
    Linux kernel device considerably less.

    -- Robert


  4. Re: implementing true random numbers


    Hesham wrote:

    > I'm a newbie, and just
    > read this paper,www.psigenics.com/Research/Papers/US06862605.pdf, which
    > claims using two oscillators we can produce true random numbers, and we
    > have two oscillators inside a PC.


    A typical PC does have several oscillators. Unfortunately, you
    generally can only mine a small amount of true randomness from those
    oscillators because there is no good method to extract it.

    To some extent, it does get philosophical, because there are no
    practical differences between true random numbers and the output of a
    strong PRNG that's been seeded with true random numbers.

    > Anyway, they,www.psigenics.com, have
    > written a program under windows and claim it produce true random
    > numbers.


    That could mean any number of things

    > Actually I wanted to play with that TRN generator like this project:
    > http://www.princeton.edu/~pear/ if I can't implement a software TRN
    > generator I'll buy a hardware for that next month.


    Some chipsets have built-in true random number generators (I think it's
    from quantum tunnelling noise in a reverse-biased zener diode, but I'm
    not sure). I'm not sure how much randomness they produce and how high
    its quality is. Generally, you need to post-process the randomness
    produced by hardware generators because the quality is typically poor.

    If you do try to rig up your own hardware RNG, make sure to both test
    it thoroughly and post-process it appropriately. Hardware output almost
    always displays bias of various types and requires algorithmic
    post-processing.

    Note that validating must include both algorithmic/method validation
    (making sure the method used is sound) and output testing (making sure
    the results pass statistical tests for randomness). Neither alone is
    sufficient.

    See
    http://en.wikipedia.org/wiki/Diehard_tests

    DS


  5. Re: implementing true random numbers

    "David Schwartz" writes:

    [...]

    > To some extent, it does get philosophical, because there are no
    > practical differences between true random numbers and the output of a
    > strong PRNG that's been seeded with true random numbers.


    There is the very practical difference that, according to current
    theory, outputs of a cryptographically secure PRNG cannot be used to
    calculate future outputs of the same PRNG. But this is just a
    limitation of current theories about the mathematical operations
    involved, which could go away at any time. So, the practical
    standpoint would be to use 'true' random numbers instead of relying on
    not-development of new theories.

  6. Re: implementing true random numbers


    Rainer Weikusat wrote:

    > "David Schwartz" writes:


    > > To some extent, it does get philosophical, because there are no
    > > practical differences between true random numbers and the output of a
    > > strong PRNG that's been seeded with true random numbers.


    > There is the very practical difference that, according to current
    > theory, outputs of a cryptographically secure PRNG cannot be used to
    > calculate future outputs of the same PRNG. But this is just a
    > limitation of current theories about the mathematical operations
    > involved, which could go away at any time. So, the practical
    > standpoint would be to use 'true' random numbers instead of relying on
    > not-development of new theories.


    If you want to argue at the extreme limit of possibility, maybe someone
    will come up with a future model for shot noise in a zener diode or
    zone temperature variations in a crystal oscillator. It is not
    particularly hard to come up with PRNGs where the likelihood of them
    being algorithmically compromised ever is as unlikely as this.

    You can rig a PRNG anywhere on the continuum that you want. On one end,
    you have say 128-bits of input and a million bits of output. The
    possibility of algorithmic compromise eventually is almost certain. On
    the other end, you have say 65,536 bits of input and a million bits of
    output. The possibilty of algorithmic compromise in the next thousand
    years seems to be pretty close to zero.

    I guess you can make an argument that it could make a difference in a
    situation where a person might be able to get all of the random output
    up to a certain point and it matters if a thousand years later they can
    be 80% sure what the next bit is.

    DS


  7. Re: implementing true random numbers

    "David Schwartz" writes:
    > Rainer Weikusat wrote:
    >> "David Schwartz" writes:
    >> > To some extent, it does get philosophical, because there are no
    >> > practical differences between true random numbers and the output of a
    >> > strong PRNG that's been seeded with true random numbers.

    >
    >> There is the very practical difference that, according to current
    >> theory, outputs of a cryptographically secure PRNG cannot be used to
    >> calculate future outputs of the same PRNG. But this is just a
    >> limitation of current theories about the mathematical operations
    >> involved, which could go away at any time. So, the practical
    >> standpoint would be to use 'true' random numbers instead of relying on
    >> not-development of new theories.

    >
    > If you want to argue at the extreme limit of possibility, maybe someone
    > will come up with a future model for shot noise in a zener diode or
    > zone temperature variations in a crystal oscillator. It is not
    > particularly hard to come up with PRNGs where the likelihood of them
    > being algorithmically compromised ever is as unlikely as this.


    One process is believed to be random, according to 'current theory',
    and the other is known to be non-random, but nobody knows how to
    exploit this fact. So, from a _practical_ standpoint, use the first
    and avoid the latter, if 'easily enough' possible. There is no need to
    get more fancy than that, except if being interested in the theory/ies
    itself/ themselves.

+ Reply to Thread