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 ; David Schwartz wrote: > I'm waiting to be enlightened. I will also bow to your superior name-calling skillz. If I were to call you a name, no more suitable term of insult may be found than "David Schwartz", which serves ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 42

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

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

    David Schwartz wrote:

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


    If I were to call you a name, no more suitable term of insult may be found
    than "David Schwartz", which serves as a summary of your swearing up-and-down
    that SSLv3 is vulnerable to a MITM attack, that RSA is irreversible, and
    that /dev/random "tries" to emit "truly" random numbers.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: David is off to the entropy store to get some fresh entropy

    David Schwartz wrote:

    > It's a well-understood term in the art.


    You are not a practitioner of the art, David. There are RBGs and
    PRBGs but no one uses the term "truly random".

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


    No. We know what cryptographically useful random bitstreams are.

    >> 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:
    >

    Um, no mention of "truly" random. Ted T'so will chime in here...

    > 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.


    But you said it was "cryptographically secure" (not a term of art, btw).

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


    Good idea, David. You've demonstrated a depth of ignorance that
    is truly profound. Time to shut up. I noticed you skipped right over
    my citing your claim that RSA is irreversible.



    __________________________________________________ ____________________
    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?

    David Schwartz wrote:

    > 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?


    Yes. A small amount of random input might mean that the
    entire state -- past, present and future -- of the PRNG
    can be known by guessing the initial input.

    Back to school, David, back to school.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


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


    Michael Sierchio wrote:

    > No. We know what cryptographically useful random bitstreams are.

    [snip]
    > But you said it was "cryptographically secure" (not a term of art, btw).


    Umm, yes, "cryptographically secure" is a term of art. It means that a hypothetical attacker with a specific set of information (generally everything but the seed) cannot predict the output using any mechanism significantly more efficient than brute force.

    In any event, I'm curious. What do you think it is that makes bitstreams cryptographically useful? Could it be that they're secure?

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


    > Um, no mention of "truly" random. Ted T'so will chime in here...


    Apparently you don't understand the relationship between true randomness and entropy.

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


    > Good idea, David. You've demonstrated a depth of ignorance that
    > is truly profound. Time to shut up. I noticed you skipped right over
    > my citing your claim that RSA is irreversible.


    RSA is reversible. I never claimed otherwise. What I said is: "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."

    This is precisely correct. In both cases, the operations are possible in theory but impossible in practice -- by careful and deliberate design.

    In principle, with no new entropy input, a person with enough output from /dev/urandom could predict the next output byte by brute forcing every possible initial seed state and finding the (likely only) one that produce that output stream. This is exactly the same as reversing RSA -- possible in theory but practical implementations are careful to make this impractical because it's a well-understood risk.

    See if you can find anyone who knows anything about this field who agrees with you. I would be quite stunned.

    DS


    __________________________________________________ ____________________
    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?


    Micahel Sierchio:

    > David Schwartz wrote:
    >
    > > 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?

    >
    > Yes. A small amount of random input might mean that the
    > entire state -- past, present and future -- of the PRNG
    > can be known by guessing the initial input.
    >
    > Back to school, David, back to school.


    There is no conceivable response to this other than to point and laugh. I cannot believe that you can honestly think that's an appropriate response and still be able to form complete sentences.

    You might want to talk to Ted T'so or someone else quick while you might still have some credibility left.

    DS


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


  6. Re: David is off to the entropy store to get some fresh entropy

    David Schwartz wrote:

    > RSA is reversible. I never claimed otherwise. What I said is: "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."
    >
    > This is precisely correct. In both cases, the operations are possible in theory but impossible in practice -- by careful and deliberate design.



    David, we count on RSA being reversible, that's how it's designed. One-way
    hash functions are presumably irreversible. Your "knowledge" of cryptography
    hasn't improved, you should go home now.
    __________________________________________________ ____________________
    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?


    Are you or are you not the same David Schwartz who claimed that SSLv3 is
    vulnerable to MITM? If so, what have you learned since then?
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  8. Re: David is off to the entropy store to get some fresh entropy

    David Schwartz wrote:

    > Apparently you don't understand the relationship between true randomness and entropy.


    I don't know what you mean when you say "true randomness" and I suspect
    that you don't.

    When you use the word entropy in this context, I assume you mean Shannon
    entropy, and I'm pretty sure you don't have an adequate understanding
    of that either.



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


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


    > David Schwartz wrote:


    > RSA is reversible. I never claimed otherwise. What I said is:
    > "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."


    > > This is precisely correct. In both cases, the operations are
    > > possible in theory but impossible in practice -- by careful and
    > > deliberate design.


    > David, we count on RSA being reversible, that's how it's
    > designed.


    No, we count on it being (for practical purposes) irreversible. That's why you need a different key to decrypt than you used to encrypt. If it was reversible, like say DES, you could decrypt with the same key you encrypted with by simply reversing the process.

    In principle, you could reverse RSA. You could simply try every possible input (and every possible padding if random padding is used) and find the one that can produce the encrypted output. There are other ways to reverse RSA, but they are all impossible in principle.

    There are two possibilities:

    1) You didn't understand what I meant.

    2) You understood what I meant but chose to pretend you didn't.

    It really looks, at least to me, like '2'. So this is you being rude, not dumb.

    > One-way
    > hash functions are presumably irreversible.


    True, but not relevent.

    > Your "knowledge" of
    > cryptography
    > hasn't improved, you should go home now.


    At some point, somebody with much more patience than me will explain to you that you haven't any idea what you're talking about. My patient for correcting your lack of understanding and dealing with your intentional offensiveness is running out.

    I'm going to try not to respond to your for a few hours in the hopes that some such person will explain these things such that you can understand them.

    DS


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


  10. Re: David is off to the entropy store to get some fresh entropy

    David Schwartz wrote:

    > No, we count on it [RSA] being (for practical purposes) irreversible. That's why you need a different key to decrypt than you used to encrypt. If it was reversible, like say DES, you could decrypt with the same key you encrypted with by simply reversing the process.


    You are truly clueless. Encryption and decryption make RSA reversible. Plonk.


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


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


    > David Schwartz wrote:
    >
    > > No, we count on it [RSA] being (for practical purposes)

    > irreversible. That's why you need a different key to decrypt than
    > you used to encrypt. If it was reversible, like say DES, you
    > could decrypt with the same key you encrypted with by simply
    > reversing the process.


    > You are truly clueless. Encryption and decryption make RSA
    > reversible. Plonk.


    There are two possibilities:

    1) You didn't understand what I meant.

    2) You understood what I meant but chose to pretend you didn't.

    It really looks, at least to me, like '2'. So this is you being rude, not dumb.

    DS


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


  12. Re: David is off to the entropy store to get some fresh entropy

    Mr. Michael,

    I am surprised the rude way u write in a public forum. U don't know how to
    remain
    a professional, maintain decency and to disagree with someone, all
    simultaneously.
    Dear Moderator, I would suggest to unsubscribe this person from the list.

    Michael, u need more training in communication and then probably in
    technology.
    Get back to me if u need any help. I can suggest u some good places to
    school
    u properly. And, don't be a shameless and start writing here. Others are
    already
    laughing at you.


    --Chaks


    On Sat, Aug 9, 2008 at 1:44 PM, David Schwartz wrote:

    >
    > > David Schwartz wrote:
    > >
    > > > No, we count on it [RSA] being (for practical purposes)

    > > irreversible. That's why you need a different key to decrypt than
    > > you used to encrypt. If it was reversible, like say DES, you
    > > could decrypt with the same key you encrypted with by simply
    > > reversing the process.

    >
    > > You are truly clueless. Encryption and decryption make RSA
    > > reversible. Plonk.

    >
    > There are two possibilities:
    >
    > 1) You didn't understand what I meant.
    >
    > 2) You understood what I meant but chose to pretend you didn't.
    >
    > It really looks, at least to me, like '2'. So this is you being rude, not
    > dumb.
    >
    > DS
    >
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



  13. Re: David is off to the entropy store to get some fresh entropy

    biswatosh chakraborty wrote:

    > Michael, u need more training in communication and then probably in
    > technology.


    I'm extremely impatient with the use of ill-defined terms
    by the less-than-well informed when they pretend to speak
    with authority. Schwartz has committed a number of bald
    assertions over the years that are simply untrue (cf. the
    thread some time ago wrt SSLv3 being vulnerable to MITM),
    and others (such as the repeated invocation of "truly random")
    which serve only to mislead the earnest but naive reader.

    The Humpty Dumpty school of rhetoric ("when I use a word,
    it means what I want it to mean") is not appropriate to
    a technical forum, would you not agree?

    Go and ponder before responding, I'm trying to keep my
    killfile down to a manageable number. ;-)

    - M

    __________________________________________________ ____________________
    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?


    Michael Sierchio wrote:

    > Are you or are you not the same David Schwartz who claimed that SSLv3 is
    > vulnerable to MITM? If so, what have you learned since then?


    If a browser has a maliciously-included root certificate placed there by an attacker and is using a SOCKS proxy also controlled by an attacker, is it vulnerable to a MITM attack? Is there anything wrong with its SSLv3 implementation? The correct answers are "yes, it's vulnerable to a MITM attack" and "no, it's still doing SSLv3 exactly right".

    SSLv3's protection against a MITM attack in the case of my browser connecting to https://www.amazon.com relies on no MITM having a certificate that my browser will accept as vaild for https://www.amazon.com. (Otherwise, he can successfully interpose himself in the SSL connection and decrypt all the data passed and re-encrypt it for the other end.)

    SSLv3 itself cannot assure me of the nonexistence of an attacker with such a certificate. Yet that nonexistence is part of my assurance that I'm immune to MITM attacks.

    If you're talking about this post:

    http://www.mail-archive.com/openssl-.../msg32016.html

    The key excerpt from that post is this:

    "The MITM can run separate SSL sessions to both the server and the client
    and proxy the plaintext between the two connections. That's well within the
    scope of what a MITM can do.

    SSLv3 only provides protection against a MITM attack if one of two things
    is the case:

    1) The end that cares about authentication (the client for HTTPS) compares
    the name in the certificate against the name of the server it wants to talk
    to, OR

    2) Only trusted parties have access to certificates signed by any CA the
    end that cares about authentication trusts.

    The Internet security model employs option 1. Without it, there would be no
    protection whatsoever from a MITM who closes both SSL sessions and proxies
    the plaintext."

    And it is very important that people who use OpenSSL understand this.

    SSLv3's protection against a MITM attack when your custom program conneects to some other custom program relies on you designing the scheme such that some equivalent guarantee exists. SSLv3 can't provide that guarantee all by itself.

    SSLv3 provides a mechanism to protect against MITM attacks. It's up to the program using it to take advantage of that mechanism. You can't say "I use SSLv3 so I'm invulnerable to MITM attacks", but you can say, "I use SSLv3 as part of a comprehensive security scheme that prevents MITM attacks".

    See, for example:
    http://www.pburkholder.com/sysadmin/SSL-mitm/index.php

    DS


    __________________________________________________ ____________________
    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?

    > If a browser has a maliciously-included root certificate placed
    > there by an attacker and ...


    I'm not aware of any definition of MITM that includes compromising any
    part of an endpoint. Could you point to one?

    /r$

    --
    STSM, DataPower Chief Programmer
    WebSphere DataPower SOA Appliances
    http://www.ibm.com/software/integration/datapower/

    __________________________________________________ ____________________
    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?


    Richard Salz wrote:

    > > If a browser has a maliciously-included root certificate placed
    > > there by an attacker and ...


    > I'm not aware of any definition of MITM that includes compromising any
    > part of an endpoint. Could you point to one?
    >
    > /r$


    I didn't say you are vulnerable to a MITM attack that compromises the
    endpoint. I said that if the endpoint is compromised, you are vulnerable to
    MITM attacks. The attacker need not compromise the endpoint himself. He may
    discover that a poorly-designed endpoint (even though it implement SSL
    perfectly) is in fact compromised.

    What I'm saying is that you can't say "I use SSLv3, so I don't have to
    worry about a MITM attack". While SSLv3 provides the tools to prevent MITM
    attacks, it doesn't -- by itself -- prevent them. Users of OpenSSL and SSLv3
    must understand that they have to use SSL correctly or SSL's ability to
    protect against MITM attacks will do them no good.

    SSLv3 provides a certificate system that can protect you against MITM
    attacks. However, it is up to the SSLv3 user to use that system, as part of
    a public key infrastructure or some other way, to actually get the
    protection.

    This is a rehash of an old argument, but my whole point is that if you're
    implementing SSL in a custom application with custom clients and servers,
    you *do* have to worry about MITM attacks. You can't say, "I use SSL, so I
    don't have to worry about MITM attacks".

    All you have to do is fail to properly check the endpoint certificate, and
    you are vulnerable to MITM attacks. This is so even though your
    implementation of the SSL protocol is flawless.

    It is possible to implement SSLv3, the protocol, perfectly, and still
    accidentally produce a compromised endpoint that is vulnerable to a MITM
    attack.

    So you can say "I use SSLv3 as part of a comprehensive system including a
    public key infrastructure to validate endpoints and thereby protect against
    MITM attacks". The Internet's CA system is part of just such a system. CAs
    (or some equivalent) are needed because SSLv3 can't do it by itself.

    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?

    On Sun, Aug 10, 2008 at 07:28:30PM -0700, David Schwartz wrote:
    > I didn't say you are vulnerable to a MITM attack that compromises the
    > endpoint. I said that if the endpoint is compromised, you are vulnerable to
    > MITM attacks. The attacker need not compromise the endpoint himself. He may
    > discover that a poorly-designed endpoint (even though it implement SSL
    > perfectly) is in fact compromised.


    At this point, you've just spent reams and reams of electrons stating
    the obvious. If the endpoint is compromised, no protocol is going to
    help you. This is true regardless of whether you are talking about
    SSLv3, or Kerberos (if I have a copy of your server's keytab file, I
    can forge arbitrary tickets), or IPSec (for any public key system, if
    I can insert an untrustworthy CA certificate, it's all over), and so
    on.

    This is about as much of a tautology as shouting from the rooftops
    that "the sky is blue" or "2+2=4". If you find this to be an insight
    worthy of note, it says much more about *you* than of the protocol or
    anyone on this list...

    As the old saying goes, "better to be silent, and thought to be a
    fool, and to speak, and remove all doubt."

    - Ted
    __________________________________________________ ____________________
    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?

    Theodore Tso wrote:

    > As the old saying goes, "better to be silent, and thought to be a
    > fool, and to speak, and remove all doubt."


    "Well," Brahma said, "even after ten thousand explanations, a fool is no
    wiser, but an intelligent man requires only two thousand five hundred."

    Normally, I am fine with people believing all manner of silly things,
    but not when they offer advice to others.

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


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


    Ted T'so wrote:

    > At this point, you've just spent reams and reams of electrons stating
    > the obvious.


    Yes, for the second time, because some people *still* don't understand it.
    (It's quite obvious to you and me, not so obvious to the people who still
    don't get it.)

    > If the endpoint is compromised, no protocol is going to
    > help you. This is true regardless of whether you are talking about
    > SSLv3, or Kerberos (if I have a copy of your server's keytab file, I
    > can forge arbitrary tickets), or IPSec (for any public key system, if
    > I can insert an untrustworthy CA certificate, it's all over), and so
    > on.


    Exactly. So you can't say "my project uses SSLv3, so I don't have to worry
    about MITM attacks". You have to say "my project uses SSLv3, and I have made
    sure there are no problems is the *way* I used SSLv3 that might result in my
    endpoint being 'compromised be design'."

    > This is about as much of a tautology as shouting from the rooftops
    > that "the sky is blue" or "2+2=4". If you find this to be an insight
    > worthy of note, it says much more about *you* than of the protocol or
    > anyone on this list...


    Then think about how wrong the people disagreeing with me must be!

    I hardly consider it an insight worthy of note. I simply repeat it for the
    benefit of those who keep saying things like "if you use SSLv3, you don't
    have to worry about MITM attacks". Because these people do in fact sometimes
    produces what you and I would consider compromised hosts.

    > As the old saying goes, "better to be silent, and thought to be a
    > fool, and to speak, and remove all doubt."


    Tell that to the people who are disagreeing with me.

    Unfortunately, there are real people who are using OpenSSL to implement a
    communications scheme who think they are immune to MITM attacks because
    people keep telling them that SSLv3 is immune to MITM attacks. In fact, it
    provides you the tools to stop a MITM attack, but you can very easily use it
    in a naive way such that you are vulnerable to MITM attacks.

    I recognize that this is completely obvious to all people who understand
    even a small amount about cryptography. However, it is fact learned from
    experience that people who don't understand even a small amount of
    cryptogaphy sometimes implement it.

    If you trace the history of my original comment on this, it was in response
    to just such a person.
    http://www.mail-archive.com/openssl-.../msg31875.html

    DS


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


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


    Michael Sierchio wrote:

    > Theodore Tso wrote:
    >
    > > As the old saying goes, "better to be silent, and thought to be a
    > > fool, and to speak, and remove all doubt."

    >
    > "Well," Brahma said, "even after ten thousand explanations, a fool is no
    > wiser, but an intelligent man requires only two thousand five hundred."
    >
    > Normally, I am fine with people believing all manner of silly things,
    > but not when they offer advice to others.


    Umm, Ted said this about what I was saying:

    This is about as much of a tautology as shouting from the rooftops
    that "the sky is blue" or "2+2=4". If you find this to be an insight
    worthy of note, it says much more about *you* than of the protocol or
    anyone on this list...

    In other words, he said that what I was saying was obviously correct. You were *disagreeing* with me, saying I was incorrect. In other words, you were arguing that the sky is not blue, or that two plus two is not four. So who is the fool?

    DS


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


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