> 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
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 en
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 rng
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
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 f
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
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 uninitial
20 matches
Mail list logo
