[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130130165127.GO20323@brightrain.aerifal.cx>
Date: Wed, 30 Jan 2013 11:51:27 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add support for mkostemp, mkstemps and mkostemps
On Wed, Jan 30, 2013 at 02:45:37PM +0100, Szabolcs Nagy wrote:
> * Hardy Falk <hardy.falk@...boo.com> [2013-01-30 08:59:51 +0100]:
> > Am 30.01.2013 08:21, schrieb Rich Felker:
> > >On Tue, Jan 29, 2013 at 06:16:11PM -0500, Anthony G. Basile wrote:
> > >>>implement, but the random name generator definitely needs a better
> > >>>algorithm. I just adopted what was already there, but its not good
> > >>>enough.
> > >>>
> > You should try "shr3" by George Marsaglia (rip)
>
> no, we dont need a prng there, we get new entropy
> at each try from the clock source
>
> the statistical quality may be improved a bit with
> different hashing of the time and addresses, but
> it is reasonable now
>
> for retries the iteration count and the previous
> rand could be used as well, but that's a rare case
Right now, and attacker who just wants to drastically slow down a
program can create every name in a large time window around the
current time. Better use of the stack address in generating the
filenames could prevent knowing the set of output filenames for a
range of times without knowing the stack address in the program being
attacked. In fact, I'm a little bit worried that the current approach
discloses too much information about the stack address to an attacker.
If nothing else, I think some shuffling should be done so that the
(typically more valuable) high bits of the stack address are matched
with the low (least predictable) bits of the clock.
Obviously cryptographic-quality hashes would be a solution, but I
don't think anybody wants that much bloat in mkstemp, etc...
> more significant improvement can be done by larger
> set of names and better entropy source
The theoretical bound on the space (6 X's to work with) is slightly
under 48 bits (no nulls or slashes), but that assumes you're okay with
inserting control characters, shell-special characters, malformed
utf-8, etc. I would say most of these are very bad.
Other implementations probably use 36 bits or slightly less (base64
perhaps modified base64).
I could see it being feasible to increase this slightly and maybe even
get up to ~40 bit space using part of the UTF-8 space, but I'm not
sure users would like all sorts of random characters in filenames. It
would definitely bog down your file manager loading all those fonts to
view /tmp.. :-)
> the entropy source is mostly problematic on embedded
> systems with bad clock, but there is probably no
> good source at all there
Are you sure this is an issue? IMO it's the kernel's responsibility to
give a good clock value however it can. IIRC even mips has a cpu
counter or something that could be used to compensate for bad clock
hardware, so it seems like a kernel failing if clock_gettime has bad
resolution.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
