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
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
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
Stanislav Meduna wrote:
Am I seeing ghosts? Anyone got other mysterious
problems with current UML kernel? Could it be that
some state-saving method is corrupting fp registers
or something like that? Was there some change in the
UML / vanilla kernel recently?
Confirmed: I can reproduce openssl
Richard Salz wrote:
Your test is wrong. NaN != NaN.
My test is right. Please, look into the code and the previous
discussion. The whole point of the test is that the x0/x1 are
mysteriously changed from outside of the process.
The test will run indefinitely (well until precision
suffices)
On 11.08.2011 21:33, Vegard Nossum wrote:
I've written a small program that gathers randomness from the
uncertainty of scheduling between threads/cores in a multithreaded
program/system.
Hmm my gut feeling is that this is not random enough that it matters.
The OS schedulers are actually quite
On 13.08.2011 10:09, Kyle Hamilton wrote:
See also http://egd.sourceforge.net/ (Entropy Gathering Daemon, written
in perl)
EGD is meant for systems where the /dev/random is not
present/accessible.
Assuming the /dev/random takes the entropy from all sources
affecting the scheduling of
On 14.01.2012 17:34, Andy Polyakov wrote:
Comments on http://www.openssl.org/~appro/OPENSSL_instrument_bus/ are
welcomed.
I did not analyse the architecture of tested processors to check
how many frequencies they are using and how they are generating
them, but isn't this just manifestation of
On 16.01.2012 10:30, Andy Polyakov wrote:
Are you aware of any quantitative PLL characteristics that can be
relevant in the context? Can *you* argue in favor of the hypothesis?
It's essential that somebody else but me argues to confirm or dismiss it.
Unfortunately I lack the math needed to do
On 17.01.2012 16:52, Andy Polyakov wrote:
Maybe relevant question is not how [in]predictable is PLL's reaction on
input frequency variation, but that there is one. I mean even if PLL
reaction is predictable, *when* [thermal] variation and consequent
reaction occurs is not, right?
Right, if
On 17.01.2012 21:52, Andy Polyakov wrote:
Out of curiosity: Does the picture change if you are running the test
hardware in a refrigerator at -20 degrees celsius and at say
40 degrees? ;)
Do *you* keep your systems in fridge? If so, how do you deal with
condensate when you take them out
On 17.01.2012 22:47, Andy Polyakov wrote:
Come on, having me preparing bootable CF card image for a gizmo I'm not
familiar with is unrealistic. Don't you have anything you can compile
10-lines C code and some assembler to add to?
Well you mentioned tests on x86 in your paper, I thought you
do
On 17.01.2012 23:55, Peter Waltenberg wrote:
I think my point is valid though - even if it is a PRNG, provided it's a
good one (and distribution will tell you that) if an attacker can't tell
exactly when you are sampling the PRNG effectively it's a usable entropy
source.
One of the problems
On 18.02.2012 17:02, Edward Ned Harvey wrote:
So these studies went out and scoured the internet, collecting public keys
from every service they could find, which amounts to something like 1-2
million servers, and they scanned them all for identical keys and/or shared
factors. They found
On 18.02.2012 22:47, Edward Ned Harvey wrote:
Any link to the studies? - I was not able to find anything relevant.
Is this related to the 2008 Debian OpenSSL snafu?
Not the debian thing.
http://arstechnica.com/business/news/2012/02/crypto-shocker-four-of-every-10
16 matches
Mail list logo
