On Mon, 4 Oct 2010 13:33:00 +0200
Janne Johansson icepic...@gmail.com wrote:
2010/10/4 Kevin Chadwick ma1l1i...@yahoo.co.uk
I do love all this considerations. Just wondering by on earth entropy
doesn't get much attention in a world where people seems so worried
about security and
On Thu, 30 Sep 2010 11:37:14 +0200
Daniel Gracia lists.d...@electronicagracia.com wrote:
I do love all this considerations. Just wondering by on earth entropy
doesn't get much attention in a world where people seems so worried
about security and privacy.
Do you mean the world in general or
2010/10/4 Kevin Chadwick ma1l1i...@yahoo.co.uk
I do love all this considerations. Just wondering by on earth entropy
doesn't get much attention in a world where people seems so worried
about security and privacy.
Do you mean the world in general or the OpenBSD world.
I presume you've
I do love all this considerations. Just wondering by on earth entropy
doesn't get much attention in a world where people seems so worried
about security and privacy.
Have you ever used any specific method to measure the randomness quality
of the numbers generated by the kernel when randomness
Kevin Chadwick writes:
First I'd ask how well can anyone prove that the NIST statistical test
suite can reliably judge randomness?
It can't; it can only weed out weak generators but could not distinguish
an entropic generator from, say, MD5. See
http://lcamtuf.coredump.cx/soft/stompy.tgz for
Then of course the tiiiny tiiiny problem of defining in code how to
_prove_ that the input
is random. Proving some input is skewed in one of 123 ways is easy and
relatively fast,
but proving that the input data will never fail a statistical test is..
Hard.
If a situation is possible where a
2010/10/4 Kevin Chadwick ma1l1i...@yahoo.co.uk
Then of course the tiiiny tiiiny problem of defining in code how to
_prove_ that the input
is random. Proving some input is skewed in one of 123 ways is easy and
relatively fast,
but proving that the input data will never fail a statistical test
Janne Johansson wrote:
What I meant was that one can complain of that the NIST programs (diehard
and
dieharder springs to mind) only do certain tests, but that is just because
noone
can make a short program that _proves_ a certain stream is random. The only
thing available seems to be a
2010/10/4 Brad Tilley b...@16systems.com
Janne Johansson wrote:
What I meant was that one can complain of that the NIST programs (diehard
and
dieharder springs to mind) only do certain tests,
Check out ent (it's in ports) it does chi-square, entropy, and a few
other tests to grade
Janne Johansson wrote:
List of the CURRENT fully implemented tests (as of the 08/18/08 snapshot):
#=#
# dieharder version 3.29.4beta Copyright 2003 Robert G. Brown
#
-d 1 Diehard OPERM5 Test Suspect
-d 14Diehard Sums TestDo Not Use
And from the site:
Note that a few tests appear to have stubborn bugs. In particular,
the diehard operm5 test seems to fail all
On Wed, 29 Sep 2010 13:02:41 -0400
Ted Unangst ted.unan...@gmail.com wrote:
On Wed, Sep 29, 2010 at 12:49 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk
wrote:
And isn't srandom sometimes (very rarely!) appropriate? E.g. for
generating encryption keys?
If arandom is somehow not appropriate for
On Wed, 29 Sep 2010 11:16:53 -0600
Theo de Raadt dera...@cvs.openbsd.org wrote:
It is more efficient. There is almost always enough entropy for
arandom, and if there isn't, you would have a hard time detecting
that.
There is always enough. The generator will keep moving, until it has
On Fri, Oct 01, 2010 at 10:45:30AM +0200, Massimo Lusetti wrote:
On Wed, 29 Sep 2010 Theo de Raadt dera...@cvs.openbsd.org wrote:
[Ted Unangst wrote: -- Joachim Schipper]
[/dev/arandom] is more efficient. There is almost always enough entropy
for
arandom, and if there isn't, you
Hello,
I'm trying to use /dev/srandom, but I can't get even a single byte out
of it.
To reproduce:
$ hexdump -n 1 /dev/srandom
It just hangs there, sleeping. If I use /dev/urandom instead, it returns
immediately, as expected:
$ hexdump -n 1 /dev/urandom
000 0069
001
I tried on
it is hanging because:
23208 hexdump CALL read(0,0x81ffc000,0x1)
It is trying to read too much. A whole buffer, into stdio.
So it empties the pool it can have, and then has to wait for more.
eventually it does get data, and print 1 char.
I am susprised that hexdump doesn't decide to
On 2010-09-29 10:36, Theo de Raadt wrote:
it is hanging because:
23208 hexdump CALL read(0,0x81ffc000,0x1)
It is trying to read too much. A whole buffer, into stdio.
So it empties the pool it can have, and then has to wait for more.
eventually it does get data, and print 1 char.
On Wed, Sep 29, 2010 at 09:57:53AM -0400, Simon Perreault wrote:
I'm trying to use /dev/srandom, but I can't get even a single byte out
of it.
$ hexdump -n 1 /dev/srandom
It just hangs there, sleeping. If I use /dev/urandom instead, it returns
immediately, as expected:
$ hexdump -n 1
it is hanging because:
23208 hexdump CALL read(0,0x81ffc000,0x1)
It is trying to read too much. A whole buffer, into stdio.
So it empties the pool it can have, and then has to wait for more.
eventually it does get data, and print 1 char.
Thanks! I was using the much
On 2010-09-29 10:49, Theo de Raadt wrote:
Perhaps a posix weenie can look into making hexdump use setvbuf and
adjusting the read requirements for fread() when the length (-n
argument) is specified as being short of the blocksize.
How about this weenie?
Index: display.c
On Wed, Sep 29, 2010 at 9:57 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
I'm trying to use /dev/srandom, but I can't get even a single byte out
of it.
Independent of other problems, I don't think you should be using
srandom. We should just take that interface away, people see it and
On Wed, Sep 29, 2010 at 9:57 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
I'm trying to use /dev/srandom, but I can't get even a single byte out
of it.
Independent of other problems, I don't think you should be using
srandom. We should just take that interface away, people see
On Wed, Sep 29, 2010 at 09:39:06AM -0600, Theo de Raadt wrote:
On Wed, Sep 29, 2010 at 9:57 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
I'm trying to use /dev/srandom, but I can't get even a single byte out
of it.
Independent of other problems, I don't think you should be
On Wed, Sep 29, 2010 at 09:39:06AM -0600, Theo de Raadt wrote:
On Wed, Sep 29, 2010 at 9:57 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
I'm trying to use /dev/srandom, but I can't get even a single byte out
of it.
Independent of other problems, I don't think you
On Wed, 29 Sep 2010 10:02:16 -0600
Theo de Raadt dera...@cvs.openbsd.org wrote:
And isn't srandom sometimes (very rarely!) appropriate? E.g. for
generating encryption keys?
hell no!
srandom is definately worse than the arc4random generator.
oh, but linux people told you it was the
On Wed, Sep 29, 2010 at 12:49 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
And isn't srandom sometimes (very rarely!) appropriate? E.g. for
generating encryption keys?
If arandom is somehow not appropriate for generating keys, it should
be fixed. I'd be interested to hear more.
I notice
On Wed, Sep 29, 2010 at 11:39 AM, Theo de Raadt dera...@cvs.openbsd.org
wrote:
Independent of other problems, I don't think you should be using
srandom. We should just take that interface away, people see it and
then they want to use it, but it doesn't work the way they want.
Taking it away
On Wed, Sep 29, 2010 at 11:39 AM, Theo de Raadt dera...@cvs.openbsd.org w=
rote:
Independent of other problems, I don't think you should be using
srandom. =A0We should just take that interface away, people see it and
then they want to use it, but it doesn't work the way they want.
On Wed, Sep 29, 2010 at 12:49 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk
wrote:
And isn't srandom sometimes (very rarely!) appropriate? E.g. for
generating encryption keys?
If arandom is somehow not appropriate for generating keys, it should
be fixed. I'd be interested to hear more.
29 matches
Mail list logo