Hello ,
I have problem in understanding and could you clarify for me what is the best
way to extract and safe public and private keys
from generated ES_KEY and then create new key for signature or verify .
Example esdatest.c:
if (!EC_KEY_generate_key(key))
goto
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 and
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.
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 the
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 and
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 the
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
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
that this is the case, but it would certainly make sense to compare
before posting a bug report.
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
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
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
entropy
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
37 matches
Mail list logo
