On Tue, 25 Sep 2012 11:36:31 +0200
Mariusz Gromada wrote:
> Here we did some initial testing, mainly based on charts, which showed
> typical noise in time. But again, it requires a formal proof.
When you say formal proof lets be clear that you aren't actually
proving anything about entropy.
Ent
W dniu 2012-09-25 11:05, Ben Laurie pisze:
I created dummy driver which was registering three dummy drivers, so it
was provoking three device_attach() calls on every kldload. Mariusz
verified the observations and there was no correlation between the
times.
Sorry to those that are bored, but ..
Pawel Jakub Dawidek writes:
> "Dag-Erling Smørgrav" writes:
> > (I don't even need PXE - they'll probably boot faster from USB
> > sticks or disks)
> And probably more reliable. My netbooted test machines occasionally
> don't boot and you don't want to find out in the morning that the whole
> pro
On Tue, Sep 25, 2012 at 12:58:37PM +0200, Dag-Erling Smørgrav wrote:
> Pawel Jakub Dawidek writes:
> > Note that this fake data is the hardest to gather entropy from, as it
> > doesn't interact with any external hardware. I'm all for testing it on
> > real hardware and I expect to be able to gathe
Hi,
Please review this patch [1] which allows unprivileged users call
mlock()/munlock() and mlockall()/munlockall().
AFAIK, these calls were not allowed for every-one because accounting for
mlockall(MCL_FUTURE) was not implemented.
[1] http://people.freebsd.org/~zont/patches/mlock3.patch
--
An
>
>
> You cannot conclude that - no test can tell you it, but this test
> rather obviously does not, since what it tests is the equality of
> probability distributions, so what you can now say is that the
> distribution is square. A completely predictable sequence, say 0..63,
> would satisfy that.
2012/9/25 Mariusz Gromada
>
> Empirically, it seems to me that these numbers are actually unlikely
>> to be correlated with each other, but that has not been tested.
>>
>
>
> Another yes, you are right. We need much more data to check if we have a
> stochastic process consisted of independent rand
Pawel Jakub Dawidek writes:
> Note that this fake data is the hardest to gather entropy from, as it
> doesn't interact with any external hardware. I'm all for testing it on
> real hardware and I expect to be able to gather even more entropy from
> it (so discarding less than top 7 bits). The probl
On Tue, Sep 25, 2012 at 11:28:13AM +0200, Dag-Erling Smørgrav wrote:
> Ben Laurie writes:
> > Not that I dislike Pawel's approach, it seems promising, I'm just
> > pointing out the weakness of the analysis.
>
> It is also based on fake data.
>
> If you give me a couple of days, I'll try to come
Ben Laurie writes:
> Not that I dislike Pawel's approach, it seems promising, I'm just
> pointing out the weakness of the analysis.
It is also based on fake data.
If you give me a couple of days, I'll try to come up with a patch that
collects and stores attach times during boot so we can gather
On Tue, Sep 25, 2012 at 6:32 AM, Pawel Jakub Dawidek wrote:
> On Tue, Sep 25, 2012 at 12:10:13AM +0200, Mariusz Gromada wrote:
>> W dniu 2012-09-24 23:56, Mariusz Gromada pisze:
>>
>> > Ok, finally I have some formal results. To be completely honest I need
>> > to point out that, in fact, we have
On Mon, Sep 24, 2012 at 10:56 PM, Mariusz Gromada
wrote:
> W dniu 2012-09-23 17:17, Pawel Jakub Dawidek pisze:
>
>> On Sun, Sep 23, 2012 at 02:37:48AM +0200, Mariusz Gromada wrote:
>>>
>>> W dniu 2012-09-22 21:53, Pawel Jakub Dawidek pisze:
Mariusz, can you confirm my findings?
>>>
>>>
>
Ben Laurie writes:
> He means postrandom. Which deletes all saved entropy because of fear
> of replay attacks.
>
> IMO, this doesn't make much sense - if you don't have sufficient fresh
> entropy to mix into the pool, then deleting your saved entropy makes
> you more vulnerable, not less. And if y
13 matches
Mail list logo
