valgrind and openssl - Openssl

This is a discussion on valgrind and openssl - Openssl ; Bodo Moeller wrote: > However, another intentional use of potentially unitialized data is > still left as of > http://cvs.openssl.org/getfile/opens...e.c?v=1.47.2.2 > : > > i=fread(buf,1,n,in); > if (i > /* even if n != i, use the full array */ ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 74

Thread: valgrind and openssl

  1. Re: valgrind and openssl

    Bodo Moeller wrote:
    > However, another intentional use of potentially unitialized data is
    > still left as of
    > http://cvs.openssl.org/getfile/opens...e.c?v=1.47.2.2
    > :
    >
    > i=fread(buf,1,n,in);
    > if (i <= 0) break;
    > /* even if n != i, use the full array */
    > RAND_add(buf,n,(double)i);
    >
    > Changing this into RAND_add(buf,i,(double)i) should make verification
    > tools happier. Or it could be
    >
    > #ifdef PURIFY
    > RAND_add(buf,i,(double)i);
    > #else
    > RAND_add(buf,n,(double)i);
    > #endif
    >
    > (abusing the "PURIFY" macro with a more general meaning).
    >

    Good catch, patch applied :-)

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


  2. Re: valgrind and openssl

    On Fri, May 16, 2008 at 6:47 AM, Thor Lancelot Simon wrote:
    > On Thu, May 15, 2008 at 11:45:14PM +0200, Bodo Moeller wrote:
    >> On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
    >> wrote:
    >> > Goetz Babin-Ebell wrote:


    >> >> But here the use of this uninitialized data is intentional
    >> >> and the programmer are very well aware of what they did.


    >> > The use of unititialized data in this case is stupid because the
    >> > entropy of this random data is close to zero.


    >> It may be zero, but it may be more, depending on what happened earlier
    >> in the program if the same memory locations have been in use before.
    >> This may very well include data that would be unpredictable to
    >> adversaries -- i.e., entropy; that's the point here.


    > Unfortunately, it may also very well include data that would be
    > highly predictable to adversaries.


    Sure. That's not a problem, though. What happens to the PRNG then is
    not too different from what happens when you use it to output bits
    (except that with RAND_add(), there is no output that might be seen by
    the adversary, so seeding with known data should actually be safer
    than generating output if you're worrying about this kind of things at
    all). The adversary may know something about what is going on, but
    the internal state still remains secret; and the internal state's
    entropy won't be adversely affected more than marginally if at all.
    (Because of the way the internal state is structured, this "stirring"
    achieved even with a fixed input might even be considered a feature to
    improve the distribution of whatever entropy you already have.)

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


  3. Re: valgrind and openssl

    On Thursday 15 May 2008 16:51:55 John Parker wrote:
    > I'm still seeing a lot of errors from valgrind, even with the latest
    > snapshot.
    >
    > 19 15:12 tar xvfz ../openssl-0.9.8-stable-SNAP-20080515.tar.gz
    > 20 15:12 cd openssl-0.9.8-stable-SNAP-20080515/
    > 21 15:12 ls
    > 22 15:12 ./config no-asm -DPURIFY
    > 23 15:12 make
    > 24 15:14 valgrind ./apps/openssl genrsa 1024
    >
    > Please let me know if I'm doing something wrong with this test sequence.
    >
    > The problems occur on Red Hat 5.1 server x86_64. For what it's worth,
    > I don't get errors on (updated Ubuntu 7.10.
    >
    > I do get errors even with Bodo's addition to randfile.c. I'd be happy
    > to post the valgrind output if that would be helpful.


    If this is environment/OS-specific, then it's probably indicative of a libc
    (or valgrind, or gcc) issue with the fixed-in-the-past versions of those
    packages on RH5.1-64bit. If compiling and running the same openssl source on
    a different system doesn't give you problems, that would seem to imply that
    the problem appears and disappears based on elements that vary rather than
    elements that are invariant. :-)

    OTOH, it might just be that the different OSes catch things differently. In
    any case, I don't have (or want) a RH5.1-64bit installation, so you might as
    well post some clippings from your output to give us an idea of what it's
    showing. (If possible, could you please use a snapshot from HEAD for this
    instead of 0.9.8-stable?) TIA.

    Cheers,
    Geoff

    PS: I wonder whether I should be so dismissive of RH5.1 - as far as I know, it
    always generated usable keys ... :-)
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: valgrind and openssl

    On Friday 16 May 2008 00:47:52 Thor Lancelot Simon wrote:
    > On Thu, May 15, 2008 at 11:45:14PM +0200, Bodo Moeller wrote:
    > > It may be zero, but it may be more, depending on what happened earlier
    > > in the program if the same memory locations have been in use before.
    > > This may very well include data that would be unpredictable to
    > > adversaries -- i.e., entropy; that's the point here.

    >
    > Unfortunately, it may also very well include data that would be
    > highly predictable to adversaries.


    If feeding predictable data into a PRNG that was already well seeded with
    unpredictable data produced a weaker PRNG, then you have found a security bug
    in the PRNG and I suggest you publish. (Or put it in a distribution-local
    patch and wait a couple of years...) After all, the PRNG itself is "highly
    predictable to adversaries" - it's open source - so the requirement of the
    PRNG is for it's stirring mechanism to be essentially mononotic w.r.t.
    entropy gained from the input. Any unpredictability in the data you feed it
    should make the PRNG output correspondingly unpredictable - and that should
    not become more predictable (ie. less unpredictable) because you supplement
    the existing unpredictable input with predictable input. That's the point -
    feed whatever you've got into it, and the resulting "randomness" is (roughly)
    as good as the total entropy of your input, no matter how sparse that input's
    entropy was.

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


  5. Re: valgrind and openssl

    On Fri, May 16, 2008 at 11:24:45AM -0400, Geoff Thorpe wrote:
    > On Friday 16 May 2008 00:47:52 Thor Lancelot Simon wrote:
    > > On Thu, May 15, 2008 at 11:45:14PM +0200, Bodo Moeller wrote:
    > > > It may be zero, but it may be more, depending on what happened earlier
    > > > in the program if the same memory locations have been in use before.
    > > > This may very well include data that would be unpredictable to
    > > > adversaries -- i.e., entropy; that's the point here.

    > >
    > > Unfortunately, it may also very well include data that would be
    > > highly predictable to adversaries.

    >
    > If feeding predictable data into a PRNG that was already well seeded with
    > unpredictable data produced a weaker PRNG, then you have found a security bug
    > in the PRNG and I suggest you publish.


    Yeah, I've heard that a few times. However, consider the pathological case,
    in which an adversary manages to introduce N-1 bits of known state into your
    PRNG which has N bits of internal state. Are you comfortable with that? For
    what value M are you comfortable with N - M bits of the state having been
    introduced by the adversary? Why?

    It seems to me that best practice is to not introduce such state if one
    can avoid it, whether one counts it into an entropy estimate or not.

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


  6. RE: valgrind and openssl


    > Unfortunately, it may also very well include data that would be
    > highly predictable to adversaries.


    That doesn't matter.

    > I am aware that this is an area without a lot of good theoretical
    > signposts, but I am just not very comfortable feeding arbitrary
    > amounts of possibly-known data into a PRNG.
    >
    > Thor


    Don't worry about it. One of the specific security objectives of the PRNG is
    that mixing in known data does not degrade the pool. If you don't trust it
    not to get worse with known data being mixed in, then you don't trust it at
    all and you shouldn't use it.

    If you can't trust your selected algorithms to meet their specific security
    objectives, then you can't use those algorithms.

    DS


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


  7. RE: valgrind and openssl


    > > If feeding predictable data into a PRNG that was already well
    > > seeded with
    > > unpredictable data produced a weaker PRNG, then you have found
    > > a security bug
    > > in the PRNG and I suggest you publish.


    > Yeah, I've heard that a few times. However, consider the
    > pathological case,
    > in which an adversary manages to introduce N-1 bits of known
    > state into your
    > PRNG which has N bits of internal state. Are you comfortable
    > with that?


    Yes.

    > For
    > what value M are you comfortable with N - M bits of the state having been
    > introduced by the adversary? Why?


    An attacker can feed an infinite amount of known entropy into the pool. The
    result is that it has as much entropy as it had before he did that.

    > It seems to me that best practice is to not introduce such state if one
    > can avoid it, whether one counts it into an entropy estimate or not.


    Why? Because it's always possible that the algorithm actually has some
    unknown defect that might make this bad? What if the algorithm has some
    unknown defect that doing this fixes? The entropy pool is specifically
    designed, as a major security objective, such that:

    1) An attacker can remove an unlimited amount of entropy from the pool and
    it is still computationally infeasible to know anything about the next byte
    that will come out, and

    2) An attacker can add an unlimited amount of known "entropy" to the pool
    and it is still computationally infeasible to know anything abou the next
    byte that will come, and

    3) An attacker can do both 2 and 3 in any amount in any computation, and the
    pool is still just as secure as it was before he did so.

    These are not accidents. These are the specific design criteria for the
    entropy pool PRNG used and its design specifically reflects these
    objectives.

    If you have any reason or evidence to suspect that any of these is not true,
    please share it. Otherwise, you're just asking us to hope that the
    hypothetical attack this might somehow make us less vulnerable to is more
    significant to the hypothetical attack this might somehow make us more
    vulnerable too. And that would just be your guess.

    DS


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


  8. Re: valgrind and openssl

    Thor Lancelot Simon wrote:

    > ... However, consider the pathological case,
    > in which an adversary manages to introduce N-1 bits of known state into your
    > PRNG which has N bits of internal state. ...


    What you seem not to understand from this discussion is that the
    internal state is a consequence of input that is processed via
    a diffusion mechanism, a cryptographic hash such as SHA1 or MD5
    or something stronger. These change roughly half the bits of
    their output when a single input bit is changed.

    It is not possible to know the state itself without direct inspection
    of structures whose security is obviously essential for useful
    random number generation.

    If your point is that system events are not a good source of
    entropy, I agree.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  9. Re: valgrind and openssl

    On Sun, May 18, 2008 at 08:41:36AM -0700, Michael Sierchio wrote:
    > Thor Lancelot Simon wrote:
    >
    > >... However, consider the pathological case,
    > >in which an adversary manages to introduce N-1 bits of known state into
    > >your
    > >PRNG which has N bits of internal state. ...

    >
    > What you seem not to understand from this discussion is that the
    > internal state is a consequence of input that is processed via
    > a diffusion mechanism, a cryptographic hash such as SHA1 or MD5
    > or something stronger. These change roughly half the bits of
    > their output when a single input bit is changed.


    So you're comfortable with the adversary knowing, let's say, 511 of
    the first 512 bits fed through SHA1? Maybe I haven't been clear enough
    here: I specifically object to introducing easy to know information into
    the PRNG at startup time, though if one is going to feed it in at other
    times because "it can't hurt" and extra iterations of the mixing
    function are thought to be helpful, I can't really see why not feed in
    0xFFFF every 100ms from a timer -- it'd do about as much good.

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


  10. RE: valgrind and openssl


    Thor Lancelot Simon wrote:

    > So you're comfortable with the adversary knowing, let's say, 511 of
    > the first 512 bits fed through SHA1?


    I'm comfortable knowing any number of bits fed into or through the SHA1
    provided there are also sufficient bits he does not know. The issue of how
    many bits he does know is a complete and utter red herring. It doesn't
    matter. All that matters is whether you feed in enough bits he *doesn't*
    know.

    > Maybe I haven't been clear enough
    > here: I specifically object to introducing easy to know information into
    > the PRNG at startup time, though if one is going to feed it in at other
    > times because "it can't hurt" and extra iterations of the mixing
    > function are thought to be helpful, I can't really see why not feed in
    > 0xFFFF every 100ms from a timer -- it'd do about as much good.


    It doesn't hurt at startup time. It doesn't hurt at any time. Mixing in data
    an adversary knows *never* hurts you.

    What hurts you is *not* mixing in enough information the attacker does not
    know.

    You are confusing the issue by focusing on things that are not the problem.

    DS


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


  11. Re: valgrind and openssl

    On Sun, May 18, 2008 at 05:24:51PM -0400, Thor Lancelot Simon wrote:
    > So you're comfortable with the adversary knowing, let's say, 511 of
    > the first 512 bits fed through SHA1?


    *Sigh*.

    Thor, you clearly have no idea how SHA-1 works. In fact, I'd be
    comfortable with an adversary knowing the first megabyte of data fed
    through SHA1, as long as it was followed up by at least 256 bits which
    the adversary *didn't* know.

    Look, SHA-1 works by having a Very Complicated Mixing function that
    takes a state function, and mixes in the input in a one-way fashion,
    in chunks of 64 bytes at a time. The initial state looks like this:

    67452301 efcdab89 98badcfe 10325476 c3d2e1f0

    It doesn't look very random, but that's OK. You have to start
    *somewhere* --- and it's a public value. If you mix in a megabyte of
    known data, it is the equivalent of changing the initial state to
    something else. Effectively, it's another public starting value.

    As long as follow up the megabyte of known data with 256 bits of
    unknown data, you could feed another megabyte of known data, and the
    adversary would have no idea what the internal state of the SHA-1 hash
    function would look like. If this were not true, SHA-1's mixing
    function would be so throughly broken that all use of SHA-1 for
    digital signatures, certificates, etc., would be totally broken.

    So if you don't trust SHA-1 for use in PRNG's, then you shouldn't
    trust SHA-1 for *anything*.

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


  12. Re: valgrind and openssl

    Theodore Tso wrote:

    > ... I'd be
    > comfortable with an adversary knowing the first megabyte of data fed
    > through SHA1, as long as it was followed up by at least 256 bits which
    > the adversary *didn't* know.


    I'd be comfortable with an adversary knowing the first zetabyte of
    data fed though SHA1, as long as it was followed up by at least 256 bits
    which the adversary didn't know. ;-)

    Cheers,

    Michael

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


  13. Re: valgrind and openssl

    It doesn't matter. If you only have one bit of real entropy you are screwed
    - no matter whether 0 or a 10^15 bits of known data are introduced, and if
    it's 10^15 bits of data the attacker can't reliably guess, you are
    definitely better off.

    And, to put this in perspective, given that the uninitialized memory
    contents are likely unknowable off the machine - if Debian had screwed up
    just a little more - and left the uninitialized memory as a source, but
    taken out the real entropy source, (instead of taking out both), would
    Debian users be in better or worse shape now ?.


    Peter




    From: Thor Lancelot Simon

    To: openssl-dev@openssl.org

    Date: 05/19/2008 05:24 PM

    Subject: Re: valgrind and openssl






    On Fri, May 16, 2008 at 11:24:45AM -0400, Geoff Thorpe wrote:
    > On Friday 16 May 2008 00:47:52 Thor Lancelot Simon wrote:
    > > On Thu, May 15, 2008 at 11:45:14PM +0200, Bodo Moeller wrote:
    > > > It may be zero, but it may be more, depending on what happened

    earlier
    > > > in the program if the same memory locations have been in use before.
    > > > This may very well include data that would be unpredictable to
    > > > adversaries -- i.e., entropy; that's the point here.

    > >
    > > Unfortunately, it may also very well include data that would be
    > > highly predictable to adversaries.

    >
    > If feeding predictable data into a PRNG that was already well seeded with


    > unpredictable data produced a weaker PRNG, then you have found a security

    bug
    > in the PRNG and I suggest you publish.


    Yeah, I've heard that a few times. However, consider the pathological
    case,
    in which an adversary manages to introduce N-1 bits of known state into
    your
    PRNG which has N bits of internal state. Are you comfortable with that?
    For
    what value M are you comfortable with N - M bits of the state having been
    introduced by the adversary? Why?

    It seems to me that best practice is to not introduce such state if one
    can avoid it, whether one counts it into an entropy estimate or not.

    Thor
    __________________________________________________ ____________________
    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: valgrind and openssl

    On Mon, May 19, 2008 at 6:00 AM, Michael Sierchio wrote:
    > Theodore Tso wrote:


    >> ... I'd be comfortable with an adversary knowing the first megabyte of data fed
    >> through SHA1, as long as it was followed up by at least 256 bits which
    >> the adversary *didn't* know.


    > I'd be comfortable with an adversary knowing the first zetabyte of
    > data fed though SHA1, as long as it was followed up by at least 256 bits
    > which the adversary didn't know. ;-)


    You are being a few orders of magnitude too optimistic here, though
    .... ;-) A zettabyte would be 2^78 bits (less if you use the standard
    decimal version of "zetta"), but SHA-1 will only handle inputs up to
    2^64 -1 bits.

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


  15. Re: valgrind and openssl

    On Mon, May 19, 2008 at 11:47:07AM +0200, Bodo Moeller wrote:
    > You are being a few orders of magnitude too optimistic here, though
    > ... ;-) A zettabyte would be 2^78 bits (less if you use the standard
    > decimal version of "zetta"), but SHA-1 will only handle inputs up to
    > 2^64 -1 bits.


    That's true only because size of the message in bits is appended to
    the end of the message to prevent the obvious extension attacks.

    (For people who are clueless about how SHA-1 is implemented, the
    message is padded out with a 1 followed by enough 0 bits so the
    message is congruent to 448 mod 512 bits, and then a 64-bit message
    size count, in big-endian format is appended to the message, and the
    message is processed in 16 byte --- 512 bit --- chunks. Yes that
    means that if the message is an exact multiple of 16 bytes, and you
    know the size of the message, the last 16 bytes which is run through
    the compression algorithm is known to the adversary; it will be a 1,
    followed by 447 zero bits, followed by the message size as a 64-bit
    big endian integer. Whoop! Whoop! Danger Will Robinson! Time to
    run in circles and scream about something you know nothing about!!!
    "It must be a NSA conspiracy!")

    Seriously, it would be easy to change the padding scheme to accomodate
    bigger messages, and in fact for a PRNG you don't need to worry about
    extension attacks, since what you are really depending upon is the
    crypto hash function's compression function. With Linux's
    /dev/random, we dispense with message padding completely, since it's
    not necessary given how we are using the hash's compression function.

    So it wouldn't be SHA-1, but with some very minor modifications to
    accomodate a bigger message size count, you could run a zettabyte of
    known data, followed by 256 bits of known data, and the adversary
    would still be screwed. (And if they aren't, it's time to replace
    SHA-1....)

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


  16. Re: valgrind and openssl

    On Sun, May 18, 2008 at 10:07:03PM -0400, Theodore Tso wrote:
    > On Sun, May 18, 2008 at 05:24:51PM -0400, Thor Lancelot Simon wrote:
    > > So you're comfortable with the adversary knowing, let's say, 511 of
    > > the first 512 bits fed through SHA1?

    >
    > *Sigh*.
    >
    > Thor, you clearly have no idea how SHA-1 works. In fact, I'd be
    > comfortable with an adversary knowing the first megabyte of data fed
    > through SHA1, as long as it was followed up by at least 256 bits which
    > the adversary *didn't* know.


    Thanks for the gratuitous insult. I'd be perfectly happy with the case
    you'd be happy with, too, but you took my one bit and turned it into 256.

    What I _wouldn't_ be happy with is a PRNG which has been fed only known
    data, but enough of it at startup that it agrees to provide output to
    the user. There are a terrible lot of these around, and pretending that
    stack contents are random is a great way to accidentally build them.

    Not feeding in data which you have a pretty darned good idea will be
    predictable -- potentially as the first bits in at RNG startup -- is to
    my mind one thing one can should do to avoid the problem.

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


  17. Re: valgrind and openssl

    On Mon, May 19, 2008 at 6:30 PM, Thor Lancelot Simon wrote:
    > On Sun, May 18, 2008 at 10:07:03PM -0400, Theodore Tso wrote:
    >> On Sun, May 18, 2008 at 05:24:51PM -0400, Thor Lancelot Simon wrote:


    >> > So you're comfortable with the adversary knowing, let's say, 511 of
    >> > the first 512 bits fed through SHA1?


    >> *Sigh*.
    >>
    >> Thor, you clearly have no idea how SHA-1 works. In fact, I'd be
    >> comfortable with an adversary knowing the first megabyte of data fed
    >> through SHA1, as long as it was followed up by at least 256 bits which
    >> the adversary *didn't* know.


    > Thanks for the gratuitous insult. I'd be perfectly happy with the case
    > you'd be happy with, too, but you took my one bit and turned it into 256.
    >
    > What I _wouldn't_ be happy with is a PRNG which has been fed only known
    > data, but enough of it at startup that it agrees to provide output to
    > the user. There are a terrible lot of these around, and pretending that
    > stack contents are random is a great way to accidentally build them.
    >
    > Not feeding in data which you have a pretty darned good idea will be
    > predictable -- potentially as the first bits in at RNG startup -- is to
    > my mind one thing one can should do to avoid the problem.


    No-one pretends that stacks contents are random.

    The OpenSSL PRNG tries to keep a tally of how much entropy has been
    added from external sources. I won't generate any output for key
    generation and such until it is happy about this amount of entropy.
    Those stack contents are taken into account with an entropy estimate
    of 0.0, i.e., not at all. Thus, after feeding those 511 known bits to
    the OpenSSL PRNG[*], it would still expect just as much additional
    seeding as before. Your failure scenario has nothing to do with the
    way this PRNG operates.


    ]*] Actually the PRNG won't take fractions of bytes, so make that 512
    bits, or 504.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  18. Re: valgrind and openssl

    On Mon, May 19, 2008 at 12:30:42PM -0400, Thor Lancelot Simon wrote:
    > Thanks for the gratuitous insult. I'd be perfectly happy with the case
    > you'd be happy with, too, but you took my one bit and turned it into 256.


    But your example is NOT what openssl does.

    I recently had similar issue with Linux's /dev/random, where folks
    were similarly confused. You see, the issue that SHA-1 takes its
    input in 512 bits chunks of data. If you are only mixing in 256 bits
    of randomness, the question is what to do with the other 256 bits.
    You could waste CPU time zero'ing out those bits, or you can just
    shrug your shoulders and say, "I don't care". The problem is people
    who don't understand say "OMG!!! Ur using unitializated data!", not
    getting the fact that whole point was to mix in the 256 bits of
    entropy. The other uninitialized bits might add more information
    unknown to the adversary (in which case it helps), or it might not (in
    which case it doesn't matter, because what you're really depending on
    is the 256 bits of entropy from a good entropy source).

    Of course, you could use the argument that it's a bad idea because a
    clueless Debian developer might comment out the call entirely due to
    some misguided notion that using uninitialized data was somehow a
    security problem. Until last week, I would have thought that was a
    silly argument, but apparently there are people that clueless/stupid/
    careless out there....

    - Ted

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


  19. Re: valgrind and openssl

    On Thu, 15 May 2008, Geoff Thorpe wrote:

    > I forgot to mention something;
    >
    > > On Thursday 15 May 2008 12:38:24 John Parker wrote:
    > > > >> > It is already possible to use openssl and valgrind - just build
    > > > >> > OpenSSL with -DPURIFY, and it is quite clean.
    > > >
    > > > Actually on my system, just -DPURIFY doesn't satisfy valgrind. What
    > > > I'm asking for is something that both satisfies valgrind and doesn't
    > > > reduce the keyspace.

    > >
    > > If you're using an up-to-date version of openssl when you see this (ie. a
    > > recent CVS snapshot from our website, even if it's from a stable branch for
    > > compatibility reasons), then please post details. -DPURIFY exists to
    > > facilitate debuggers that don't like reading uninitialised data, so if
    > > that's not the case then please provide details. Note however that there
    > > are a variety of gotchas that allow you to create little leaks if you're
    > > not careful, and valgrind could well be complaining about those instead.

    >
    > Note that you should always build with "no-asm" if you're doing this kind of
    > debug analysis. The assembly optimisations are likely to operate at
    > granularities and in ways that valgrind could easily complain about. I don't
    > know that this is the case, but it would certainly make sense to compare
    > before posting a bug report.


    you know, this is sheer stupidity.

    you're suggesting that testing the no-asm code is a valid way of testing
    the assembly code?

    additionally the suggestion of -DPURIFY as a way of testing the code is
    also completely broken software engineering practice.

    any special case changes for testing means you're not testing the REAL
    CODE.

    for example if you build -DPURIFY then you also won't get notified of
    problems with other PRNG seeds which are supposed to be providing random
    *initialized* data. not to mention that a system compiled that way is
    insecure -- so you either have to link your binaries static (to avoid the
    danger of an insecure shared lib), or set up a chroot for testing.

    in any event YOU'RE NOT TESTING THE REAL CODE. which is to say you're
    wasting your time if you test under any of these conditions.

    openssl should not be relying on uninitialized data for anything. even if
    it doesn't matter from the point of view of the PRNG, it should be pretty
    damn clear it's horrible software engineering practice.

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


  20. RE: valgrind and openssl


    > any special case changes for testing means you're not testing the REAL
    > CODE.


    You mean you're not testing *all* of the real code. That's fine, you can't
    debug everythign at once.

    > for example if you build -DPURIFY then you also won't get notified of
    > problems with other PRNG seeds which are supposed to be providing random
    > *initialized* data. not to mention that a system compiled that way is
    > insecure -- so you either have to link your binaries static (to avoid the
    > danger of an insecure shared lib), or set up a chroot for testing.


    Right, but you know that. So you don't build with -DPURIFY if you care about
    things that it affects. But sometimes you care about other things.

    > in any event YOU'RE NOT TESTING THE REAL CODE. which is to say you're
    > wasting your time if you test under any of these conditions.


    You seem to think that code is one monolithic thing that doesn't consist of
    component parts. In fact, code does consist of component parts, and the code
    your actually testing may be a different component from the one you change
    the compilation flags on.

    > openssl should not be relying on uninitialized data for anything.
    > even if
    > it doesn't matter from the point of view of the PRNG, it should be pretty
    > damn clear it's horrible software engineering practice.


    No, it's not pretty damn clear. The only reason it might be horrible is
    because it makes the code less predictable. But in this case, predictability
    is explicitly undesired. Perhaps you can make a coherent argument why it's
    bad in this particular case, but I doubt it. This is the opposite of the
    typical case.

    > -dean


    Good luck finding people who agree with you. I've been a professional
    software developer for about 18 years and I've worked on debugging with
    hundreds of other developers. I have *never* met anyone who shared your
    view. In fact, it strikes me as sheer craziness.

    It is akin to saying that debuggers should not exist. After all, the release
    program won't run with a debugger, so how can you debug with one?

    Clearly every difference between the test environment and the use
    environment is a trade-off. But being a competent engineer is about making
    rational trade-offs.

    I could go into more detail with real-world examples how following your
    advice above would have turned very simple efforts into Herculean ones, but
    what you're saying is so obviously absurd, I can't see how it could possibly
    be worth the effort.

    DS


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


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