On Dec 9, 2011, at 2:38 PM, Steven Bellovin wrote:
> Imagine
> what would happen if someone upgraded the disk to a flash disk or
> one with a large flash cache
Heh, I was gonna say -- "I haven't carried around a computer that actually has
a hard drive in it for at least a year now."
-- tho
At Fri, 9 Dec 2011 15:50:35 -0500, Donald Allen wrote:
Subject: Re: Lost file-system story
>
> "does not guarantee to keep a consistent file system structure on the
> disk" is what I expected from NetBSD. From what I've been told in this
> discussion, NetBSD pretty much guarantees that if you use
[Another omnibus reply.]
Thor has several different arguments, but some of them seem to amount
to "the old way was broken, therefore the new way is better". I
certainly hope I'm misreading those, because the Thor I thought I knew
is smart to seriously support that kind of stance.
The old way was
At Tue, 6 Dec 2011 12:44:16 -0500, Donald Allen wrote:
Subject: Re: Lost file-system story
>
> much more clear. When I read this before the fun started, I took it to
> mean, perhaps unjustifiably, what I know to be true -- there is some
> non-zero probability that fsck of an async file-system wil
On Fri, Dec 9, 2011 at 4:33 PM, Brian Buhrow
wrote:
> Hello. Just for your edification, it is possible to break out of fsck
> mid-way and reinvoke it with fsck -y to get it to do the cleaning on its
> own.
>
> With regard to your notes on speed with NetBSD versus OpenBSD, I
> suspe
On Dec 9, 2011, at 3:15 52PM, Thor Lancelot Simon wrote:
>>
>> (1) Strong bits suitable for direct use as things like crypto keys.
>> Using a PRNG here, even a really good one, is a major fail.
>
> This may be your opinion, but it differs radically from the opinion of
> almost every expert in the
On Fri, 9 Dec 2011 15:50:35 -0500
Donald Allen wrote:
> were not designed to do this. The reason I'm beating on this is that I
> would have liked to use NetBSD for the application I have in mind, but
> I need the performance improvement that async provides (my tests show
> this; the tests also sh
On Fri, Dec 09, 2011 at 03:50:35PM -0500, Donald Allen wrote:
> The reason I'm beating on this is that I would have liked to use
> NetBSD for the application I have in mind, but I need the performance
> improvement that async provides.
Compared to what? I did extensive benchmarks in the past and s
http://mail-index.netbsd.org/tech-security/1999/08/08/.html
Hello. Just for your edification, it is possible to break out of fsck
mid-way and reinvoke it with fsck -y to get it to do the cleaning on its
own.
With regard to your notes on speed with NetBSD versus OpenBSD, I
suspect the speed trade off is where the difference is. Op
(do we need so many lists?)
I've read Thor's answer to Alan, that started:
>
>You didn't misunderstand. The people who designed the "entropy pool"
>misunderstood. In what sense are bits really ever "taken out"? But,
>back then, the whole idea was so new that being very conservative
and I +1 t
On Fri, 09 Dec 2011, Pawel Jakub Dawidek wrote:
You are aware of the fact that 99.99% of computers don't have
true random number generators and the bits you claim that are
random are not random at all? They try to be unpredictable.
I believe that there is a truly random component to air turbul
>
> -Original Message-
> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
> Behalf Of Mouse
> Sent: Friday, December 09, 2011 2:24 PM
> To: tech-secur...@netbsd.org; tech-kern@NetBSD.org; tech-cry...@netbsd.org
> Subject: Re: Patch: new random pseudodevice
> ...
>>
I just did a little experiment. I installed OpenBSD 5.0 on the same
machine where I had my adventure with NetBSD. This time, I broke up
the world into separate filesystems, which OpenBSD facilitates,
mounting only /home and /tmp async, noatime. All the others were
mounted softdep,noatime. I downloa
On Fri, Dec 09, 2011 at 09:18:39PM +0100, Pawel Jakub Dawidek wrote:
>
> That's the problem. They might seem random, but they are not. They
> weren't designed as true random number generators, so they can't be
> trusted neither to generate true random numbers nor to be resistant on
> various attac
On Fri, Dec 09, 2011 at 02:33:49PM -0500, Mouse wrote:
> > You are aware of the fact that 99.99% of computers don't have true
> > random number generators and the bits you claim that are random are
> > not random at all?
>
> Actually, practically all computers have true random number generators.
>
On Fri, Dec 09, 2011 at 02:23:34PM -0500, Mouse wrote:
>
> You appear to think that anything that's not pure true randomness must
> be pure PRNG. The old randomness pool was neither; it was a hybrid.
I think we have a basic disagreement here. I don't grant that there
is such a thing as "hybrid"
On Fri, Dec 09, 2011 at 02:33:49PM -0500, Mouse wrote:
> Actually, practically all computers have true random number generators.
> The first problem is that neither they nor their interfaces are
> designed as such, so getting the randomness out of them and into the
> system is...interesting. The s
On Fri, 09 Dec 2011, Thor Lancelot Simon wrote:
On Fri, Dec 09, 2011 at 12:14:40PM -0500, Thor Lancelot Simon
wrote:
Let me put it this way: before, you may have thought you were
getting some kind of "true" randomness. You weren't. Now,
you still aren't, but at least what sits between you and
>
> -Original Message-
> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
> Behalf Of Mouse
> Sent: Friday, December 09, 2011 2:34 PM
> To: tech-secur...@netbsd.org; tech-kern@NetBSD.org; tech-cry...@netbsd.org
> Subject: Re: Patch: new random pseudodevice
>
>> You
> You are aware of the fact that 99.99% of computers don't have true
> random number generators and the bits you claim that are random are
> not random at all?
Actually, practically all computers have true random number generators.
The first problem is that neither they nor their interfaces are
de
[I'm pulling together multiple mails from tls here. The second-level
quotes are from varying people; I've marked their authors according to
the info I have.]
[Mouse]
>> "Revealed to userland", of course.
>> Combined with the conservative approach to estimating how much
>> entropy was put into th
On Fri, Dec 09, 2011 at 06:52:16PM +0200, Alan Barrett wrote:
> On Fri, 09 Dec 2011, Thor Lancelot Simon wrote:
> > An attacker who can break AES might be able to predict
> > the future output of _one_ instance of the generator. An
> > attacker who can break AES and recover the key and defeat th
On Fri, Dec 09, 2011 at 12:14:40PM -0500, Thor Lancelot Simon wrote:
>
> Let me put it this way: before, you may have thought you were getting
> some kind of "true" randomness. You weren't. Now, you still aren't,
> but at least what sits between you and the entropy source is a lot
> more clear,
On Fri, Dec 09, 2011 at 06:52:16PM +0200, Alan Barrett wrote:
>
> Fair enough, but you still seem to be talking about how good a
> CSPRNG it is, whereas my concern is that it's pseudorandom, nor
> random.
So was the output from the old entropy pool. Again, look at the
implementation!
As soon as
On Fri, 09 Dec 2011, Thor Lancelot Simon wrote:
An attacker who can break AES might be able to predict
the future output of _one_ instance of the generator. An
attacker who can break AES and recover the key and defeat the
backtracking resistance designed into CTR_DRBG *might* be able
to recov
On Fri, Dec 09, 2011 at 10:35:32AM -0500, Mouse wrote:
> > In what sense are bits really ever "taken out"?
>
> "Revealed to userland", of course.
>
> The idea here is that entropy that has been revealed to userland might
> as well not be present. With good mixing at appropriate points, this
> is
>> And note that at least one highly-thought-of modern design for an
>> entropy collector (Fortuna) doesn't even _try_ to keep an "entropy
>> estimate" -- the whole concept is pretty fuzzy when you start trying
>> to count how many bits you "took out".
> To extend on that: the basic idea is that a
> In what sense are bits really ever "taken out"?
"Revealed to userland", of course.
The idea here is that entropy that has been revealed to userland might
as well not be present. With good mixing at appropriate points, this
is of questionable truth, but it is, as you said, a very conservative
a
On Fri, Dec 09, 2011 at 09:45:40AM -0500, Thor Lancelot Simon wrote:
> Suffice to say I think the state of affairs is a lot better now than
> it was before. And note that at least one highly-thought-of modern
> design for an entropy collector (Fortuna) doesn't even _try_ to
> keep an "entropy esti
On Fri, Dec 09, 2011 at 08:41:25AM +0200, Alan Barrett wrote:
>
> I have this naive idea that trying to get out more than you put in
> is cheating, and I think it's fine for /dev/urandom to cheat, but I
> am not happy about /dev/random cheating. Please could you explain
> where I have misundersto
On Fri, 9 Dec 2011 11:56:32 +0100
Nicolas Joly wrote:
> On Fri, Dec 09, 2011 at 04:36:55AM -0500, Matthew Mondor wrote:
> > In the case of sys/rump/librump/rumpvfs/rumpfs.c, is it possible that
> > the underlaying implementation could previously decide if it could
> > support read(2) on directori
On Fri, Dec 09, 2011 at 04:36:55AM -0500, Matthew Mondor wrote:
> On Fri, 9 Dec 2011 09:33:54 +0100
> Nicolas Joly wrote:
>
> > According to the online OpenGroup specification for read(2) available
> > at [1], read(2) on directories is implementation dependant. If
> > unsupported, it shall fail w
On Fri, 9 Dec 2011 09:33:54 +0100
Nicolas Joly wrote:
> According to the online OpenGroup specification for read(2) available
> at [1], read(2) on directories is implementation dependant. If
> unsupported, it shall fail with EISDIR.
In the case of sys/rump/librump/rumpvfs/rumpfs.c, is it possibl
Hi,
According to the online OpenGroup specification for read(2) available
at [1], read(2) on directories is implementation dependant. If
unsupported, it shall fail with EISDIR.
Not all our file systems comply, and return random errno values in
this case (mostly EINVAL or ENOTSUP).
The attached
35 matches
Mail list logo
