Date: Tue, 21 Aug 2012 09:55:01 +0100 From: Ben Laurie <ben@links.org> To: Peter Jeremy <peter@rulingia.com> Cc: freebsd-arch@freebsd.org Subject: Re: /dev/random Message-ID: <CAG5KPzwy0csR0F5WXVmDg9=3vDiPXf9X=Zz=dAsXpMEnjjn6AQ@mail.gmail.com> In-Reply-To: <20120820225504.GA78528@server.rulingia.com> References: <CAG5KPzz4GQ2C_ky_qrDroQ4srGL4daW0OO-F3eOvvL-9AO6zoQ@mail.gmail.com> <20120820220243.GA96700@troutmask.apl.washington.edu> <CAG5KPzwBzWvDFDZqzT4masbknKfVe-rvdTd1h6ZxEoG90Rcxqg@mail.gmail.com> <20120820225504.GA78528@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 20, 2012 at 11:55 PM, Peter Jeremy <peter@rulingia.com> wrote: > On 2012-Aug-20 23:05:39 +0100, Ben Laurie <ben@links.org> wrote: >>It is relevant because it seems there is entropy available in >>fine-grained timing. > > Part of the entropy harvested at each of the sampling points is > the CPU cyclecounter (eg TSC). It's difficult to see what finer > grained timing you expect to be used. In the wake of https://factorable.net/weakkeys12.conference.pdf, I'm wondering how well we do on entropy-starved devices. The thing that worries me about TSC is that multiple identical devices may get similar values during initialisation (I don't know if they do, has anyone studied this?). Skew between TSC and a real-time clock might be useful (because ultimately the RTC relies on a clock that is not synchronised with the CPU clock), but AFAICS we don't use the RTC to provide randomness. I could be missing something, of course, I've only recently started looking at this code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG5KPzwy0csR0F5WXVmDg9=3vDiPXf9X=Zz=dAsXpMEnjjn6AQ>