On Fri, Aug 19, 2016 at 10:20:18AM -0700, H. Peter Anvin wrote:
> On 08/18/16 22:56, Herbert Xu wrote:
> > On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
> >>
> >> That really depends on the system. We can't assume that people are
> >> using systems with a 100Hz clock interrupt. M
On 08/18/16 22:56, Herbert Xu wrote:
> On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
>>
>> That really depends on the system. We can't assume that people are
>> using systems with a 100Hz clock interrupt. More often than not
>> people are using tickless kernels these days. That'
Hi!
> > From my point of view, it would make sense to factor time from RTC and
> > mac addresses into the initial hash. Situation in the paper was so bad
> > some devices had _completely identical_ keys. We should be able to do
> > better than that.
>
> We fixed that **years** ago. In fact, the
On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
>
> That really depends on the system. We can't assume that people are
> using systems with a 100Hz clock interrupt. More often than not
> people are using tickless kernels these days. That's actually the
> problem with changing /dev
On Thu, Aug 18, 2016 at 08:39:23PM +0200, Pavel Machek wrote:
>
> But this is the scary part. Not limited to ssh. "We perform the
> largest ever network survey of TLS and SSH servers and present
> evidence that vulnerable keys are surprisingly widespread. We find
> that 0.75% of TLS certificates s
On Thu 2016-08-18 13:27:12, Theodore Ts'o wrote:
> On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
> >
> > Actually.. I'm starting to believe that getting enough entropy before
> > userspace starts is more important than pretty much anything else.
> >
> > We only "need" 64-bits of e
On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
>
> Actually.. I'm starting to believe that getting enough entropy before
> userspace starts is more important than pretty much anything else.
>
> We only "need" 64-bits of entropy, AFAICT. If it passes statistical
> tests, I'd use it.
Hi!
> As far as whether or not you can gather enough entropy at boot time,
> what we're really talking about how how much entropy we want to assume
> can be gathered from interrupt timings, since what you do in your code
> is not all that different from what the current random driver is
> doing.
Am Dienstag, 16. August 2016, 15:28:45 CEST schrieb H. Peter Anvin:
Hi Peter,
> >
> > There are two motivations for that:
> >
> > - the current /dev/random is compliant to NTG.1 from AIS 20/31 which
> > requires (in brief words) that entropy comes from auditible noise
> > sources. Currently in
On 08/16/16 15:28, H. Peter Anvin wrote:
> On 08/15/16 22:45, Stephan Mueller wrote:
>> Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin:
>>
>> Hi H,
>>
>>> On 08/11/16 05:24, Stephan Mueller wrote:
* prevent fast noise sources from dominating slow noise sources
in
On 08/15/16 22:45, Stephan Mueller wrote:
> Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin:
>
> Hi H,
>
>> On 08/11/16 05:24, Stephan Mueller wrote:
>>> * prevent fast noise sources from dominating slow noise sources
>>>
>>> in case of /dev/random
>>
>> Can someone please expl
Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin:
Hi H,
> On 08/11/16 05:24, Stephan Mueller wrote:
> > * prevent fast noise sources from dominating slow noise sources
> >
> > in case of /dev/random
>
> Can someone please explain if and why this is actually desirable, and if
>
On 08/11/16 05:24, Stephan Mueller wrote:
> * prevent fast noise sources from dominating slow noise sources
> in case of /dev/random
Can someone please explain if and why this is actually desirable, and if
this assessment has been passed to someone who has actual experience
with cryptography at
On Mon, Aug 15, 2016 at 08:13:06AM +0200, Stephan Mueller wrote:
>
> According to my understanding of NAPI, the network card sends one interrupt
> when receiving the first packet of a packet stream and then the driver goes
> into polling mode, disabling the interrupt. So, I cannot see any batchi
Am Freitag, 12. August 2016, 15:22:08 CEST schrieb Theodore Ts'o:
Hi Theodore,
> On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote:
> > - correlation: the interrupt noise source is closely correlated to the
> > HID/
> > block noise sources. I see that the fast_pool somehow "smears"
On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote:
>
> - correlation: the interrupt noise source is closely correlated to the HID/
> block noise sources. I see that the fast_pool somehow "smears" that
> correlation. However, I have not seen a full assessment that the correlation
>
Am Donnerstag, 11. August 2016, 17:36:32 CEST schrieb Theodore Ts'o:
Hi Theodore,
> On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote:
> > The following patch set provides a different approach to /dev/random
which
> > I call Linux Random Number Generator (LRNG) to collect entropy w
On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote:
>
> The following patch set provides a different approach to /dev/random which
> I call Linux Random Number Generator (LRNG) to collect entropy within the
> Linux
> kernel. The main improvements compared to the legacy /dev/random is
Hi Herbert, Ted,
The following patch set provides a different approach to /dev/random which
I call Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the legacy /dev/random is to provide
sufficient entropy during boot time as well as
19 matches
Mail list logo
