Martin Mares wrote:
No, the only safe thing the kernel can do is to add NO entropy,
unless explicitly told otherwise.
Ahh, I think I see where I got confused now. I thought you wanted to
save and restore the entropy estimate after a reboot. I was trying to
say that you don't want to/can't d
On 2006-11-28 19:42, Phillip Susi wrote:
> what good does a non root user do by writing to random? If it
> does not increase the entropy estimate, and it may not actually increase
> the entropy, why bother allowing it?
It is not guaranteed to actually increase the entropy, but it might. And
in c
Hello!
> That is exactly my point. Since you can not tell how much randomness is
> in the data you provide, you can not tell the kernel how much to add to
> its entropy estimate. Instead it just has to estimate based on the
> amount of data you provide.
No, the only safe thing the kernel can
Martin Mares wrote:
Yes, but the point is that you cannot tell how much randomness is in the
data you provide.
That is exactly my point. Since you can not tell how much randomness is
in the data you provide, you can not tell the kernel how much to add to
its entropy estimate. Instead it jus
Hello!
> I still don't see how feeding tons of zeros ( or some other carefully
> crafted sequence ) in will not decrease the entropy of the pool ( even
> if it does so in a way that is impossible to predict ), but assuming it
> can't, what good does a non root user do by writing to random?
Eve
Hello!
> You aren't dumping and restoring the entropy pool; you are dumping
> random data generated by the pool, and using that data to stir the new
> entropy pool after the next boot. There is no direct relationship
> between the entropy of the old and new pools. The kernel needs to
> decid
First, please don't remove the Cc: list.
David Wagner wrote:
Sorry, but I disagree with just about everything you wrote in this
message. I'm not committing any logical fallacies. I'm not assuming
it works because it would be a bug if it didn't; I'm just trying to
Nope, I don't think so. If
Martin Mares wrote:
I'm adding entropy, but unless I record the exact amount of entropy when
dumping the pool, I don't know how much I am adding, so using any fixed
number is obviously wrong.
You aren't dumping and restoring the entropy pool; you are dumping
random data generated by the pool,
Hello!
> After a reboot the entropy estimate starts at zero, so if you are adding
> data to the pool from the previous boot, you DO want the estimate to
> increase because you are, in fact, adding entropy.
I'm adding entropy, but unless I record the exact amount of entropy when
dumping the pool
Martin Mares wrote:
More importantly, it should be possible for root to write to /dev/random
_without_ increasing the entropy count, for example when restoring random
pool contents after reboot. In such cases you want the pool to contain
at least some unpredictable data before real entropy arrive
On 2006-11-27 23:52, Kyle Moffett wrote:
> Actually, our current /dev/random implementation is secure even if the
> cryptographic algorithms can be broken under traditional circumstances.
This is far from obvious, and in my opinion incorrect. David explained
this very well in his follow-up. Other
Hello!
> - Whether you automatically bump up the entropy estimate when
> root users write to /dev/random is a design choice where you could
> reasonably go either way. On the one hand, you might want to ensure
> that root has to take some explicit action to allege that it is
> p
Continuing the tangent:
Henrique de Moraes Holschuh wrote:
>On Mon, 27 Nov 2006, Ben Pfaff wrote:
>> [EMAIL PROTECTED] (David Wagner) writes:
>> > Well, if you want to talk about really high-value keys like the scenarios
>> > you mention, you probably shouldn't be using /dev/random, either; you
>
On Mon, 27 Nov 2006, Ben Pfaff wrote:
> [EMAIL PROTECTED] (David Wagner) writes:
> > Well, if you want to talk about really high-value keys like the scenarios
> > you mention, you probably shouldn't be using /dev/random, either; you
> > should be using a hardware security module with a built-in FIP
[EMAIL PROTECTED] (David Wagner) writes:
> Well, if you want to talk about really high-value keys like the scenarios
> you mention, you probably shouldn't be using /dev/random, either; you
> should be using a hardware security module with a built-in FIPS certified
> hardware random number source.
Warning: tangent with little practical relevance follows:
Kyle Moffett wrote:
>Actually, our current /dev/random implementation is secure even if
>the cryptographic algorithms can be broken under traditional
>circumstances.
Maybe. But, I've never seen any careful analysis to support this or
Phillip Susi wrote:
>> I'm mainly wondering why writing stuff to /dev/*random does not change
>> the entropy from zero to at least any low non-zero value...
> I ran into this the other day myself and when I investigated the kernel
> code, I found that writes to /dev/random do accept the data into t
On Nov 27, 2006, at 15:40:16, David Wagner wrote:
Phillip Susi wrote:
David Wagner wrote:
Nope, I don't think so. If they could, that would be a security
hole, but /dev/{,u}random was designed to try to make this
impossible, assuming the cryptographic algorithms are secure.
Actually, our
Phillip Susi wrote:
>David Wagner wrote:
>> Nope, I don't think so. If they could, that would be a security hole,
>> but /dev/{,u}random was designed to try to make this impossible, assuming
>> the cryptographic algorithms are secure.
>>
>> After all, some of the entropy sources come from untrus
David Wagner wrote:
Nope, I don't think so. If they could, that would be a security hole,
but /dev/{,u}random was designed to try to make this impossible, assuming
the cryptographic algorithms are secure.
After all, some of the entropy sources come from untrusted sources and
could be manipulate
Phillip Susi wrote:
>Why are non root users allowed write access in the first place? Can't
>the pollute the entropy pool and thus actually REDUCE the amount of good
>entropy?
Nope, I don't think so. If they could, that would be a security hole,
but /dev/{,u}random was designed to try to make
Chris Friesen wrote:
I believe the idea was that you don't want random users being able to
artificially inflate your entropy count. So the kernel tries to make
use of entropy entered by regular users (by stirring it into the pool)
but it doesn't increase the entropy estimate unless root says i
Gunter Ohrner wrote:
IMHO something really fishy's going on there. If I explicitely write data
into the pool, it shouldd not stay at "zero", from wwhat I understood about
how /dev/*random work.
I'm mainly wondering why writing stuff to /dev/*random does not change the
entropy from zero to a
Phillip Susi wrote:
I ran into this the other day myself and when I investigated the kernel
code, I found that writes to /dev/random do accept the data into the
entropy pool, but do NOT update the entropy estimate. In order to do
that, you have to use a root only ioctl to add the data and upd
> Hornburg:~# cat /proc/sys/kernel/random/entropy_avail
> 0
Please have a look at:
audio-entropyd: http://www.vanheusden.com/aed/
fills the kernel entropy buffer with noise from your audio-card
video-entropyd: http://www.vanheusden.com/ved/
fills the kernel entropy buffer with noise from a video4l
25 matches
Mail list logo
