John Baldwin writes:
> Index: sys/kern/kern_intr.c
Looks OK to me! Appears to work too. I'd drop the estimate down to 1 bit
instead of 2 for now. Keeping the estimate really low is safe.
Thanks, John.
M
--
Mark R V Murray
Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open)
Pi: 132511160
On Thu, Sep 20, 2012 at 08:44:10AM -0400, John Baldwin wrote:
> I leave it up to someone else to explicitly ok that this data goes into
> the RANDOM_INTERRUPT queue with the claim of 2 bits of entropy:
>
> Index: sys/kern/kern_intr.c
...
>+ if (harvest.swi) {
>+ CTR3(KTR_INTR, "s
On Wednesday, September 19, 2012 6:08:19 pm David O'Brien wrote:
> Also, I'm having trouble finding the source for 'swi' harvesting.
> Do you know where it is?
It has certainly not been used since 5.0. I wasn't able to find it
in my limited grubbing around in 4.x sources either.
The untested cha
On Sun, Sep 16, 2012 at 05:21:21PM +0100, Mark Murray wrote:
> Tweeks along the way may include reverting to the original intent of
> starting the PRNG blocked, and only unblocking once reseeded.
I hope I'm testing this incorrectly, but I think we've managed to break
this over the years.
1. Putti
On Sun, Sep 16, 2012 at 05:21:21PM +0100, Mark Murray wrote:
> Part 1 of the fix is enclosed; it involves drastically shortening the
> input into /dev/random (the "kickstart") at boot time. There are time
> implications that I'd like to hear any objections to.
...
> better_than_nothing()
> {
> -
Pawel Jakub Dawidek writes:
> Why can't we split harvesting entropy from /dev/random from harvesting
> entropy from sources that are much more performance-sensitive?
> Currently random_harvest_internal() is used for both and it is trying to
> be fast, as we don't want to slow down the caller. But w
On Sun, Sep 16, 2012 at 10:27 PM, Doug Barton wrote:
> Finally, I still think that making changes to the entropy-feeding
> methods in initrandom or random are premature until we have a chance to
> review Arthur's work on what's actually happening with the buffer. Until
> we know where the problems
On Sun, Sep 16, 2012 at 05:21:21PM +0100, Mark Murray wrote:
> Hi
>
> Part 1 of the fix is enclosed; it involves drastically shortening the
> input into /dev/random (the "kickstart") at boot time. There are time
> implications that I'd like to hear any objections to.
>
> Part 1a is going to be tw
On Sat, Sep 15, 2012 at 01:07:34PM +0100, Mark Murray wrote:
> Ben Laurie writes:
> > I notice that events are also discarded when the queue reaches a
> > certain length. This seems like a problem, too.
>
> Hooboy.
>
> Please go back and read this whole thread from the beginning. Attempting
> to
On Sun, 16 Sep 2012 14:27:34 -0700
Doug Barton wrote:
> Finally, I still think that making changes to the entropy-feeding
> methods in initrandom or random are premature until we have a chance
> to review Arthur's work on what's actually happening with the buffer.
> Until we know where the proble
On Sun, 16 Sep 2012 17:21:21 +0100
Mark Murray wrote:
> Part 3 will be the addition of another choice of software PRNG;
> Fortuna. Fortuna is MUCH more resilient to attack,
Fortuna is much more resilient to types of attack that're probably
never going to happen.
Potentially Fortuna could be muc
On 09/16/2012 09:21, Mark Murray wrote:
> Part 1 of the fix is enclosed; it involves drastically shortening the
> input into /dev/random (the "kickstart") at boot time. There are time
> implications that I'd like to hear any objections to.
I remain convinced that chunking the input so that we don'
Hi
Part 1 of the fix is enclosed; it involves drastically shortening the
input into /dev/random (the "kickstart") at boot time. There are time
implications that I'd like to hear any objections to.
Part 1a is going to be tweeks to stashing entropy at restart
(and possibly during normal running). A
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Mark Murray writes:
> > You have to rely on something; Yarrow needs some entropy to cold-start,
> > and on a freshly installed OS, this is rocking-horse shit. This is
> > where BIG problems start because it is at this time that (eg) SSH keys
> > are b
Mark Murray writes:
> You have to rely on something; Yarrow needs some entropy to cold-start,
> and on a freshly installed OS, this is rocking-horse shit. This is
> where BIG problems start because it is at this time that (eg) SSH keys
> are built. We make some effort to get the user to "kayboard
On Sat, Sep 15, 2012 at 1:07 PM, Mark Murray wrote:
> Ben Laurie writes:
>> I notice that events are also discarded when the queue reaches a
>> certain length. This seems like a problem, too.
>
> Hooboy.
>
> Please go back and read this whole thread from the beginning. Attempting
> to mitigate the
On Sat, 15 Sep 2012 09:13:49 +0100
Mark Murray wrote:
> RW writes:
> > So far no one has come up with a single cogent argument for
> > compression. If you replace compression with hashing then the need
> > modifying the kernel code is eliminated.
>
> Compression reduces file size without losing e
Ben Laurie writes:
> I notice that events are also discarded when the queue reaches a
> certain length. This seems like a problem, too.
Hooboy.
Please go back and read this whole thread from the beginning. Attempting
to mitigate the inevitable effects of filling the harvest queue is the
main thru
Ben Laurie writes:
> > Reseeds are expensive in kernel space; locking/unlocking and thread
> > consumption are the issue. Right now, this is mitigated by reseeding
> > at 10Hz. To allow reseeds to overwhelm the running kernel by pumping
> > data into /dev/random is would be very silly indeed, and I
On Sat, Sep 15, 2012 at 12:07 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > Are you aware of Yarrow's approach to poor entropy while harvesting?
>>
>> Yes. I am _only_ talking about fixes for the current practice of
>> discarding input - once Yarrow gets to eat input, then its all fine,
>> but
Ben Laurie writes:
> > Are you aware of Yarrow's approach to poor entropy while harvesting?
>
> Yes. I am _only_ talking about fixes for the current practice of
> discarding input - once Yarrow gets to eat input, then its all fine,
> but as you say, you don't want to run Yarrow over all input becau
On Sat, Sep 15, 2012 at 11:36 AM, Mark Murray wrote:
> Ben Laurie writes:
>> > I can certainly trigger a reseed at will, but allowing external writes
>> > to overwhelm the system by doing a
>> >
>> > $ cat /dev/zero > /dev/random
>> >
>> > ... just ain't gonna happen. No, sir.
>>
>> Let's just qua
On Sat, Sep 15, 2012 at 11:36 AM, Mark Murray wrote:
> Ben Laurie writes:
>> My point here is that you don't have full control of the inputs
>> to /dev/random, so assuming that they take some particular form
>> seems like a mistake to me - the aim, I would hope, would be to
>> extract available en
Ben Laurie writes:
> > I can certainly trigger a reseed at will, but allowing external writes
> > to overwhelm the system by doing a
> >
> > $ cat /dev/zero > /dev/random
> >
> > ... just ain't gonna happen. No, sir.
>
> Let's just quantify the risk here: essentially the problem is that if
> I fee
On Fri, Sep 14, 2012 at 10:49 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > My proposed solution is intended so address, if not solve that
>> > problem, by preventing file writes from filling up the harvest
>> > queue. Yarrow already has pretty good data hashing; there is no
>> > point in dupli
RW writes:
> So far no one has come up with a single cogent argument for
> compression. If you replace compression with hashing then the need
> modifying the kernel code is eliminated.
Compression reduces file size without losing entropy; in fact it serves
as an entropy concentrator. That said, I
Its useless chink.
Sent from my iPhone
On Sep 14, 2012, at 11:39 PM, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 9/14/12 7:18 PM, Samuel Ports wrote:
>> Omg cant an freebsd-entropy be created as mailing list already
>
> Nothing prevents you from unsubscribing this m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 9/14/12 7:18 PM, Samuel Ports wrote:
> Omg cant an freebsd-entropy be created as mailing list already
Nothing prevents you from unsubscribing this mailing list.
> Sent from my iPhone
>
> On Sep 14, 2012, at 8:09 PM, RW
> wrote:
>
>> On Fri, 1
Omg cant an freebsd-entropy be created as mailing list already
Sent from my iPhone
On Sep 14, 2012, at 8:09 PM, RW wrote:
> On Fri, 14 Sep 2012 17:25:59 +0100
> Ben Laurie wrote:
>
>> On Fri, Sep 14, 2012 at 3:46 PM, RW
>> wrote:
>>> On Fri, 14 Sep 2012 14:43:53 +0100
>>> Ben Laurie wrote:
>>>
On Fri, 14 Sep 2012 22:49:14 +0100
Mark Murray wrote:
> If not, then whatever you run instead must also be sound. XOR isn't.
>
> You have a way to go before you convince me on this one. I'll buy this
> argument if it is a routine/regular/risky ocurrence that the output
> of (say)
>
> $ ( ps -gau
On Fri, 14 Sep 2012 16:15:03 -0700
Arthur Mesh wrote:
> Has it been considered that /dev/random being "rw-rw-rw-" may be a bad
> idea? What's the benefit of allowing unprivileged users reseeding
> yarrow? Perhaps restricting it to "rw-r--r--" is a part of the
> solution that may address potential
On Fri, Sep 14, 2012 at 10:49:14PM +0100, Mark Murray wrote:
> I can certainly trigger a reseed at will, but allowing external writes
> to overwhelm the system by doing a
>
> $ cat /dev/zero > /dev/random
>
> ... just ain't gonna happen. No, sir.
Has it been considered that /dev/random being "rw
On Fri, 14 Sep 2012 17:25:59 +0100
Ben Laurie wrote:
> On Fri, Sep 14, 2012 at 3:46 PM, RW
> wrote:
> > On Fri, 14 Sep 2012 14:43:53 +0100
> > Ben Laurie wrote:
> >
> >> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb
> >> wrote:
> >> > 7) send all data to the kernel and hash (arch dependent?) i
Ben Laurie writes:
> > My proposed solution is intended so address, if not solve that
> > problem, by preventing file writes from filling up the harvest
> > queue. Yarrow already has pretty good data hashing; there is no
> > point in duplicating that.
>
> Fine: then when the queue fills, run the Ya
On Fri, Sep 14, 2012 at 9:15 PM, Mark Murray wrote:
> Ben Laurie writes:
>> What I am trying to do is extract whatever entropy there is in the
>> input. You appear to be saying that there's no point adding extra
>> entropy because it is estimated at zero. This makes no sense to me.
>
> What I am t
Ben Laurie writes:
> What I am trying to do is extract whatever entropy there is in the
> input. You appear to be saying that there's no point adding extra
> entropy because it is estimated at zero. This makes no sense to me.
What I am trying to say is that it doesn't matter if by some coincidence
On Fri, Sep 14, 2012 at 8:22 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > What??! Have you seen how Yarrow does its harvesting??
>>
>> If you XOR into the as-yet-unharvested buffer, then appropriately
>> aligned repeated input makes the buffer zero.
>
I have no idea what point you're trying t
Pawel Jakub Dawidek writes:
> Also, compression can definiately increase entropy per byte, but IMHO it
> can also lose some entropy overall. With lossless compression you don't
> lose data, but I don't believe you can say that you don't lose entropy.
By definition (both the definition of entropy
Ben Laurie writes:
> > What??! Have you seen how Yarrow does its harvesting??
>
> If you XOR into the as-yet-unharvested buffer, then appropriately
> aligned repeated input makes the buffer zero.
There is an "if" and an "appropriately" in there. The entropy is
estimated as Zero anyway, in spite o
Ben Laurie writes:
> > I'll send patches (untested) in a couple of hours for discussion.
>
> I used to like this idea, but it can break pretty badly if you repeat
> input, so in the end I decided hashes were the only safe way.
What??! Have you seen how Yarrow does its harvesting??
Presupposing t
On Fri, Sep 14, 2012 at 8:06 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > I'll send patches (untested) in a couple of hours for discussion.
>>
>> I used to like this idea, but it can break pretty badly if you repeat
>> input, so in the end I decided hashes were the only safe way.
>
> What??! H
On Fri, Sep 14, 2012 at 4:30 PM, Pawel Jakub Dawidek wrote:
> On Tue, Sep 11, 2012 at 04:01:17PM -0700, Xin Li wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 09/11/12 15:48, Arthur Mesh wrote:
>> > On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
>> >> Using gzip is b
On Fri, Sep 14, 2012 at 3:59 PM, Mark Murray wrote:
>> 5) send all data to the kernel but XORing the data together on
>> overflow in the kernel (can control when buffer full and only then
>> take action when needed, indepedent on how seed data is chosen,
>> withdrawn)
>
> I've already coded this u
On Fri, Sep 14, 2012 at 3:46 PM, RW wrote:
> On Fri, 14 Sep 2012 14:43:53 +0100
> Ben Laurie wrote:
>
>> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb
>> wrote:
>> > 7) send all data to the kernel and hash (arch dependent?) it +
>> > counter value into the buffer on overflow, as in b[n] = H(b[n
On Tue, Sep 11, 2012 at 04:01:17PM -0700, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 09/11/12 15:48, Arthur Mesh wrote:
> > On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
> >> Using gzip is better than not using it though, since 4k worth of
> >> compressed d
"Bjoern A. Zeeb" writes:
> 1) continue to over-[fs]eed as we always did (seems out of question,
> no improvement)
See below. Solutions are very possible.
> 2) compress (as in gzip) the input of better_than_nothing (multiple
> people objected, no literature, questionable outcome, speed, still not
On Fri, 2012-09-14 at 13:38 +, Bjoern A. Zeeb wrote:
> On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote:
>
> Hi,
>
> I have removed freebsd-rc for this part of the discussion as it's
> unrelated.
>
I don't think I have the right expertise to help in this discussion. My
gut tells me that lossless
On Fri, 14 Sep 2012 14:43:53 +0100
Ben Laurie wrote:
> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb
> wrote:
> > 7) send all data to the kernel and hash (arch dependent?) it +
> > counter value into the buffer on overflow, as in b[n] = H(b[n] + c
> > + i[n]) in the kernel
> >(can control w
On Thu, Sep 13, 2012 at 08:51:15PM +0100, Mark Murray wrote:
> David O'Brien writes: On Thu, Sep 13, 2012 at 08:00:19PM +0100, Mark Murray
> wrote:
> > Mark,
> > Can you add more about your reasoning why the low-grade entropy should be
> > input before the high-quality cached entropy?
>
> Sure!
>
On Fri, 14 Sep 2012, Ian Lepore wrote:
On Fri, 2012-09-14 at 13:38 +, Bjoern A. Zeeb wrote:
On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote:
Hi,
I have removed freebsd-rc for this part of the discussion as it's
unrelated.
..
I think the one thing left I might be able to contribute is a lit
On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb wrote:
> 7) send all data to the kernel and hash (arch dependent?) it + counter value
>into the buffer on overflow, as in b[n] = H(b[n] + c + i[n]) in the
> kernel
>(can control when buffer full and only then take action when
>needed, ind
On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote:
Hi,
I have removed freebsd-rc for this part of the discussion as it's
unrelated.
Ok, this is an aweful lot of individual parts and my feeling is that
we want to go through them very focused. Some of them have been
discussed enough already with good s
On Thu, 13 Sep 2012 20:00:19 +0100
Mark Murray wrote:
> > The entropy estimated at zero bits is so that an *unpriveleged* user
> > can't feed in his own input, corrupt the entropy estimation and
> > perform a state-extension attack.
>
> Yarrow is pretty resistant to this. "cat /dev/zero > /dev/
On Thu, 13 Sep 2012 20:00:19 +0100
Mark Murray wrote:
>
> > The entropy estimated at zero bits is so that an *unpriveleged* user
> > can't feed in his own input, corrupt the entropy estimation and
> > perform a state-extension attack.
>
> Yarrow is pretty resistant to this. "cat /dev/zero > /de
David O'Brien writes:
> On Thu, Sep 13, 2012 at 08:00:19PM +0100, Mark Murray wrote:
> > I'm in favour of doing something
> > to "dribble" the startup suff in, while limiting its length to (say)
> > 1-2 K. Compressing the gathered stuff is a good idea, and inserting
> > that *first* with a delay f
On Thu, Sep 13, 2012 at 08:00:19PM +0100, Mark Murray wrote:
> I'm in favour of doing something
> to "dribble" the startup suff in, while limiting its length to (say)
> 1-2 K. Compressing the gathered stuff is a good idea, and inserting
> that *first* with a delay following would be ideal; 1 secon
I've been watching this thread, but not responding due to a need to not
contribute to controversy and to be able to provide a measured response
when I had the resources.
I'm responding to this mail out of the thread not for any particular
reason.
> David O'Brien wrote:
>
> > > On 09/10/2012 23:
secteam is currently digesting more of this thread and are going
through things. Could you please slow down; we'll try to summarize
the current status and we shall see. We do have a real life as well
and other issues to deal with so please don't expect a 1 hour round
trip time. Might also giv
On Wed, Sep 12, 2012 at 02:31:41PM -0700, Arthur Mesh wrote:
> As you can see, only first ps, and part of sysctl is consumed. Rest of
> the pipe is dropped. Contents of ls(1) follow and then parts of entropy
> files.
Note this result is just for this run of the test.
Arthur showed me varience betw
On 9/12/2012 10:28 AM, John Baldwin wrote:
> On Tuesday, September 11, 2012 5:38:15 am Doug Barton wrote:
>> I've said lots of times now that my FreeBSD time is limited, and THE
>> BURDEN OF PROOF IS ON YOU. If you think it's easy, whip it up. If you're
>> right, the truth will benefit all of us.
>
On Tuesday, September 11, 2012 5:38:15 am Doug Barton wrote:
> >>> Also, both jbh <201209050944.38042@freebsd.org> and RW
> >>> <20120905021248.5a17a...@gumby.homeunix.com> feel this likely does
> >>> happen just from reading the code. Please explain from either
> >>> (1) a code reading, or (2
On Tue, 11 Sep 2012 16:01:17 -0700
Xin Li wrote:
> Well, 1:1 correspondence is when we fed full text to /dev/random,
> which we don't, right? Only the first 4K gets consumed. So:
>
> Situation 1: we have 45K of plain text, and only first 4k is fed to
> /dev/random at about 5 bits of entropy pe
On Tue, 11 Sep 2012 01:23:09 -0700
David O'Brien wrote:
> > On 09/10/2012 23:46, David O'Brien wrote:
> > > In what way did I suggest we don't need to seed the PRNG?
> > > I simply removed an outdated and incorrect statement.
> >
> > Yes, the comment as it stood was out of date. I'm not sure that
Xin Li writes:
> Situation 1: we have 45K of plain text, and only first 4k is fed to
> /dev/random at about 5 bits of entropy per byte;
>
> Situation 2: we have 45K of plain text, compress to e.g. 25K and only
> first 4k is fed to /dev/random at more than 7.6 bits of entropy per byte;
>
> Therefor
On 09/11/2012 12:48 PM, Arthur Mesh wrote:
> On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
>> Using gzip is better than not using it though, since 4k worth of
>> compressed data is better than 4k worth of plain text because of
>> higher entropy destiny (note that the FreeBSD gzip uses 64K
On 09/11/2012 04:20 AM, Ian Lepore wrote:
> On Mon, 2012-09-10 at 22:46 -0700, David O'Brien wrote:
>>
>>> -r just changes the sort order, which is probably pointless.
>>
>> I'm not wedded to "-r", but since you're proposing this to not use "-r",
>> which Ian Lepore suggested after instrumenting /e
On Tue, Sep 11, 2012 at 09:27:26PM -0400, Samuel Ports wrote:
> 63 deleted messages and counting
>
Comments like this in this thread, and accusation of FreeBSD developers
operating "behind closed doors" on other lists.
It would be amusing, if it weren't so sad...
Glen
pgpzHM1Ulw5wS.pgp
Descr
63 deleted messages and counting
On Tue, Sep 11, 2012 at 7:03 PM, Arthur Mesh wrote:
> On Tue, Sep 11, 2012 at 04:01:17PM -0700, Xin Li wrote:
> > Well, 1:1 correspondence is when we fed full text to /dev/random,
> > which we don't, right? Only the first 4K gets consumed. So:
>
> That's right.
On Tue, Sep 11, 2012 at 04:01:17PM -0700, Xin Li wrote:
> Well, 1:1 correspondence is when we fed full text to /dev/random,
> which we don't, right? Only the first 4K gets consumed. So:
That's right.
> Situation 1: we have 45K of plain text, and only first 4k is fed to
> /dev/random at about 5
On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
> Using gzip is better than not using it though, since 4k worth of
> compressed data is better than 4k worth of plain text because of
> higher entropy destiny (note that the FreeBSD gzip uses 64K of
> input/output buffer for compression by the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 17:07, David O'Brien wrote:
> On Tue, Sep 11, 2012 at 04:22:24PM -0700, Xin Li wrote:
>> Please consider using sha512...
>
> What is the performance (boot time) impact on low-end MIPS and ARM
> systems?
>
> I'm all for sha512, but don'
On Tue, Sep 11, 2012 at 04:22:24PM -0700, Xin Li wrote:
> I'm not quite convinced that this works by the way -- is 65 bytes
> enough to "kickstart" /dev/random?
What way our yarrow works today, we start up assuming we're seeding.
And writes to /dev/random do not count toward our entropy estimation
On Tue, Sep 11, 2012 at 04:22:24PM -0700, Xin Li wrote:
> Please consider using sha512...
What is the performance (boot time) impact on low-end MIPS and ARM
systems?
I'm all for sha512, but don't want to be shot with a machine gun (vs.
simple pistol).
--
-- David (obr...@freebsd.org)
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 16:01, David O'Brien wrote:
> On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
>> On 09/11/12 14:52, David O'Brien wrote:
>>> On Tue, Sep 11, 2012 at 02:22:15PM -0700, Xin Li wrote:
Hmm, but this sha256 run will turn the outpu
On Tue, Sep 11, 2012 at 04:01:17PM -0700, Xin Li wrote:
> Situation 1: we have 45K of plain text, and only first 4k is fed to
> /dev/random at about 5 bits of entropy per byte;
>
> Situation 2: we have 45K of plain text, compress to e.g. 25K and only
> first 4k is fed to /dev/random at more than 7
On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
> On 09/11/12 14:52, David O'Brien wrote:
> > On Tue, Sep 11, 2012 at 02:22:15PM -0700, Xin Li wrote:
> > > Hmm, but this sha256 run will turn the output to 65 bytes (hex
> > > representation of 256 bits of hash output, 64 bytes, and one \n),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 15:48, Arthur Mesh wrote:
> On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
>> Using gzip is better than not using it though, since 4k worth of
>> compressed data is better than 4k worth of plain text because of
>> higher entrop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 14:52, David O'Brien wrote:
> On Tue, Sep 11, 2012 at 02:22:15PM -0700, Xin Li wrote:
>> On 09/11/12 14:17, David O'Brien wrote:
>>> On Tue, Sep 11, 2012 at 02:04:42PM -0700, Xin Li wrote:
So if I was to implement the low grade part
On Tue, Sep 11, 2012 at 02:22:15PM -0700, Xin Li wrote:
> On 09/11/12 14:17, David O'Brien wrote:
> > On Tue, Sep 11, 2012 at 02:04:42PM -0700, Xin Li wrote:
> >> So if I was to implement the low grade part I'd remove the
> >> variable names from the sysctl output at minimum.
> >
> > I've removed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
By the way what I meant would be something like:
Instead of:
| /sbin/sha256 -q | dd of=/dev/random bs=8k 2>/dev/null
Do:
| gzip | dd ibs=1 iseek=16 obs=8k count=8k of=/dev/random 2>/dev/null
Note that the first few bytes are deterministic (heade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 14:27, RW wrote:
> On Tue, 11 Sep 2012 13:54:41 -0700 Xin Li wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 09/11/12 12:53, RW wrote:
>>> On Tue, 11 Sep 2012 13:28:51 +0200 Dag-Erling Smørgrav wrote:
>>>
Doug
On Tue, 11 Sep 2012 13:54:41 -0700
Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 09/11/12 12:53, RW wrote:
> > On Tue, 11 Sep 2012 13:28:51 +0200 Dag-Erling Smørgrav wrote:
> >
> >> Doug Barton writes:
> >>> 1. Pseudo-randomize the order in which we utilize the files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 14:17, David O'Brien wrote:
> On Tue, Sep 11, 2012 at 02:04:42PM -0700, Xin Li wrote:
>> So if I was to implement the low grade part I'd remove the
>> variable names from the sysctl output at minimum.
>
>
> I've removed the MIB names in
On Tue, Sep 11, 2012 at 02:04:42PM -0700, Xin Li wrote:
> So if I was to implement the low grade part I'd remove the variable
> names from the sysctl output at minimum.
I've removed the MIB names in my latest diff (based on input from this
thread):
+ ( dmesg; kenv; df -ib; \
+ ps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 13:09, David O'Brien wrote:
> On Tue, Sep 11, 2012 at 08:53:02PM +0100, RW wrote:
>> On Tue, 11 Sep 2012 13:28:51 +0200 Dag-Erling Sm�rgrav wrote:
>>> so none of it is discarded. My gut feeling is that compression
>>> is better than hash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/12 12:53, RW wrote:
> On Tue, 11 Sep 2012 13:28:51 +0200 Dag-Erling Smørgrav wrote:
>
>> Doug Barton writes:
>>> 1. Pseudo-randomize the order in which we utilize the files in
>>> /var/db/entropy
>>
>> There's no need for randomization i
On Tue, Sep 11, 2012 at 08:53:02PM +0100, RW wrote:
> On Tue, 11 Sep 2012 13:28:51 +0200 Dag-Erling Sm?rgrav wrote:
> > so none of it is discarded. My gut feeling is that compression is
> > better than hashing for that purpose,
>
> It's analogous to a passphrase, have you ever heard of a
> passph
On Tue, 11 Sep 2012 13:28:51 +0200
Dag-Erling Smørgrav wrote:
> Doug Barton writes:
> > 1. Pseudo-randomize the order in which we utilize the files in
> > /var/db/entropy
>
> There's no need for randomization if we make sure that *all* the data
> written to /dev/random is used, rather than just
On Mon, 2012-09-10 at 22:46 -0700, David O'Brien wrote:
>
> > -r just changes the sort order, which is probably pointless.
>
> I'm not wedded to "-r", but since you're proposing this to not use "-r",
> which Ian Lepore suggested after instrumenting /etc/rc.d/initrandom and
> looking at the output
On Tue, Sep 11, 2012 at 01:28:51PM +0200, Dag-Erling Smrgrav wrote:
> My gut feeling is that compression is better
> than hashing for that purpose,
An related interesting thing -- in
http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix98.pdf '5. Randomness
Polling Results', Peter Gutmann states
On Mon, Sep 10, 2012 at 01:40:28PM -0700, Doug Barton wrote:
> > 2) reusing entropy seeds is a bad thing - for this I don't have
> > empirical proof. But I have Bruce Schneier's word.
>
> And as I have stated repeatedly, you and David are misapplying what
> you're reading.
Just my 2c.
In case we
Doug Barton writes:
> 1. Pseudo-randomize the order in which we utilize the files in
> /var/db/entropy
There's no need for randomization if we make sure that *all* the data
written to /dev/random is used, rather than just the first 4096 bytes;
or that we reduce the amount of data to 4096 bytes be
On 09/11/2012 01:23 AM, David O'Brien wrote:
>> On 09/10/2012 23:46, David O'Brien wrote:
>>> In what way did I suggest we don't need to seed the PRNG?
>>> I simply removed an outdated and incorrect statement.
>>
>> Yes, the comment as it stood was out of date. I'm not sure that removing
>> it (rat
> On 09/10/2012 23:46, David O'Brien wrote:
> > In what way did I suggest we don't need to seed the PRNG?
> > I simply removed an outdated and incorrect statement.
>
> Yes, the comment as it stood was out of date. I'm not sure that removing
> it (rather than rephrasing it) was the right call.
Dou
On Tue, Sep 11, 2012 at 09:31:18AM +0200, Dag-Erling Smrgrav wrote:
> David O'Brien writes:
> > Dag-Erling Sm??rgrav writes:
> > > -u is overridden by -o and therefore pointless.
> > Please verify this claim (or have I misunderstood you?):
>
> Hmm, I assumed it did, but didn't check. Sorry.
No
David O'Brien writes:
> Dag-Erling Smørgrav writes:
> > -u is overridden by -o and therefore pointless.
> Please verify this claim (or have I misunderstood you?):
Hmm, I assumed it did, but didn't check. Sorry.
DES
--
Dag-Erling Smørgrav - d...@des.no
_
On 09/11/2012 00:10, David O'Brien wrote:
> On Mon, Sep 10, 2012 at 01:33:46PM -0700, Doug Barton wrote:
>> Remember, the assertion that David and Arthur are making is that
>> re-using the files in /var/db/entropy is harmful.
>
> It is not just David and Arthur, it is also the designer of the PRNG
On 09/10/2012 23:46, David O'Brien wrote:
> On Mon, Sep 10, 2012 at 11:40:58AM -0700, Doug Barton wrote:
>> I am opposed to this patch, more details below.
>>
>> On 9/10/2012 6:52 AM, David O'Brien wrote:
>>> * Updates the comment about blocking -- it hasn't been true for 8 years.
>>
>> Just becaus
On Mon, Sep 10, 2012 at 01:33:46PM -0700, Doug Barton wrote:
> Remember, the assertion that David and Arthur are making is that
> re-using the files in /var/db/entropy is harmful.
Damnit Doug is your desktop's memory faulty and you're loosing RAM
values? Is your MUA (or MTA) randomly dropping cha
On Mon, Sep 10, 2012 at 11:40:58AM -0700, Doug Barton wrote:
> I am opposed to this patch, more details below.
>
> On 9/10/2012 6:52 AM, David O'Brien wrote:
> > * Updates the comment about blocking -- it hasn't been true for 8 years.
>
> Just because .seeded=1 doesn't mean the device is ready to
1 - 100 of 156 matches
Mail list logo
