Couldn't obtain random bytes in sshd - problem in RAND_poll? - Openssl

This is a discussion on Couldn't obtain random bytes in sshd - problem in RAND_poll? - Openssl ; Hi, I and a few other users are seeing sshd failing with Couldn't obtain random bytes (error 604389476) and other ssl-related application failing randomly in user mode linux guests and I suspect a problem in openssl that got triggered by ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 42

Thread: Couldn't obtain random bytes in sshd - problem in RAND_poll?

  1. Couldn't obtain random bytes in sshd - problem in RAND_poll?

    Hi,

    I and a few other users are seeing sshd failing with
    Couldn't obtain random bytes (error 604389476)
    and other ssl-related application failing randomly
    in user mode linux guests and I suspect a problem
    in openssl that got triggered by some change in UML.

    I reviewed the RAND_poll function in rand_unix.c
    (statically, no time for building a debug version now)
    and have following suspicions:

    ===
    For Linux:

    int r; ... this has random bytes from stack
    ....

    if (poll(&pset, 1, usec / 1000) < 0)
    usec = 0;
    else
    try_read = (pset.revents & POLLIN) != 0;

    .... Let's say that the poll timed out (i.e. returned 0)
    try_read remains 0, r still has garbage

    while ((r > 0 || (errno == EINTR || errno == EAGAIN)) &&

    .... Let's say that the garbage was negative. We are out of
    the loop and errno has bogus data (successfull/timed out
    poll did not set anything)


    === For other Unices there's additional problem:

    If the select select's successfully and immediately, it can
    leave the time not slept unchanged in the time argument
    (which is IMHO fully legal, if it finds the bytes immediately).
    If the read then does not get all the needed bytes, the code
    if (usec == 10*1000)
    usec = 0;
    kicks in and we are out of the loop again.


    Suggested changes:

    - add
    r = -1;
    inside the do loop after the int try_read = 0;

    - change
    if (usec == 10*1000)
    into
    if (r < 0 && usec == 10*1000)


    Regards
    --
    Stano
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    Stanislav Meduna wrote:
    > - add
    > r = -1;
    > inside the do loop after the int try_read = 0;


    Erm, actually I mean
    r = -1;
    errno = EAGAIN;
    or something like that - it has to let the while know
    that the poll timed out.

    --
    Stano
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    On Wed, 2008-08-06 at 11:08 +0200, Stanislav Meduna wrote:
    > Hi,
    >
    > I and a few other users are seeing sshd failing with
    > Couldn't obtain random bytes (error 604389476)
    > and other ssl-related application failing randomly
    > in user mode linux guests and I suspect a problem
    > in openssl that got triggered by some change in UML.
    >
    > I reviewed the RAND_poll function in rand_unix.c
    > (statically, no time for building a debug version now)
    > and have following suspicions:
    >
    > ===
    > For Linux:
    >
    > int r; ... this has random bytes from stack
    > ...
    >
    > if (poll(&pset, 1, usec / 1000) < 0)
    > usec = 0;
    > else
    > try_read = (pset.revents & POLLIN) != 0;
    >
    > ... Let's say that the poll timed out (i.e. returned 0)
    > try_read remains 0, r still has garbage


    The r is set to -1 in the else of if(try_read) statement.

    > while ((r > 0 || (errno == EINTR || errno == EAGAIN)) &&
    >
    > ... Let's say that the garbage was negative. We are out of
    > the loop and errno has bogus data (successfull/timed out
    > poll did not set anything)


    errno has garbage value - this should be fixed by initializing errno to
    0 before the poll/select calls. But in the worst case it means the code
    will wait until it will be able to read some data from the random device
    (which was not the intent).

    >
    > === For other Unices there's additional problem:
    >
    > If the select select's successfully and immediately, it can
    > leave the time not slept unchanged in the time argument
    > (which is IMHO fully legal, if it finds the bytes immediately).
    > If the read then does not get all the needed bytes, the code
    > if (usec == 10*1000)
    > usec = 0;
    > kicks in and we are out of the loop again.


    The problem is not in the RAND_poll() timeouting - this is fully
    intentional, the function should timeout after 10ms if the random device
    blocks read. The default is to
    try /dev/urandom, /dev/random, /dev/srandom in this order. So if you for
    example do not have /dev/urandom and have just the blocking /dev/random,
    it is perfectly possible that the RAND_poll returns error. The other
    possibility is that the /dev/urandom is broken in UML and blocks if not
    enough entropy is available.

    --
    Tomas Mraz
    No matter how far down the wrong road you've gone, turn back.
    Turkish proverb

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    Tomas Mraz wrote:

    > errno has garbage value - this should be fixed by initializing errno to
    > 0 before the poll/select calls.


    Actually after it returns with timeout - a successfull
    syscall is free to set errno to whatever value it wants,
    it is only after an error the value has to be meaningful
    (I did have this problem a few times).

    > The problem is not in the RAND_poll() timeouting - this is fully
    > intentional, the function should timeout after 10ms if the random device
    > blocks read.


    Ah, ok..

    So what should the applications calling openssl actually
    do if this happens? Now the ssh/apache/... simply exit,
    which is bad (it left me without an access to a remote
    box...).

    I assume they are not calling the method directly, instead
    they are using some of the openssl's methods. In the current
    situation anyone who actually wants to block until the entropy
    is available is simply out of luck

    > try /dev/urandom, /dev/random, /dev/srandom in this order. So if you for
    > example do not have /dev/urandom and have just the blocking /dev/random,
    > it is perfectly possible that the RAND_poll returns error.


    Both UML guest and host have /dev/urandom. I straced
    a ssh, it opens /dev/urandom first, so this should
    be OK too.

    > The other possibility is that the /dev/urandom is broken
    > in UML and blocks if not enough entropy is available.


    Good.. let's try it:

    ===
    #include
    #include
    #include
    #include


    main()
    {
    int fd = open("/dev/urandom", O_RDONLY|O_NONBLOCK|O_NOCTTY);
    int i;
    int errpoll=0, blocked=0, rdbytes=0,errread=0, nullread=0;

    for (i=0; i < 1000000; ++i)
    {
    struct pollfd pset;
    int r;
    char tmp[32];

    pset.fd = fd;
    pset.events = POLLIN;
    pset.revents = 0;

    r = poll(&pset, 1, 10);
    if (r > 0)
    {
    if ((pset.revents & POLLIN) != 0)
    {
    r = read(fd, tmp, sizeof(tmp));
    if (r < 0)
    errread++;
    else if (r==0)
    nullread++;
    else
    rdbytes += r;
    }
    else
    {
    printf("poll returned %d, but POLLIN is false (%x)\n", r, pset.revents);
    }
    }
    else if (r == 0)
    blocked++;
    else
    errpoll++;
    }

    printf("got %d bytes of entropy, poll err %d, blocked %d times, err read: %d, null
    read: %d\n", rdbytes, errpoll, blocked, errread, nullread);
    }
    ===

    got 3200000 bytes of entropy, poll err 0, blocked 0 times, err read: 0, null read: 0


    Tried many many times, even two running at the same time
    or poll timeout set to zero, not one instance of blocking
    even with
    od -x /dev/urandom
    and
    od -x /dev/random
    running simultaneously (the second one blocks, of course).


    Hmmmm.. what the #$%# is happening here.. more ideas?

    --
    Stano
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  5. RE: Couldn't obtain random bytes in sshd - problem in RAND_poll?



    > Tried many many times, even two running at the same time
    > or poll timeout set to zero, not one instance of blocking
    > even with
    > od -x /dev/urandom
    > and
    > od -x /dev/random
    > running simultaneously (the second one blocks, of course).
    >
    >
    > Hmmmm.. what the #$%# is happening here.. more ideas?
    >
    > --
    > Stano


    My bet is that '/dev/urandom' only blocks if it doesn't have enough entropy.
    Early in the startup process, '/dev/urandom' doesn't have enough entropy,
    and your application times out on it.

    Later on, when the system has had lots of network activity, you log in and
    test '/dev/urandom'. At this point, the system is well-seeded from the
    network activity. So it works great for you.

    Try launching your test program automatically on boot up at the saem time
    you launch ssh or whatever application is failing. I bet '/dev/urandom' will
    fail then.

    If you have a network, one solution might be to do a few 'ping's or
    'nslookup's to seed the entropy pool. You can also keep an entropy pool on
    disk, saving it on shutdown and loading it on startup.

    Or I could be completely wrong.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  6. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    You're right: You are completely wrong. /dev/urandom never blocks.
    See the man page.

    David Schwartz wrote:
    >
    >> Tried many many times, even two running at the same time
    >> or poll timeout set to zero, not one instance of blocking
    >> even with
    >> od -x /dev/urandom
    >> and
    >> od -x /dev/random
    >> running simultaneously (the second one blocks, of course).
    >>
    >>
    >> Hmmmm.. what the #$%# is happening here.. more ideas?
    >>
    >> --
    >> Stano

    >
    > My bet is that '/dev/urandom' only blocks if it doesn't have enough entropy.
    > Early in the startup process, '/dev/urandom' doesn't have enough entropy,
    > and your application times out on it.
    >
    > Later on, when the system has had lots of network activity, you log in and
    > test '/dev/urandom'. At this point, the system is well-seeded from the
    > network activity. So it works great for you.
    >
    > Try launching your test program automatically on boot up at the saem time
    > you launch ssh or whatever application is failing. I bet '/dev/urandom' will
    > fail then.
    >
    > If you have a network, one solution might be to do a few 'ping's or
    > 'nslookup's to seed the entropy pool. You can also keep an entropy pool on
    > disk, saving it on shutdown and loading it on startup.
    >
    > Or I could be completely wrong.
    >
    > DS
    >
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  7. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    On Wed, 6 Aug 2008, Stanislav Meduna wrote:

    > So what should the applications calling openssl actually
    > do if this happens? Now the ssh/apache/... simply exit,
    > which is bad (it left me without an access to a remote
    > box...).


    Exiting is the best behaviour - continuing without a good source
    of randomness may compromise cryptographic protocols and even
    long-term private keys (e.g. if DSA is used).

    -d
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  8. RE: Couldn't obtain random bytes in sshd - problem in RAND_poll?


    David Shambroom wrote:

    > You're right: You are completely wrong. /dev/urandom never blocks.
    > See the man page.


    Is this is the excerpt from the man page you are referring to?

    A read from the /dev/urandom device will not block waiting for
    more
    entropy. As a result, if there is not sufficient entropy in
    the
    entropy pool, the returned values are theoretically vulnerable to
    a
    cryptographic attack on the algorithms used by the driver.
    Knowledge
    of how to do this is not available in the current non-classified
    liter-
    ature, but it is theoretically possible that such an attack may
    exist.
    If this is a concern in your application, use /dev/random instead.

    If so, this doesn't say that /dev/urandom never blocks. It just says that it
    will not block waiting for more entropy. In fact, this paragraph is horribly
    misleading, because it suggests that the worst thing /dev/urandom can do is
    return random values with a theoretical vulnerability. Alas, this is not
    true. The /dev/urandom interface will happily return entirely predictable
    values if the pool was never seeded.

    If the entropy pool was ever seeded, then it can produce
    cryptographically-strong entropy forever. You cannot run it out of entropy.
    However, if it was *never* seeded, it cannot produce even a single byte of
    crypotgraphically-strong entropy.

    Reading back over the post you are responding to, I realize that it reads to
    mean the complete opposite of what I was trying to say. I'm not sure how I
    managed to do that. I was very sloppy with my terms.

    What I was trying to address was the case where the pool was never seeded,
    not the case where the pool runs out of entropy. However, reading my words,
    it seems I somehow said the exact opposite of what I was thinking!

    Sadly, Linux suffers from a three bears problem. The /dev/random
    implementation will block even if cryptographically-strong randomness is
    available. The /dev/urandom implementation will happilly hand you numbers
    that are not cryptograhically-strong. There is no "just right" interface
    that will tell you whether or not cryptographically-strong randomness is
    available and let you block waiting for it if you choose to.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  9. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    David S: to my knowledge you're at least somewhat incorrect, and part
    of your advice is rather dangerous to rely upon (from a cryptographic
    theory perspective).

    /dev/urandom will never, under normal circumstances, block -- its
    output is generated algorithmically by the random/urandom device
    driver. (It's akin to reading from /dev/null or /dev/zero, in that
    the read is always handled by the kernel driver without having to wait
    for anything.)

    /dev/urandom will not block.
    /dev/random will block if there isn't enough entropy stirred into it.

    And yes, it is possible to "run out" the entropy pool. The amount of
    chaos that you stir in is the amount of chaos that you can pull out --
    everything else is deterministic, and as the man page says there may
    be a theoretical way that the pseudorandom number generator can be
    attacked (though one is currently not known in the nonclassified
    literature) with the result that the keys generated will be
    predictable.

    If the pool is never seeded, the "randomness" won't ever be really random.
    If the pool is seeded once, the "randomness" will be random for as
    long as the amount of entropy in the seed holds out. After this, the
    numbers generated won't really be random.
    If the pool is continually re-seeded, the "randomness" will be random
    for as long as the amount of entropy in the seeds fed into it holds
    out. After this, the numbers generated won't really be random, until
    more entropy is stirred in -- and even then, that will be exhausted in
    the same way.

    The only way to guarantee that your numbers are truly
    cryptographically secure is to use /dev/random and deal with the fact
    that it will block until there's been enough entropy seeded into the
    randomness pool. Otherwise, many random number generators use a
    linear-feedback shift register with a periodicity of 2**56. That's
    approximately the same amount of keyspace as DES, and the output over
    multiple successions of readings of 2**56 bytes will repeat and not be
    suitably random. (If an attacker can figure out the state of your
    PRNG, the attacker can figure out your next-generated "secret"
    randomness. This is why the Debian debacle was so serious, and why
    only a few thousand possible keys were generated by the vulnerable
    implementations -- the randomness wasn't.)

    I'd certainly like to see references to the contrary, if they exist --
    my references are the Handbook of Applied Cryptography and Applied
    Cryptography 2nd Ed.

    -Kyle H

    On Thu, Aug 7, 2008 at 2:13 AM, David Schwartz wrote:
    >
    > David Shambroom wrote:
    >
    >> You're right: You are completely wrong. /dev/urandom never blocks.
    >> See the man page.

    >
    > Is this is the excerpt from the man page you are referring to?
    >
    > A read from the /dev/urandom device will not block waiting for
    > more
    > entropy. As a result, if there is not sufficient entropy in
    > the
    > entropy pool, the returned values are theoretically vulnerable to
    > a
    > cryptographic attack on the algorithms used by the driver.
    > Knowledge
    > of how to do this is not available in the current non-classified
    > liter-
    > ature, but it is theoretically possible that such an attack may
    > exist.
    > If this is a concern in your application, use /dev/random instead.
    >
    > If so, this doesn't say that /dev/urandom never blocks. It just says that it
    > will not block waiting for more entropy. In fact, this paragraph is horribly
    > misleading, because it suggests that the worst thing /dev/urandom can do is
    > return random values with a theoretical vulnerability. Alas, this is not
    > true. The /dev/urandom interface will happily return entirely predictable
    > values if the pool was never seeded.
    >
    > If the entropy pool was ever seeded, then it can produce
    > cryptographically-strong entropy forever. You cannot run it out of entropy.
    > However, if it was *never* seeded, it cannot produce even a single byte of
    > crypotgraphically-strong entropy.
    >
    > Reading back over the post you are responding to, I realize that it reads to
    > mean the complete opposite of what I was trying to say. I'm not sure how I
    > managed to do that. I was very sloppy with my terms.
    >
    > What I was trying to address was the case where the pool was never seeded,
    > not the case where the pool runs out of entropy. However, reading my words,
    > it seems I somehow said the exact opposite of what I was thinking!
    >
    > Sadly, Linux suffers from a three bears problem. The /dev/random
    > implementation will block even if cryptographically-strong randomness is
    > available. The /dev/urandom implementation will happilly hand you numbers
    > that are not cryptograhically-strong. There is no "just right" interface
    > that will tell you whether or not cryptographically-strong randomness is
    > available and let you block waiting for it if you choose to.
    >
    > DS
    >
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  10. RE: Couldn't obtain random bytes in sshd - problem in RAND_poll?


    Kyle Hamilton wrote:

    > David S: to my knowledge you're at least somewhat incorrect, and part
    > of your advice is rather dangerous to rely upon (from a cryptographic
    > theory perspective).


    You are at least somewhat incorrect too.

    > And yes, it is possible to "run out" the entropy pool. The amount of
    > chaos that you stir in is the amount of chaos that you can pull out --
    > everything else is deterministic, and as the man page says there may
    > be a theoretical way that the pseudorandom number generator can be
    > attacked (though one is currently not known in the nonclassified
    > literature) with the result that the keys generated will be
    > predictable.


    This is correct, but doesn't conflict with anything that I've said.

    > If the pool is never seeded, the "randomness" won't ever be really random.


    Right.

    > If the pool is seeded once, the "randomness" will be random for as
    > long as the amount of entropy in the seed holds out. After this, the
    > numbers generated won't really be random.


    Right, but they will be cryptogrpahically secure. Forever.

    > If the pool is continually re-seeded, the "randomness" will be random
    > for as long as the amount of entropy in the seeds fed into it holds
    > out. After this, the numbers generated won't really be random, until
    > more entropy is stirred in -- and even then, that will be exhausted in
    > the same way.


    Correct. They will, however, always be cryptographically secure.

    > The only way to guarantee that your numbers are truly
    > cryptographically secure is to use /dev/random and deal with the fact
    > that it will block until there's been enough entropy seeded into the
    > randomness pool.


    Nope. That does not "guarantee" that the numbers are truly cryptogrpahically secure. There could be a bug in the /dev/random implementation. A cosmic ray may cause the PRNG software to be bypassed.

    If you get to argue that there might be a weakness in the PRNG algorithm such that it does not generate cryptogrpahically-secure numbers even if it was seeded, then I get to argue that there might be a weakness in your RNG alogorithm.

    > Otherwise, many random number generators use a
    > linear-feedback shift register with a periodicity of 2**56. That's
    > approximately the same amount of keyspace as DES, and the output over
    > multiple successions of readings of 2**56 bytes will repeat and not be
    > suitably random.


    That seems pretty boneheaded to me, considering how trivial it is to create PRNGs with much higher periods. In any event, Linux's /dev/urandom implementation has a periodicity of way over 2^64 bytes.

    > (If an attacker can figure out the state of your
    > PRNG, the attacker can figure out your next-generated "secret"
    > randomness. This is why the Debian debacle was so serious, and why
    > only a few thousand possible keys were generated by the vulnerable
    > implementations -- the randomness wasn't.)


    The whole point of the design of Linux's /dev/urandom implementation is that if it was ever seeded, no matter how much output you have made, an attacher can never determine the state of your PRNG. This was an explicit design goal.

    > I'd certainly like to see references to the contrary, if they exist --
    > my references are the Handbook of Applied Cryptography and Applied
    > Cryptography 2nd Ed.


    Linux's /dev/urandom implementation was specifically made such that if it was ever seeded, no amount of known output would compromise the state of the PRNG.

    So long as it is initially seeded, the only risk is that the algorithm has some unknown weakness or bug.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  11. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    On Thu, Aug 07, 2008 at 02:13:27AM -0700, David Schwartz wrote:
    > If so, this doesn't say that /dev/urandom never blocks. It just says that it
    > will not block waiting for more entropy. In fact, this paragraph is horribly
    > misleading, because it suggests that the worst thing /dev/urandom can do is
    > return random values with a theoretical vulnerability. Alas, this is not
    > true. The /dev/urandom interface will happily return entirely predictable
    > values if the pool was never seeded.


    In practice, most Linux distributions (and certainly all of the major
    ones), extract content from /dev/urandom and save it across boot
    sessions. So the once the system becomes seeded, it stays seeded.
    Yes, if you assume that an attacker can remove the hard drive and
    access the urandom seed file across reboots, you're in trouble -- but
    the attacker can also replace the kernel with one that contains a
    keyboard logger, so you'd be even more f*cked.

    The question then is how do you make sure the system is correctly
    initially seeded. This fundamentally depends on the distribution
    installer. If there is sufficient keyboard/mouse activity while the
    system is booted, and the distribution saves the result to urandom
    seed file, then the system can be seeded from its first boot.

    However, if you are worried about systems where you're booting off of
    a CD, and/or where the system is getting installed without any human
    intervention, then yes, there is need to be concerned. The problem
    gets worse if you are booting off of flash where there is entropy
    gained by trying to get timings from any kind of spinning storage. At
    some level, security systems really need to be designed from a system
    perspective, and so there is a quesiton how much of this can or should
    be solved inside the kernel or inside the openssl library.

    The argument for doing something where you are worried about the
    initial seeding problem is probably one where we want to make the
    system more robust against clueless application programmers/system
    engineers trying to put together security solutions. I can think of
    some potential solutions; for example, we can set a flag which is set
    once root has written at least 256 bytes to /dev/random (or
    /dev/urandom; they share the same input pool), OR once the input pool
    has gained at least 64 bytes of entropy credits. And then we could
    have an ioctl which blocks until that that flag is set.

    - Ted
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  12. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    Kyle,

    I didn't say that /dev/urandom was safe to use for cryptographic
    purposes. It isn't, and I didn't then and don't now advise its use. I
    said it never blocks. It doesn't. So what was incorrect?

    Kyle Hamilton wrote:
    > David S: to my knowledge you're at least somewhat incorrect, and part
    > of your advice is rather dangerous to rely upon (from a cryptographic
    > theory perspective).
    >
    > /dev/urandom will never, under normal circumstances, block -- its
    > output is generated algorithmically by the random/urandom device
    > driver. (It's akin to reading from /dev/null or /dev/zero, in that
    > the read is always handled by the kernel driver without having to wait
    > for anything.)
    >
    > /dev/urandom will not block.
    > /dev/random will block if there isn't enough entropy stirred into it.
    >
    > And yes, it is possible to "run out" the entropy pool. The amount of
    > chaos that you stir in is the amount of chaos that you can pull out --
    > everything else is deterministic, and as the man page says there may
    > be a theoretical way that the pseudorandom number generator can be
    > attacked (though one is currently not known in the nonclassified
    > literature) with the result that the keys generated will be
    > predictable.
    >
    > If the pool is never seeded, the "randomness" won't ever be really random.
    > If the pool is seeded once, the "randomness" will be random for as
    > long as the amount of entropy in the seed holds out. After this, the
    > numbers generated won't really be random.
    > If the pool is continually re-seeded, the "randomness" will be random
    > for as long as the amount of entropy in the seeds fed into it holds
    > out. After this, the numbers generated won't really be random, until
    > more entropy is stirred in -- and even then, that will be exhausted in
    > the same way.
    >
    > The only way to guarantee that your numbers are truly
    > cryptographically secure is to use /dev/random and deal with the fact
    > that it will block until there's been enough entropy seeded into the
    > randomness pool. Otherwise, many random number generators use a
    > linear-feedback shift register with a periodicity of 2**56. That's
    > approximately the same amount of keyspace as DES, and the output over
    > multiple successions of readings of 2**56 bytes will repeat and not be
    > suitably random. (If an attacker can figure out the state of your
    > PRNG, the attacker can figure out your next-generated "secret"
    > randomness. This is why the Debian debacle was so serious, and why
    > only a few thousand possible keys were generated by the vulnerable
    > implementations -- the randomness wasn't.)
    >
    > I'd certainly like to see references to the contrary, if they exist --
    > my references are the Handbook of Applied Cryptography and Applied
    > Cryptography 2nd Ed.
    >
    > -Kyle H
    >
    > On Thu, Aug 7, 2008 at 2:13 AM, David Schwartz wrote:
    >> David Shambroom wrote:
    >>
    >>> You're right: You are completely wrong. /dev/urandom never blocks.
    >>> See the man page.

    >> Is this is the excerpt from the man page you are referring to?
    >>
    >> A read from the /dev/urandom device will not block waiting for
    >> more
    >> entropy. As a result, if there is not sufficient entropy in
    >> the
    >> entropy pool, the returned values are theoretically vulnerable to
    >> a
    >> cryptographic attack on the algorithms used by the driver.
    >> Knowledge
    >> of how to do this is not available in the current non-classified
    >> liter-
    >> ature, but it is theoretically possible that such an attack may
    >> exist.
    >> If this is a concern in your application, use /dev/random instead.
    >>
    >> If so, this doesn't say that /dev/urandom never blocks. It just says that it
    >> will not block waiting for more entropy. In fact, this paragraph is horribly
    >> misleading, because it suggests that the worst thing /dev/urandom can do is
    >> return random values with a theoretical vulnerability. Alas, this is not
    >> true. The /dev/urandom interface will happily return entirely predictable
    >> values if the pool was never seeded.
    >>
    >> If the entropy pool was ever seeded, then it can produce
    >> cryptographically-strong entropy forever. You cannot run it out of entropy.
    >> However, if it was *never* seeded, it cannot produce even a single byte of
    >> crypotgraphically-strong entropy.
    >>
    >> Reading back over the post you are responding to, I realize that it reads to
    >> mean the complete opposite of what I was trying to say. I'm not sure how I
    >> managed to do that. I was very sloppy with my terms.
    >>
    >> What I was trying to address was the case where the pool was never seeded,
    >> not the case where the pool runs out of entropy. However, reading my words,
    >> it seems I somehow said the exact opposite of what I was thinking!
    >>
    >> Sadly, Linux suffers from a three bears problem. The /dev/random
    >> implementation will block even if cryptographically-strong randomness is
    >> available. The /dev/urandom implementation will happilly hand you numbers
    >> that are not cryptograhically-strong. There is no "just right" interface
    >> that will tell you whether or not cryptographically-strong randomness is
    >> available and let you block waiting for it if you choose to.
    >>
    >> DS
    >>
    >>
    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> Development Mailing List openssl-dev@openssl.org
    >> Automated List Manager majordomo@openssl.org
    >>

    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  13. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    I'm sorry -- my comment was to David Schwartz (I realized both of you
    were named David, but failed to realize that you also had a surname
    that started with S).

    -Kyle H

    On Thu, Aug 7, 2008 at 11:44 AM, David Shambroom wrote:
    > Kyle,
    >
    > I didn't say that /dev/urandom was safe to use for cryptographic purposes.
    > It isn't, and I didn't then and don't now advise its use. I said it never
    > blocks. It doesn't. So what was incorrect?
    >
    > Kyle Hamilton wrote:
    >>
    >> David S: to my knowledge you're at least somewhat incorrect, and part
    >> of your advice is rather dangerous to rely upon (from a cryptographic
    >> theory perspective).
    >>
    >> /dev/urandom will never, under normal circumstances, block -- its
    >> output is generated algorithmically by the random/urandom device
    >> driver. (It's akin to reading from /dev/null or /dev/zero, in that
    >> the read is always handled by the kernel driver without having to wait
    >> for anything.)
    >>
    >> /dev/urandom will not block.
    >> /dev/random will block if there isn't enough entropy stirred into it.
    >>
    >> And yes, it is possible to "run out" the entropy pool. The amount of
    >> chaos that you stir in is the amount of chaos that you can pull out --
    >> everything else is deterministic, and as the man page says there may
    >> be a theoretical way that the pseudorandom number generator can be
    >> attacked (though one is currently not known in the nonclassified
    >> literature) with the result that the keys generated will be
    >> predictable.
    >>
    >> If the pool is never seeded, the "randomness" won't ever be really random.
    >> If the pool is seeded once, the "randomness" will be random for as
    >> long as the amount of entropy in the seed holds out. After this, the
    >> numbers generated won't really be random.
    >> If the pool is continually re-seeded, the "randomness" will be random
    >> for as long as the amount of entropy in the seeds fed into it holds
    >> out. After this, the numbers generated won't really be random, until
    >> more entropy is stirred in -- and even then, that will be exhausted in
    >> the same way.
    >>
    >> The only way to guarantee that your numbers are truly
    >> cryptographically secure is to use /dev/random and deal with the fact
    >> that it will block until there's been enough entropy seeded into the
    >> randomness pool. Otherwise, many random number generators use a
    >> linear-feedback shift register with a periodicity of 2**56. That's
    >> approximately the same amount of keyspace as DES, and the output over
    >> multiple successions of readings of 2**56 bytes will repeat and not be
    >> suitably random. (If an attacker can figure out the state of your
    >> PRNG, the attacker can figure out your next-generated "secret"
    >> randomness. This is why the Debian debacle was so serious, and why
    >> only a few thousand possible keys were generated by the vulnerable
    >> implementations -- the randomness wasn't.)
    >>
    >> I'd certainly like to see references to the contrary, if they exist --
    >> my references are the Handbook of Applied Cryptography and Applied
    >> Cryptography 2nd Ed.
    >>
    >> -Kyle H
    >>
    >> On Thu, Aug 7, 2008 at 2:13 AM, David Schwartz
    >> wrote:
    >>>
    >>> David Shambroom wrote:
    >>>
    >>>> You're right: You are completely wrong. /dev/urandom never blocks.
    >>>> See the man page.
    >>>
    >>> Is this is the excerpt from the man page you are referring to?
    >>>
    >>> A read from the /dev/urandom device will not block waiting for
    >>> more
    >>> entropy. As a result, if there is not sufficient entropy in
    >>> the
    >>> entropy pool, the returned values are theoretically vulnerable
    >>> to
    >>> a
    >>> cryptographic attack on the algorithms used by the driver.
    >>> Knowledge
    >>> of how to do this is not available in the current non-classified
    >>> liter-
    >>> ature, but it is theoretically possible that such an attack may
    >>> exist.
    >>> If this is a concern in your application, use /dev/random instead.
    >>>
    >>> If so, this doesn't say that /dev/urandom never blocks. It just says that
    >>> it
    >>> will not block waiting for more entropy. In fact, this paragraph is
    >>> horribly
    >>> misleading, because it suggests that the worst thing /dev/urandom can do
    >>> is
    >>> return random values with a theoretical vulnerability. Alas, this is not
    >>> true. The /dev/urandom interface will happily return entirely predictable
    >>> values if the pool was never seeded.
    >>>
    >>> If the entropy pool was ever seeded, then it can produce
    >>> cryptographically-strong entropy forever. You cannot run it out of
    >>> entropy.
    >>> However, if it was *never* seeded, it cannot produce even a single byte
    >>> of
    >>> crypotgraphically-strong entropy.
    >>>
    >>> Reading back over the post you are responding to, I realize that it reads
    >>> to
    >>> mean the complete opposite of what I was trying to say. I'm not sure how
    >>> I
    >>> managed to do that. I was very sloppy with my terms.
    >>>
    >>> What I was trying to address was the case where the pool was never
    >>> seeded,
    >>> not the case where the pool runs out of entropy. However, reading my
    >>> words,
    >>> it seems I somehow said the exact opposite of what I was thinking!
    >>>
    >>> Sadly, Linux suffers from a three bears problem. The /dev/random
    >>> implementation will block even if cryptographically-strong randomness is
    >>> available. The /dev/urandom implementation will happilly hand you numbers
    >>> that are not cryptograhically-strong. There is no "just right" interface
    >>> that will tell you whether or not cryptographically-strong randomness is
    >>> available and let you block waiting for it if you choose to.
    >>>
    >>> DS
    >>>
    >>>
    >>> __________________________________________________ ____________________
    >>> OpenSSL Project http://www.openssl.org
    >>> Development Mailing List openssl-dev@openssl.org
    >>> Automated List Manager majordomo@openssl.org
    >>>

    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> Development Mailing List openssl-dev@openssl.org
    >> Automated List Manager majordomo@openssl.org

    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  14. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    On Thu, Aug 7, 2008 at 6:59 AM, David Schwartz wrote:
    >
    > Kyle Hamilton wrote:
    >
    >> David S: to my knowledge you're at least somewhat incorrect, and part
    >> of your advice is rather dangerous to rely upon (from a cryptographic
    >> theory perspective).

    >
    > You are at least somewhat incorrect too.
    >
    >> And yes, it is possible to "run out" the entropy pool. The amount of
    >> chaos that you stir in is the amount of chaos that you can pull out --
    >> everything else is deterministic, and as the man page says there may
    >> be a theoretical way that the pseudorandom number generator can be
    >> attacked (though one is currently not known in the nonclassified
    >> literature) with the result that the keys generated will be
    >> predictable.

    >
    > This is correct, but doesn't conflict with anything that I've said.
    >
    >> If the pool is never seeded, the "randomness" won't ever be really random.

    >
    > Right.
    >
    >> If the pool is seeded once, the "randomness" will be random for as
    >> long as the amount of entropy in the seed holds out. After this, the
    >> numbers generated won't really be random.

    >
    > Right, but they will be cryptogrpahically secure. Forever.


    Uh, no. If you seed it with 1 bit of entropy, then there's only 2**1
    possible output chains. Entropy is observation of chaos, which is
    supposed to make all possible values of the entropy pool equally
    possible -- and the less entropy you stir in, the more likely it is
    that someone who figures out what's come before is going to be able to
    figure out what's going to come in the future.

    >> The only way to guarantee that your numbers are truly
    >> cryptographically secure is to use /dev/random and deal with the fact
    >> that it will block until there's been enough entropy seeded into the
    >> randomness pool.

    >
    > Nope. That does not "guarantee" that the numbers are truly cryptogrpahically secure. There could be a bug in the /dev/random implementation. A cosmic ray may cause the PRNG software to be bypassed.
    >
    > If you get to argue that there might be a weakness in the PRNG algorithm such that it does not generate cryptogrpahically-secure numbers even if it was seeded, then I get to argue that there might be a weakness in your RNG alogorithm.


    Technically, if you want to absolutely guarantee that you have truly
    cryptographically secure numbers you should perform thermodynamic
    analysis of case air-flows, or measure the periodicity of the release
    of electrons or photons from radioactive nuclei, or directly measure
    other phenomena that are nondeterministic. The /dev/random
    implementation measures as much of the nondeterministic phenomena as
    is possible in a typical computer system, and uses that to seed the
    random number generator.

    /dev/random and /dev/urandom have historically shared the same
    implementation. The difference is that /dev/random blocks when it has
    calculated that its entropy pool is exhausted, and /dev/urandom does
    not.

    >> Otherwise, many random number generators use a
    >> linear-feedback shift register with a periodicity of 2**56. That's
    >> approximately the same amount of keyspace as DES, and the output over
    >> multiple successions of readings of 2**56 bytes will repeat and not be
    >> suitably random.

    >
    > That seems pretty boneheaded to me, considering how trivial it is to create PRNGs with much higher periods. In any event, Linux's /dev/urandom implementation has a periodicity of way over 2^64 bytes.


    Sure, it's possible to create PRNGs with much higher periods, but it's
    rather difficult to create /good/ PRNGs with much higher periods.
    Even then, though, all PRNGs have the property that their output is
    deterministic... and "deterministic" is the antithesis of
    "cryptographically secure".

    >> (If an attacker can figure out the state of your
    >> PRNG, the attacker can figure out your next-generated "secret"
    >> randomness. This is why the Debian debacle was so serious, and why
    >> only a few thousand possible keys were generated by the vulnerable
    >> implementations -- the randomness wasn't.)

    >
    > The whole point of the design of Linux's /dev/urandom implementation is that if it was ever seeded, no matter how much output you have made, an attacher can never determine the state of your PRNG. This was an explicit design goal.


    The whole point of cryptosystem implementation is so that if the key
    is properly kept secret, no matter how much material is encrypted
    under the key, an attacker can never determine the key or the
    plaintext. This is an explicit design goal.

    Of course, no cryptosystem has ever been found to have an unknown
    weakness or buggy implementation, right?

    >
    >> I'd certainly like to see references to the contrary, if they exist --
    >> my references are the Handbook of Applied Cryptography and Applied
    >> Cryptography 2nd Ed.

    >
    > Linux's /dev/urandom implementation was specifically made such that if it was ever seeded, no amount of known output would compromise the state of the PRNG.
    >
    > So long as it is initially seeded, the only risk is that the algorithm has some unknown weakness or bug.


    I'll vote "unknown weakness". Give me /dev/random and blockage any
    day, and/or have me seed the PRNG with the timing of my keystrokes (a
    la PGP 2.x) or mouse-cursor movements (a la PGP 5.x+), or something
    else.

    Entropy is really the only way to protect against PRNG bugs. And it's
    also really the only way to work around the deterministic nature of
    the PRNG.

    -Kyle H
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  15. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    On Fri, 2008-08-08 at 02:52 -0700, Kyle Hamilton wrote:
    > On Thu, Aug 7, 2008 at 6:59 AM, David Schwartz wrote:


    > >> Otherwise, many random number generators use a
    > >> linear-feedback shift register with a periodicity of 2**56. That's
    > >> approximately the same amount of keyspace as DES, and the output over
    > >> multiple successions of readings of 2**56 bytes will repeat and not be
    > >> suitably random.

    > >
    > > That seems pretty boneheaded to me, considering how trivial it is to

    > create PRNGs with much higher periods. In any event,
    > Linux's /dev/urandom implementation has a periodicity of way over 2^64
    > bytes.
    >
    > Sure, it's possible to create PRNGs with much higher periods, but it's
    > rather difficult to create /good/ PRNGs with much higher periods.
    > Even then, though, all PRNGs have the property that their output is
    > deterministic... and "deterministic" is the antithesis of
    > "cryptographically secure".


    Someone should probably tell that to NIST. So they can fix their
    FIPS-140 standard to allow nondeterministic RNGs.

    --
    Tomas Mraz
    No matter how far down the wrong road you've gone, turn back.
    Turkish proverb

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  16. RE: Couldn't obtain random bytes in sshd - problem in RAND_poll?


    Kyle Hamilton wrote:

    > On Thu, Aug 7, 2008 at 6:59 AM, David Schwartz
    > wrote:


    > > Kyle Hamilton wrote:


    > >> If the pool is seeded once, the "randomness" will be random for as
    > >> long as the amount of entropy in the seed holds out. After this, the
    > >> numbers generated won't really be random.


    > > Right, but they will be cryptogrpahically secure. Forever.


    > Uh, no.


    Uh, yes.

    > If you seed it with 1 bit of entropy, then there's only 2**1
    > possible output chains.


    You cannot "seed it with 1 bit of entropy".

    > Entropy is observation of chaos, which is
    > supposed to make all possible values of the entropy pool equally
    > possible -- and the less entropy you stir in, the more likely it is
    > that someone who figures out what's come before is going to be able to
    > figure out what's going to come in the future.


    What you are claiming can happen -- that the /dev/urandom pool can produce cryptographically-secure random numbers but then run out of entropy -- is impossible. It cannot happen. If you could seed the pool with 1 bit of entropy, it would never produce any cryptographically-secure random numbers. If you seeded it with 64-bytes of entropy, it would produce an effectively unlimited amount of cryptographically-secure random number, well in excess of 2^64 bytes.

    This is not an accident or artifact. This is the specific design intention of the implementation. It's as assured by the implementation as RSA assures that its operations are irreversible.

    > >> The only way to guarantee that your numbers are truly
    > >> cryptographically secure is to use /dev/random and deal with the fact
    > >> that it will block until there's been enough entropy seeded into the
    > >> randomness pool.

    > >
    > > Nope. That does not "guarantee" that the numbers are truly

    > cryptogrpahically secure. There could be a bug in the /dev/random
    > implementation. A cosmic ray may cause the PRNG software to be bypassed.
    > >
    > > If you get to argue that there might be a weakness in the PRNG

    > algorithm such that it does not generate cryptogrpahically-secure
    > numbers even if it was seeded, then I get to argue that there
    > might be a weakness in your RNG alogorithm.


    > Technically, if you want to absolutely guarantee that you have truly
    > cryptographically secure numbers you should perform thermodynamic
    > analysis of case air-flows, or measure the periodicity of the release
    > of electrons or photons from radioactive nuclei, or directly measure
    > other phenomena that are nondeterministic. The /dev/random
    > implementation measures as much of the nondeterministic phenomena as
    > is possible in a typical computer system, and uses that to seed the
    > random number generator.


    > /dev/random and /dev/urandom have historically shared the same
    > implementation. The difference is that /dev/random blocks when it has
    > calculated that its entropy pool is exhausted, and /dev/urandom does
    > not.


    Right. So /dev/random tries to provide truly random numbers while /dev/urandom tries to provide only cryptographically-secure pseudo-random numbers.

    > >> Otherwise, many random number generators use a
    > >> linear-feedback shift register with a periodicity of 2**56. That's
    > >> approximately the same amount of keyspace as DES, and the output over
    > >> multiple successions of readings of 2**56 bytes will repeat and not be
    > >> suitably random.

    > >
    > > That seems pretty boneheaded to me, considering how trivial it

    > is to create PRNGs with much higher periods. In any event,
    > Linux's /dev/urandom implementation has a periodicity of way over
    > 2^64 bytes.


    > Sure, it's possible to create PRNGs with much higher periods, but it's
    > rather difficult to create /good/ PRNGs with much higher periods.
    > Even then, though, all PRNGs have the property that their output is
    > deterministic... and "deterministic" is the antithesis of
    > "cryptographically secure".


    No, it is not. Deterministic is the antithesis of truly random. Deterministic is entirely compatible with cryptographically secure.

    Non-deterministic processes are one way to produce cryptographically-secure random numbers, but it is not the only way. It's like a one-time pad, it is easy to prove that it works and is secure, but is not always the best in practice. If you don't use it, you risk theoretical vulernabilities, but you choose mature, well-researched algorithms to mitigate that risk.

    > >> (If an attacker can figure out the state of your
    > >> PRNG, the attacker can figure out your next-generated "secret"
    > >> randomness. This is why the Debian debacle was so serious, and why
    > >> only a few thousand possible keys were generated by the vulnerable
    > >> implementations -- the randomness wasn't.)

    > >
    > > The whole point of the design of Linux's /dev/urandom

    > implementation is that if it was ever seeded, no matter how much
    > output you have made, an attacher can never determine the state
    > of your PRNG. This was an explicit design goal.


    > The whole point of cryptosystem implementation is so that if the key
    > is properly kept secret, no matter how much material is encrypted
    > under the key, an attacker can never determine the key or the
    > plaintext. This is an explicit design goal.


    > Of course, no cryptosystem has ever been found to have an unknown
    > weakness or buggy implementation, right?


    That is the risk of every system. If all you're trying to say is that /dev/urandom has the same risks as every other cryptograhic implementation of every algorithm, then fine. But you are inventing some special "run out of entropy" risk. There is no such special risk. It's the same as the risk that someone might find a faster way to factor primes is a risk for RSA.

    That is, the implementation is carefully designed and tested to control this well-understood risk. It is not some vulnerability that normal users of the algorithm need to worry about, except in the same sense that they worry about prime factoring with RSA. (For example, with RSA, you need to constantly evaluate whether your key size is still appropriate.)

    > >> I'd certainly like to see references to the contrary, if they exist --
    > >> my references are the Handbook of Applied Cryptography and Applied
    > >> Cryptography 2nd Ed.

    > >
    > > Linux's /dev/urandom implementation was specifically made such

    > that if it was ever seeded, no amount of known output would
    > compromise the state of the PRNG.
    > >
    > > So long as it is initially seeded, the only risk is that the

    > algorithm has some unknown weakness or bug.


    > I'll vote "unknown weakness". Give me /dev/random and blockage any
    > day, and/or have me seed the PRNG with the timing of my keystrokes (a
    > la PGP 2.x) or mouse-cursor movements (a la PGP 5.x+), or something
    > else.


    Fine, but then make clear that your argument is not about any known vulnerabilities, but a specific claim that the algorithm might not actually meet its design goals.

    > Entropy is really the only way to protect against PRNG bugs. And it's
    > also really the only way to work around the deterministic nature of
    > the PRNG.
    >
    > -Kyle H


    This really is comparable to the view that no public-key encryption algorithm should ever be trusted. In principle, every such algorithm can be reversed. It's almost equivalent to the view that only a one-time pad should be used as an encryption algorithm, but not quite, as there is often no way to use a one-time pad and there is rarely no way to get sufficient true randomness.

    In case you don't have a good idea how the /dev/urandom PRNG works, it's roughly like this:

    1) There's a pool of entropy. It's way too large to brute force.

    2) That pool is iterated with a LFSR type algorithm with a ludicrously high period. It would take the known age of the universe to get it to repeat.

    3) A secure hash algorithm runs over the pool after each iteration. The output of the secure hash algorithm is much smaller than the size of the pool. Some of the output of this secure hash algorithm is used as the output random number.

    Provided the input seed is sufficient, any attacker who tries to attack this algorithm, regardless of the amount of output he had or how long the algorithm has run (assuming much less than its period, of course) must exploit some weakness in the secure hash algorithm. The secure hash algorithm used is SHA1, which is as well-studied as almost any other cryptogrpahic algorithm, and it has no known (or even suspected, AFAIK) relevant weaknesses.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  17. Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?

    David Schwartz wrote:

    > Deterministic is the antithesis of truly random.


    You've said some truly stupid things, David, but that one
    wins the prize.


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  18. RE: Couldn't obtain random bytes in sshd - problem in RAND_poll?


    > David Schwartz wrote:


    > > Deterministic is the antithesis of truly random.


    > You've said some truly stupid things, David, but that one
    > wins the prize.


    Do you know of a way that an algorithmic process can produce more truly random output than it has truly random input? Or do disagree with my claim that an algorithmic process can produce an very large amount of cryptographically-strong random output with a small amount of truly random input?

    I'm waiting to be enlightened. I will also bow to your superior name-calling skillz.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  19. David is off to the entropy store to get some fresh entropy

    David Schwartz wrote:

    >>> Deterministic is the antithesis of truly random.


    I think you're obliged to define what you mean by "truly random" --
    maybe even think about it before using such terms.

    Most processes that generate "random" noise don't usually have
    an nice, equiprobable, Poisson distribution. So what's "truly"
    random? I don't think you know. I'm not sure about your
    understanding of deterministic, either.

    Is the latched output of a free-running oscillator and a clock
    "truly" random? Thermal noise? Radioactive decay?

    The distinction you make, with ill-defined and poorly understood
    terms, is specious. Among the mind-blowingly stupid things you've
    said in this thread:

    So /dev/random tries to provide truly random numbers while
    /dev/urandom tries to provide only cryptographically-secure
    pseudo-random numbers

    It's as assured by the implementation as RSA assures that
    its operations are irreversible.

    Well, these statements are false. I leave it up to you to decide
    whether such utterances are, on their face, stupid.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  20. RE: David is off to the entropy store to get some fresh entropy


    Michael Sierchio wrote:

    > David Schwartz wrote:
    >
    > >>> Deterministic is the antithesis of truly random.

    >
    > I think you're obliged to define what you mean by "truly random" --
    > maybe even think about it before using such terms.


    It's a well-understood term in the art. Understanding the distinction between truly random, pseudo-random, predictable, and so on is the price of admission to have a meaningful opinion on RNGs and PRNGs as used in cyrptography.

    > Most processes that generate "random" noise don't usually have
    > an nice, equiprobable, Poisson distribution.


    Of course. Not all random strings contain as much entropy as their length would make possible.

    > So what's "truly"
    > random? I don't think you know.


    Sure, I can tell you if "7" is random or not. But that doesn't mean I don't understand the term as it is used in this field. In fact, I do.

    http://random.org/analysis/
    http://world.std.com/~cme/html/randomness.html

    > I'm not sure about your
    > understanding of deterministic, either.


    A deterministic process is one whose output is solely dependent on its input. That is, it follows a precise sequence of steps in a precise order such that it will always produce the same output from the same input.

    PRNGs are deterministic in this sense. For the same input, they will always produce the same output stream. If you assume an attacker knows their input and their algorithm, they cannot be used to provide cyptographically-secure random numbers.

    > Is the latched output of a free-running oscillator and a clock
    > "truly" random? Thermal noise? Radioactive decay?


    All of these thins are believed to contain at least some truly random output if constructed properly. Do you think I need to know more than everyone else about these esoteric issues which have no relevance to what I was saying?

    > The distinction you make, with ill-defined and poorly understood
    > terms, is specious. Among the mind-blowingly stupid things you've
    > said in this thread:


    In fact, it's the same distinction everyone else in this field makes.

    > So /dev/random tries to provide truly random numbers while
    > /dev/urandom tries to provide only cryptographically-secure
    > pseudo-random numbers


    This is, in fact, precisely correct. The man page says:

    When read, the /dev/random device will only return random bytes within
    the estimated number of bits of noise in the entropy pool. /dev/random
    should be suitable for uses that need very high quality randomness such
    as one-time pad or key generation. When the entropy pool is empty,
    reads from /dev/random will block until additional environmental noise
    is gathered.

    -and-

    A read from the /dev/urandom device will not block waiting for more
    entropy. As a result, if there is not sufficient entropy in the
    entropy pool, the returned values are theoretically vulnerable to a
    cryptographic attack on the algorithms used by the driver. Knowledge
    of how to do this is not available in the current non-classified liter-
    ature, but it is theoretically possible that such an attack may exist.
    If this is a concern in your application, use /dev/random instead.

    If you think this is different from what I said, you're going to have to explain why you think that. Because you are completely wrong.

    > It's as assured by the implementation as RSA assures that
    > its operations are irreversible.


    > Well, these statements are false. I leave it up to you to decide
    > whether such utterances are, on their face, stupid.


    I anxiously await your argument. In fact, the statement above that begins "Knowledge of how to do this" is making precisely the same point I am.

    If you don't know anything about an entire field, the least you can do is keep your mouth shut.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread
Page 1 of 3 1 2 3 LastLast