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
Hi experts,
According to the code in apps/dgst.c, command dgst should have an option
-hmac, which means use HMAC algorithm. For openssl-0.9.8g, the code is from
line 193 to line 198.However, I can not find the usage of -hmac option either
in man-page or in the usage-prompt printed when user
On Sun, 18 May 2008 11:53:35 pm Stephen Henson via RT wrote:
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
May as well do the documentation too - guess attached.
Looking for other missing undocumented
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
Hi,
This is not a joke. Please clean up ssleay_rand_bytes:
- do not mix the PID into the internal entropy pool, and
- do not mix bits of the given output buffer into the internal entropy pool.
This will help detecting weaknesses in the rng itself as well as in
software that depends on this
On Mon, May 19, 2008 at 11:57 PM, Richard Stoughton [EMAIL PROTECTED] wrote:
- do not mix the PID into the internal entropy pool, and
The OpenSSL PRNG uses the PID twice:
Once it is used as part of the intitial seeding on Unix machines, to
get some data that might provide a little actual
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
18 matches
Mail list logo
