Subject:Re: valgrind and openssl
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
Subject:Re: valgrind and openssl
Peter Waltenberg wrote:
Think back to what tripped this whole discussion.
valgrind
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 entropy is
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 don't
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 arguing
Hi there,
Can you please unsubscribe anyone who posts on this subject again.
The participants should long ago have taken this debate off list.
It's degenerated into a discussion without any value whatsoever.
Kind regards
-paul
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
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 this is
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. Are
: 05/19/2008 05:24 PM
Subject:Re: valgrind and openssl
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 be
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
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
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 first 512
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
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
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
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
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.
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 use of
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 you
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
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 intentional
and the
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 case,
in
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
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
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 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
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
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
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
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
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
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 did.
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 so that
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, use the
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 uninitialized data is
./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
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
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?
Are we really relying on uninitialized memory for randomness?
-JP
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 really
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 -DPURIFY
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 openssl
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
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 may reduce
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. That
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
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 valgrind
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
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
reduce
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
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
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
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. It
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.
Actually on my
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 mechanism to
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 valgrind
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 the key
-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.
| -DPURIFY
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
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
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 its
of this random data is close to zero.
The only sane way to deal with this it to either make it zero
or make it truely random.
Erik
I disagree. If there's a performance cost to making openssl happy
with valgrind, I'd rather have there be an option that defaults to
optimize security
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
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.
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
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 system
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 unusual use
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
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?
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 valgrind
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 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
suppressions
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
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 known
76 matches
Mail list logo
