Kurt Roeckx wrote:
> David,
>
> I think you have a problem of not making clear what you actually mean.
>
> I'm going to give 3 examples of how I could read what you were saying so
> far:
>
> 1. A client connects to a server, but the server has been compromised
>and someone knows it's secret k
On Mon, Aug 11, 2008 at 02:50:55AM -0700, David Schwartz wrote:
>
> Ted T'so wrote:
>
> > At this point, you've just spent reams and reams of electrons stating
> > the obvious.
>
> Yes, for the second time, because some people *still* don't understand it.
> (It's quite obvious to you and me, not
Michael Sierchio wrote:
> Theodore Tso wrote:
>
> > As the old saying goes, "better to be silent, and thought to be a
> > fool, and to speak, and remove all doubt."
>
> "Well," Brahma said, "even after ten thousand explanations, a fool is no
> wiser, but an intelligent man requires only two tho
Ted T'so wrote:
> At this point, you've just spent reams and reams of electrons stating
> the obvious.
Yes, for the second time, because some people *still* don't understand it.
(It's quite obvious to you and me, not so obvious to the people who still
don't get it.)
> If the endpoint is comprom
Theodore Tso wrote:
As the old saying goes, "better to be silent, and thought to be a
fool, and to speak, and remove all doubt."
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent man requires only two thousand five hundred."
Normally, I am fine
On Sun, Aug 10, 2008 at 07:28:30PM -0700, David Schwartz wrote:
> I didn't say you are vulnerable to a MITM attack that compromises the
> endpoint. I said that if the endpoint is compromised, you are vulnerable to
> MITM attacks. The attacker need not compromise the endpoint himself. He may
>
Richard Salz wrote:
> >If a browser has a maliciously-included root certificate placed
> > there by an attacker and ...
> I'm not aware of any definition of MITM that includes compromising any
> part of an endpoint. Could you point to one?
>
> /r$
I didn't say you are vulne
>If a browser has a maliciously-included root certificate placed
> there by an attacker and ...
I'm not aware of any definition of MITM that includes compromising any
part of an endpoint. Could you point to one?
/r$
--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appli
Michael Sierchio wrote:
> Are you or are you not the same David Schwartz who claimed that SSLv3 is
> vulnerable to MITM? If so, what have you learned since then?
If a browser has a maliciously-included root certificate placed there
by an attacker and is using a SOCKS proxy also control
Are you or are you not the same David Schwartz who claimed that SSLv3 is
vulnerable to MITM? If so, what have you learned since then?
__
OpenSSL Project http://www.openssl.org
Development Mailing
Micahel Sierchio:
> David Schwartz wrote:
>
> > do disagree with my claim that an algorithmic process can
> > produce an very large amount of cryptographically-strong
> > random output with a small amount of truly random input?
>
> Yes. A small amount of random input might mean that the
> e
David Schwartz wrote:
> do disagree with my claim that an algorithmic process can
> produce an very large amount of cryptographically-strong
> random output with a small amount of truly random input?
Yes. A small amount of random input might mean that the
entire state -- past, present and futur
David Schwartz wrote:
I'm waiting to be enlightened. I will also bow to your superior name-calling
skillz.
If I were to call you a name, no more suitable term of insult may be found
than "David Schwartz", which serves as a summary of your swearing up-and-down
that SSLv3 is vulnerable to a MIT
> David Schwartz wrote:
> > Deterministic is the antithesis of truly random.
> You've said some truly stupid things, David, but that one
> wins the prize.
Do you know of a way that an algorithmic process can produce more truly random
output than it has truly random input? Or do disagree wi
David Schwartz wrote:
Deterministic is the antithesis of truly random.
You've said some truly stupid things, David, but that one
wins the prize.
__
OpenSSL Project http://www.openssl.org
Deve
Kyle Hamilton wrote:
> On Thu, Aug 7, 2008 at 6:59 AM, David Schwartz
> <[EMAIL PROTECTED]> wrote:
> > Kyle Hamilton wrote:
> >> If the pool is seeded once, the "randomness" will be random for as
> >> long as the amount of entropy in the seed holds out. After this, the
> >> numbers generated
On Fri, 2008-08-08 at 02:52 -0700, Kyle Hamilton wrote:
> On Thu, Aug 7, 2008 at 6:59 AM, David Schwartz <[EMAIL PROTECTED]> wrote:
> >> Otherwise, many random number generators use a
> >> linear-feedback shift register with a periodicity of 2**56. That's
> >> approximately the same amount of key
On Thu, Aug 7, 2008 at 6:59 AM, David Schwartz <[EMAIL PROTECTED]> wrote:
>
> Kyle Hamilton wrote:
>
>> David S: to my knowledge you're at least somewhat incorrect, and part
>> of your advice is rather dangerous to rely upon (from a cryptographic
>> theory perspective).
>
> You are at least somewha
I'm sorry -- my comment was to David Schwartz (I realized both of you
were named David, but failed to realize that you also had a surname
that started with S).
-Kyle H
On Thu, Aug 7, 2008 at 11:44 AM, David Shambroom <[EMAIL PROTECTED]> wrote:
> Kyle,
>
> I didn't say that /dev/urandom was safe t
Kyle,
I didn't say that /dev/urandom was safe to use for cryptographic
purposes. It isn't, and I didn't then and don't now advise its use. I
said it never blocks. It doesn't. So what was incorrect?
Kyle Hamilton wrote:
David S: to my knowledge you're at least somewhat incorrect, and part
On Thu, Aug 07, 2008 at 02:13:27AM -0700, David Schwartz wrote:
> If so, this doesn't say that /dev/urandom never blocks. It just says that it
> will not block waiting for more entropy. In fact, this paragraph is horribly
> misleading, because it suggests that the worst thing /dev/urandom can do is
Kyle Hamilton wrote:
> David S: to my knowledge you're at least somewhat incorrect, and part
> of your advice is rather dangerous to rely upon (from a cryptographic
> theory perspective).
You are at least somewhat incorrect too.
> And yes, it is possible to "run out" the entropy pool. The amo
David S: to my knowledge you're at least somewhat incorrect, and part
of your advice is rather dangerous to rely upon (from a cryptographic
theory perspective).
/dev/urandom will never, under normal circumstances, block -- its
output is generated algorithmically by the random/urandom device
driver
David Shambroom wrote:
> You're right: You are completely wrong. /dev/urandom never blocks.
> See the man page.
Is this is the excerpt from the man page you are referring to?
A read from the /dev/urandom device will not block waiting for
more
entropy. As a result, if there
On Wed, 6 Aug 2008, Stanislav Meduna wrote:
> So what should the applications calling openssl actually
> do if this happens? Now the ssh/apache/... simply exit,
> which is bad (it left me without an access to a remote
> box...).
Exiting is the best behaviour - continuing without a good source
of
You're right: You are completely wrong. /dev/urandom never blocks.
See the man page.
David Schwartz wrote:
Tried many many times, even two running at the same time
or poll timeout set to zero, not one instance of blocking
even with
od -x /dev/urandom
and
od -x /dev/random
running simu
> David Schwartz wrote:
> > Try launching your test program automatically on boot up at the
> > saem time
> > you launch ssh or whatever application is failing. I bet
> > '/dev/urandom' will
> > fail then.
> The program had no problems running with simultaneous
> od -x /dev/random, that was bloc
David Schwartz wrote:
Try launching your test program automatically on boot up at the saem time
you launch ssh or whatever application is failing. I bet '/dev/urandom' will
fail then.
The program had no problems running with simultaneous
od -x /dev/random, that was blocking because it sucked
a
> Tried many many times, even two running at the same time
> or poll timeout set to zero, not one instance of blocking
> even with
>od -x /dev/urandom
> and
>od -x /dev/random
> running simultaneously (the second one blocks, of course).
>
>
> H.. what the #$%# is happening here.. more
Tomas Mraz wrote:
errno has garbage value - this should be fixed by initializing errno to
0 before the poll/select calls.
Actually after it returns with timeout - a successfull
syscall is free to set errno to whatever value it wants,
it is only after an error the value has to be meaningful
(I
On Wed, 2008-08-06 at 11:08 +0200, Stanislav Meduna wrote:
> Hi,
>
> I and a few other users are seeing sshd failing with
>Couldn't obtain random bytes (error 604389476)
> and other ssl-related application failing randomly
> in user mode linux guests and I suspect a problem
> in openssl that g
Stanislav Meduna wrote:
- add
r = -1;
inside the do loop after the int try_read = 0;
Erm, actually I mean
r = -1;
errno = EAGAIN;
or something like that - it has to let the while know
that the poll timed out.
--
Stano
___
Hi,
I and a few other users are seeing sshd failing with
Couldn't obtain random bytes (error 604389476)
and other ssl-related application failing randomly
in user mode linux guests and I suspect a problem
in openssl that got triggered by some change in UML.
I reviewed the RAND_poll function in
33 matches
Mail list logo
