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
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 thousand five
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 so
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 key. The
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
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
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
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 vulnerable
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
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 with
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
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 to
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 somewhat incorrect
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 keyspace as
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 won't really be
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
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 with
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 future
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
entire
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
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
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
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
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 amount
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
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
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
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 got
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
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 ideas?
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
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
32 matches
Mail list logo
