On Tue, May 20, 2008 at 10:43:27PM -0700, dean gaudet wrote:
> the so-called "uninitialized" data is actually from the stack right? an
> attacker generally controls that (i.e. earlier use of the stack probably
> includes char buf[] which is controllable). i don't know what ordering
> the entro
Date: 05/21/2008 07:57 PM
Subject:Re: valgrind and openssl
Peter Waltenb
Peter Waltenberg wrote:
Think back to what tripped this whole discussion.
valgrind isn't complaining because the data has been pre-filled, it's
complaining because it's never been touched.
i.e if it were attacker providable "buffer contents" then this whole
discussion wouldn't have happened.
If
Date: 05/21/2008 03:44 PM
On Tue, 20 May 2008, Richard Salz wrote:
> > on the other hand it may be a known plaintext attack.
>
> Using those words in this context makes it sound that you not only don't
> understand what is being discussed right here and now, but also that you
> don't understand the term you just used. A
On Monday 19 May 2008 15:27:24 dean gaudet wrote:
> > 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 t
> on the other hand it may be a known plaintext attack.
Using those words in this context makes it sound that you not only don't
understand what is being discussed right here and now, but also that you
don't understand the term you just used. Are you sure you understood,
e.g., Ted Tso's posting
> on the other hand it may be a known plaintext attack.
>
> what are you guys smoking?
>
> -dean
This argument has already been refuted in the posts you are replying to.
Such an "attack" would require the algorithm to not meet its specific design
security objectives. In other words, you are argu
> > You mean you're not testing *all* of the real code. That's
> > fine, you can't
> > debug everythign at once.
> if you haven't tested your final production binary then you
> haven't tested
> anything at all.
You: Two plus two is five.
Me: Are you crazy? Two plus two is not five.
You: If you
On Mon, May 19, 2008 at 10:48 PM, dean gaudet <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 15 May 2008, Bodo Moeller wrote:
>
>> On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
>> <[EMAIL PROTECTED]> wrote:
>> > Goetz Babin-Ebell wrote:
>>
>> >> But here the use of this uninitialized data is inte
>> 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, t
On Mon, 19 May 2008, David Schwartz wrote:
>
> > 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.
if you haven't tested your final production binary then yo
On Thu, 15 May 2008, Bodo Moeller wrote:
> On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
> <[EMAIL PROTECTED]> 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 u
> 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.
Fortu
> 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
dean gaudet wrote:
On Thu, 15 May 2008, Geoff Thorpe wrote:
I forgot to mention something;
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.
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
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 L
On Mon, May 19, 2008 at 6:30 PM, Thor Lancelot Simon <[EMAIL PROTECTED]> 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
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 ho
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
On Mon, May 19, 2008 at 6:00 AM, Michael Sierchio <[EMAIL PROTECTED]> 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
enssl-dev@openssl.org
Date: 05/19/2008 05:24 PM
Subject:Re:
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
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 fi
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
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 n
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
Hi,
> > 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 cas
> > 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
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 m
> 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
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 includ
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
On Fri, May 16, 2008 at 6:47 AM, Thor Lancelot Simon <[EMAIL PROTECTED]> 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
>> <[EMAIL PROTECTED]> wrote:
>> > Goetz Babin-Ebell wrote:
>> >> But here the use of this uninit
Bodo Moeller wrote:
> However, another intentional use of potentially unitialized data is
> still left as of
> http://cvs.openssl.org/getfile/openssl/crypto/rand/randfile.c?v=1.47.2.2
> :
>
> i=fread(buf,1,n,in);
> if (i <= 0) break;
> /* even if n != i, us
On Thu, May 15, 2008 at 06:17:03PM -0400, Geoff Thorpe wrote:
> On Thursday 15 May 2008 17:31:45 Erik de Castro Lopo wrote:
> > Geoff Thorpe wrote:
> > > Then tell your linux distribution to use -DPURIFY.
> >
> > Hangon, I've got a better idea. How about the OpenSSL develoeprs
> > fix their library
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
> <[EMAIL PROTECTED]> 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
Hi,
> It certainly would, but Valgrind isn't the only analysis tool people
> might want to use. A runtime flag provides a means of obtaining accurate
> results with any tool.
Unfortunately, for am attacker it also provides a means of (possibly)
weakening your program's randomness behind y
On Fri, May 16, 2008 at 12:39 AM, David Schwartz <[EMAIL PROTECTED]> wrote:
> 2) Zeroing memory that doesn't need to be zeroed has a performance cost.
This particular argument doesn't actually apply here. We wouldn't
have to zeroize any memory, we just wouldn't feed those bytes that are
not know
On Thursday 15 May 2008 17:31:45 Erik de Castro Lopo wrote:
> Geoff Thorpe wrote:
> > Then tell your linux distribution to use -DPURIFY.
>
> Hangon, I've got a better idea. How about the OpenSSL develoeprs
> fix their library so that the standard version that they ship is
> valgrind clean. Then the
> Everybody?
>
> It seems to me that only one or two people who don't really
> understand what's going on are complaining.
Wanting to get accurate runtime analysis results with a release build is
not an unreasonable request.
> OpenSSL should stay as it is. A contributed valgrind
> suppressi
> Would a runtime flag for "don't seed with uninitialized memory", rather
> than (or in addition to) -DPURIFY, satisfy everybody?
>
> John
I don't think it's necessary, since compiling with '-DPURIFY' is so
ridiculously easy, but I have no objection to it. An evironment variable
would probably be
> Would a runtime flag for "don't seed with uninitialized memory", rather
> than (or in addition to) -DPURIFY, satisfy everybody?
Everybody?
It seems to me that only one or two people who don't really understand
what's going on are complaining.
OpenSSL should stay as it is. A contributed valgri
> In the practice of engineering, we should try to avoid 'hoping'
> about anything.
Don't know much about cryptography, do you?
/r$
--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
Would a runtime flag for "don't seed with uninitialized memory", rather
than (or in addition to) -DPURIFY, satisfy everybody?
John
__
OpenSSL Project http://www.openssl.org
Development Mailing List
> David Schwartz wrote:
>
> > Umm, why?
> >
> > 1) This is an unusual use case.
> This is not an unusual case. I'm a developer and I valgrind my
> code all the time because fixing problems shown up by valgrind
> makes my code better.
I didn't say it was an unusual use case for you. It's an unusu
David Schwartz wrote:
> Umm, why?
>
> 1) This is an unusual use case.
This is not an unusual case. I'm a developer and I valgrind my
code all the time because fixing problems shown up by valgrind
makes my code better.
My code is targeting an embedded Linux box and I try to ensure
that the syste
Bodo Moeller wrote:
> We don't care if anyone can force this to be predictable, because
> we're in no way relying on it to deliver more than zero bits of
> entropy.
So it might end up being zero just by chance right?
> We're just hoping there might be some entropy in there
> sometimes.
In the
> Geoff Thorpe wrote:
>
> > Then tell your linux distribution to use -DPURIFY.
>
> Hangon, I've got a better idea. How about the OpenSSL develoeprs
> fix their library so that the standard version that they ship is
> valgrind clean. Then the distributions won't need to do anything
> other than com
On Thu, May 15, 2008 at 11:51 PM, Erik de Castro Lopo
<[EMAIL PROTECTED]> wrote:
> 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
On Thu, May 15, 2008 at 4:41 PM, Erik de Castro Lopo
<[EMAIL PROTECTED]> 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
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.
Do you know i
On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo
<[EMAIL PROTECTED]> 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
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.
The only sane way to deal with this it t
Geoff Thorpe wrote:
> Then tell your linux distribution to use -DPURIFY.
Hangon, I've got a better idea. How about the OpenSSL develoeprs
fix their library so that the standard version that they ship is
valgrind clean. Then the distributions won't need to do anything
other than compile it.
Erik
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik de Castro Lopo schrieb:
| Theodore Tso wrote:
|
|> On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote:
|>> What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the
|>> default, but wouldn't reduce the keyspace either.
|> -DPURIF
On Thursday 15 May 2008 16:56:17 Erik de Castro Lopo wrote:
> Patrick Patterson wrote:
> > On May 15, 2008 10:58:07 am John Parker wrote:
> > > In the wake of the issues with Debian, is it possible to modify the
> > > source so that it is possible to use valgrind with openssl without
> > > reducing
Patrick Patterson wrote:
> On May 15, 2008 10:58:07 am John Parker wrote:
> > In the wake of the issues with Debian, is it possible to modify the
> > source so that it is possible to use valgrind with openssl without
> > reducing the key space?
> >
> It is already possible to use openssl and valgr
Theodore Tso wrote:
> On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote:
> > > change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer
> > > intention, so that debug packages (or even base packages that want to be
> > > valgrind-friendly) have a straightforward mechanis
On Thu, May 15, 2008 at 12:29 PM, Geoff Thorpe <[EMAIL PROTECTED]> 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.
>> >
On Thu, May 15, 2008 at 7:53 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote:
>> What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the
>> default, but wouldn't reduce the keyspace either.
>
> -DPURIFY *does* do what you want. I
John Parker wrote:
change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer
intention, so that debug packages (or even base packages that want to be
valgrind-friendly) have a straightforward mechanism to apply. Well, a
straightforward mechanism that doesn't kill the PRNG outright
On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote:
> > change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer
> > intention, so that debug packages (or even base packages that want to be
> > valgrind-friendly) have a straightforward mechanism to apply. Well, a
> > strai
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
John Parker, 2008-05-15:
> >> > 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
> red
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
On May 15, 2008 12:38:24 pm 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 valgr
>> > 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.
>> > (we do it all
> All of this is independent of proper entropy seeding to the PRNG, which is
> what the debian patch crushed and which in turn led to the high seismic
> reading in the blogosphere. But it may help explain why I do *not* want us to
> unilaterally remove the use of uninitialised data in the PRNG. Tha
On Thursday 15 May 2008 11:52:08 John Parker wrote:
> > It is already possible to use openssl and valgrind - just build OpenSSL
> > with -DPURIFY, and it is quite clean.
> >
> > (we do it all the time here with WvStreams and Pathfinder, and it works
> > like a charm).
>
> The problem is that this m
> It is already possible to use openssl and valgrind - just build OpenSSL
> with -DPURIFY, and it is quite clean.
>
> (we do it all the time here with WvStreams and Pathfinder, and it works like a
> charm).
The problem is that this may reduce the keyspace so that keys are guessable.
http://blog.i
Patrick Patterson <[EMAIL PROTECTED]> writes:
> On May 15, 2008 10:58:07 am John Parker wrote:
>> In the wake of the issues with Debian, is it possible to modify the
>> source so that it is possible to use valgrind with openssl without
>> reducing the key space?
>>
> It is already possible to use
Just to follow up on Bodo's comment here;
On Thursday 15 May 2008 11:11:50 Bodo Moeller wrote:
> > Are we really relying on uninitialized memory for randomness?
>
> Not at all. It's just that OpenSSL in some situations tries to feed
> possibly uninitialized memory into the random number generator
On May 15, 2008 10:58:07 am John Parker wrote:
> In the wake of the issues with Debian, is it possible to modify the
> source so that it is possible to use valgrind with openssl without
> reducing the key space?
>
It is already possible to use openssl and valgrind - just build OpenSSL
with -DPURIF
On Thu, May 15, 2008 at 4:58 PM, John Parker <[EMAIL PROTECTED]> wrote:
> In the wake of the issues with Debian, is it possible to modify the
> source so that it is possible to use valgrind with openssl without
> reducing the key space?
Sure. This might happen with the next release.
> Are we re
76 matches
Mail list logo
