> > -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 gen
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
> #
> #=
2010/10/4 Brad Tilley
> 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 the data s
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
2010/10/4 Kevin Chadwick
> >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..
> >Har
>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
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
2010/10/4 Kevin Chadwick
> > 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 read the OpenB
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
On Thu, 30 Sep 2010 11:37:14 +0200
Daniel Gracia 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 the OpenBSD world.
I presume
On Mon, 4 Oct 2010 13:33:00 +0200
Janne Johansson wrote:
> 2010/10/4 Kevin Chadwick
>
> > > 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 w
On Wed, 29 Sep 2010 13:02:41 -0400
Ted Unangst wrote:
> On Wed, Sep 29, 2010 at 12:49 PM, Kevin Chadwick
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
On Fri, Oct 01, 2010 at 10:45:30AM +0200, Massimo Lusetti wrote:
> On Wed, 29 Sep 2010 Theo de Raadt 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 would have a ha
On Wed, 29 Sep 2010 11:16:53 -0600
Theo de Raadt 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 Wed, Sep 29, 2010 at 12:49 PM, Kevin Chadwick
> 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.
For those
> On Wed, Sep 29, 2010 at 11:39 AM, Theo de Raadt 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.
> >
> > Taking it awa
On Wed, Sep 29, 2010 at 11:39 AM, Theo de Raadt
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 would first requ
On Wed, Sep 29, 2010 at 12:49 PM, Kevin Chadwick 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 arandom doesn'
On Wed, 29 Sep 2010 10:02:16 -0600
Theo de Raadt 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 best. I get it
> 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
> > > 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
> > 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
> > sra
> On Wed, Sep 29, 2010 at 9:57 AM, Simon Perreault
> 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
> then they
On Wed, Sep 29, 2010 at 9:57 AM, Simon Perreault
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
then they want to use it,
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
=
> > 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
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:
>
> $ hexdum
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
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 rea
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 various
29 matches
Mail list logo
