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 this to be
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
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 certainly
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
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
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
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 things
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
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
that
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_thresh so
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 group
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
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 support
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
considered.
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 offers
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
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 follow
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
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 I
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 for
On Sun, 27 Aug 2000 00:42:59 -0500, Adam Back [EMAIL PROTECTED] 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
21 matches
Mail list logo
