> > I posted code and results a while back to freebsd-arch which sampled the
> > sound card from userland and analysed the shannon entropy of the noise
> > (for the record, all but one card I tried gave about 6 bits of entropy or
> > more per 16 bit sample with no recording device plugged in, and
> I posted code and results a while back to freebsd-arch which sampled the
> sound card from userland and analysed the shannon entropy of the noise
> (for the record, all but one card I tried gave about 6 bits of entropy or
> more per 16 bit sample with no recording device plugged in, and maximum
On Fri, 1 Sep 2000, Mark Murray wrote:
> > > PC's are pretty low-entropy devices; users who need lots of random
> > > bits (as opposed to a steady supply of random numbers) are arguably
> > > going to need to go to extraordinary lengths to get them; their
> > > own statistical analysis is almost
Date: Fri, 1 Sep 2000 03:06:28 -0700 (PDT)
From: Kris Kennaway <[EMAIL PROTECTED]>
I claim this to be untrue: my tests show an ordinary sound card (with no
recording source, at maximum input gain) will provide far more
(high-quality) entropy than Yarrow can make use of under even t
> > PC's are pretty low-entropy devices; users who need lots of random
> > bits (as opposed to a steady supply of random numbers) are arguably
> > going to need to go to extraordinary lengths to get them; their
> > own statistical analysis is almost certainly going to be required.
>
> I claim thi
On Sat, 26 Aug 2000, Mark Murray wrote:
> My approach to this (and this is the first time I am stating this in
> such a wide forum) is to provide another device (say /dev/srandom) for
> folk who want to do their own randomness processing. This would provide
> a structure of data including the ent
Ted writes:
> [...]
>
> As far as yarrow versus the current design, I've certainly looked at
> yarrow, and I've certainly considered adding some of yarrow's design
> into my /dev/random implementation. Given that I strongly recommend
> that the 512 bytes of entropy be saved from /dev/random at
Ted writes:
> A couple of comments here. It was always the intention that
> /dev/random be 0666, and in my implementation, writing to
> /dev/random mixed the input into the entropy pool *without* changing
> the entropy estimate.
I see. This is not clear.
We recently set it /dev/random to grou
Adam writes:
>Yes. But the /dev/random device is traditionally crw-r--r-- which
>means user processes can't write to it. So you'd have to be root to
>do that.
>
>What could be done for yarrow is to change the device permissions to
>crw-rw-rw- and mix into a shared user source and set k_of_n_thre
> > That works with what I already have: cat $privatekey > /dev/random :-)
>
> Yes. But the /dev/random device is traditionally crw-r--r-- which
> means user processes can't write to it. So you'd have to be root to
> do that.
I go one further; at close, I do an explicit reseed, and I make sure
Mark Murray wrote:
[...]
> Again, I'm not so sure; Yarrow goes to great trouble to protect its
> internal state; by blocking, I have this very nasty suspicion that
> this carefully guarded state is being disclosed. The moment you block,
> you are confiding in the fact that you have no updating ent
Mark writes:
> Adam writes:
> > OK, I agree that that's an area where yarrow offers better protection.
> > But it's not like Ted's code is broken or anything. We would break
> > things using /dev/random by switching as is to yarrow, so this is why
> > I don't like it: we're trying to improve thi
> Mark writes:
> > [...]
> > FreeBSD is using an earlier version of T'so's code; I beiieve he
> > improved it later, but it has no (or little) backtracking protection,
> > and can be too easily attacked "from both sides".
>
> OK, I agree that that's an area where yarrow offers better protection.
< said:
> You probably don't want to chose RC6 or MARS because their authors
> will probably patent them if they lose, and then you'll have to back
> off using them fast.
If they were going to be patented, the application has already been
filed, so you might as well assume that they are patented
Jeroen writes:
> > > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256
> > > pseudo 256 bit block cipher Davies-Meyer performance wise, because of
> > > the key agility.
>
> But Twofish is not neccessarily the best choice. Yes, it's being
> pushed by Bruce Schneier but that's
Mark Murray wrote:
[...]
> > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit
> > plaintext with a 256 bit key as a virtual 256 bit block cipher
> > operation. I suspect the result will be weaker than 256 bits because
> > of the internal structure of BF-CBC.
>
> I'm not sure
Mark writes:
> [...]
> FreeBSD is using an earlier version of T'so's code; I beiieve he
> improved it later, but it has no (or little) backtracking protection,
> and can be too easily attacked "from both sides".
OK, I agree that that's an area where yarrow offers better protection.
But it's not
> > OK; what then? The existing MD5 based system is very attackable, and
> > protects itself very poorly.
>
> My argument for linux is leave it as it is, and see if we can persuade
> the yarrow authors to change yarrow so it does export a /dev/random
> compatible API.
If that happened, I'd fol
Mark writes:
> > You really can't use yarrow to implement /dev/random as it is.
> > [...]
>
> OK; what then? The existing MD5 based system is very attackable, and
> protects itself very poorly.
My argument for linux is leave it as it is, and see if we can persuade
the yarrow authors to change
> You really can't use yarrow to implement /dev/random as it is. Even
> waiting for reseeds doesn't cut it. The issue is that everything goes
> through the yarrow output function, which restricts yarrow to offering
> computational security with at worst 2^n work factor to break because
> it offe
Mark writes:
> > I'm hoping to persuade the yarrow designers of the importance of
> > supporting /dev/random semantics for the unix community acceptance.
> > John Kelsey and I had some discussions along the lines of feeding
> > /dev/random output into yarrow, which I notice someone on here
> > co
> We've been implementing yarrow at zeroknowledge also. I just read
> through the freebsed-current archives searching for "yarrow", and I
> share some of the concerns raised by Kris Kennaway:
OK...
> I've been talking with John Kelsey (one of the Yarrow authors) about
> changing yarrow to suppo
[try again this foobared the first time -- apologies for duplicates]
[If this bounces because I am not a list member, could I trouble one
of you to forward it to the list? -- Thanks]
Hi all
We've been implementing yarrow at zeroknowledge also. I just read
through the freebsed-current archives
23 matches
Mail list logo
