Am Mittwoch, 22. Juni 2016, 08:54:16 schrieb Austin S. Hemmelgarn:
Hi Austin,
> You're not demonstrating it's inherently present in the architecture,
I am not demonstrating it, interesting statement. I take different arches from
different vendors which were developed independently from each oth
On 2016-06-22 01:16, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn:
Hi Austin,
Little data, interesting statement for results on 200+ systems including
all major CPU arches all showing information leading in the same
directions.
Let me try rephrasing
Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn:
Hi Austin,
> > Little data, interesting statement for results on 200+ systems including
> > all major CPU arches all showing information leading in the same
> > directions.
> Let me try rephrasing this to make it a bit clearer:
>
On 2016-06-21 14:04, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
6. You have a significant lack of data regarding embedded systems, which
is one of the two biggest segments of Linux's market share. You list no
results for any pre-ARMv6 systems (Linu
On 2016-06-21 09:19, Tomas Mraz wrote:
On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote:
On 2016-06-20 14:32, Stephan Mueller wrote:
[1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
Specific things I notice about this:
1. QEMU systems are reporting higher values than almos
Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
Hi Austin,
>
> >> 2. Quite a few systems have a rather distressingly low lower bound and
> >> still get accepted by your algorithm (a number of the S/390 systems, and
> >> a handful of the AMD processors in particular).
> >
> >
Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-21 13:23, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >>> You have to trust the host for anything, not just for the entropy in
>
On 2016-06-21 13:23, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
Hi Austin,
You have to trust the host for anything, not just for the entropy in
timings. This is completely invalid argument unless you can present a
method that one guest can manipul
On 2016-06-21 09:20, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn:
Hi Austin,
On 2016-06-20 14:32, Stephan Mueller wrote:
Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
Hi Austin,
On 2016-06-18 12:31, Stephan Mueller wrote:
Am
Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
Hi Austin,
> > You have to trust the host for anything, not just for the entropy in
> > timings. This is completely invalid argument unless you can present a
> > method that one guest can manipulate timings in other guest in such
On 2016-06-21 09:42, Pavel Machek wrote:
Hi!
6. You have a significant lack of data regarding embedded systems, which is
one of the two biggest segments of Linux's market share. You list no
results for any pre-ARMv6 systems (Linux still runs on and is regularly used
on ARMv4 CPU's, and it's wo
Hi!
> 6. You have a significant lack of data regarding embedded systems, which is
> one of the two biggest segments of Linux's market share. You list no
> results for any pre-ARMv6 systems (Linux still runs on and is regularly used
> on ARMv4 CPU's, and it's worth also pointing out that the value
On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote:
> On 2016-06-20 14:32, Stephan Mueller wrote:
> >
> > [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
> Specific things I notice about this:
> 1. QEMU systems are reporting higher values than almost anything
> else
> with the
Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-20 14:32, Stephan Mueller wrote:
> > Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
> >
> > Hi Austin,
> >
> >> On 2016-06-18 12:31, Stephan Mueller wrote:
> >>> Am Samstag, 18. Juni 201
On 2016-06-20 14:32, Stephan Mueller wrote:
Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
Hi Austin,
On 2016-06-18 12:31, Stephan Mueller wrote:
Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
Hi Theodore,
At the end of the day, with these devices you really b
Hi,
On So, 2016-06-18 at 10:44 -0400, Theodore Ts'o wrote:
> On Fri, Jun 17, 2016 at 03:56:13PM +0200, David Jaša wrote:
> > I was thinking along the lines that "almost every important package
> > supports FreeBSD as well where they have to handle the condition so
> > option to switch to Rather Br
Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn:
Hi Austin,
> On 2016-06-18 12:31, Stephan Mueller wrote:
> > Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
> >
> > Hi Theodore,
> >
> >> At the end of the day, with these devices you really badly need a
> >> hardware
On 2016-06-18 12:31, Stephan Mueller wrote:
Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
Hi Theodore,
At the end of the day, with these devices you really badly need a
hardware RNG. We can't generate randomness out of thin air. The only
thing you really can do requires user sp
Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
Hi Theodore,
>
> At the end of the day, with these devices you really badly need a
> hardware RNG. We can't generate randomness out of thin air. The only
> thing you really can do requires user space help, which is to generate
> keys l
On Fri, Jun 17, 2016 at 03:56:13PM +0200, David Jaša wrote:
> I was thinking along the lines that "almost every important package
> supports FreeBSD as well where they have to handle the condition so
> option to switch to Rather Break Than Generate Weak Keys would be nice"
> - but I didn't expect t
Am Freitag, 17. Juni 2016, 11:26:23 schrieb Sandy Harris:
Hi Sandy,
> David Jaša wrote:
> > BTW when looking at an old BSI's issue with Linux urandom that Jarod
> > Wilson tried to solve with this series:
> > https://www.spinics.net/lists/linux-crypto/msg06113.html
> > I was thinking:
> > 1) wou
Am Freitag, 17. Juni 2016, 15:56:13 schrieb David Jaša:
Hi David,
> Hi Stephan,
>
> thank you for your thorough reply,
>
> On St, 2016-06-15 at 18:58 +0200, Stephan Mueller wrote:
> > Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša:
> >
> > Hi David,
> >
> > > Hello Stephan,
> > >
>
David Jaša wrote:
>
> BTW when looking at an old BSI's issue with Linux urandom that Jarod
> Wilson tried to solve with this series:
> https://www.spinics.net/lists/linux-crypto/msg06113.html
> I was thinking:
> 1) wouldn't it help for large urandom consumers if kernel created a DRBG
> instance f
Hi Stephan,
thank you for your thorough reply,
On St, 2016-06-15 at 18:58 +0200, Stephan Mueller wrote:
> Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša:
>
> Hi David,
>
> > Hello Stephan,
> >
> > Did you consider blocking urandom output or returning error until
> > initialized? Given
Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša:
Hi David,
> Hello Stephan,
>
> Did you consider blocking urandom output or returning error until
> initialized? Given the speed of initialization you report, it shouldn't
> break any userspace apps while making sure that nobody uses predic
Hello Stephan,
Did you consider blocking urandom output or returning error until
initialized? Given the speed of initialization you report, it shouldn't
break any userspace apps while making sure that nobody uses predictable
pseudoranom numbers.
I was considering asking for patch (or even trying
I'll be a while going through this.
I was thinking about our earlier discussion where I was hammering on
the point that compressing entropy too early is a mistake, and just
now realized that I should have given you credit for my recent 4.7-rc1
patch 2a18da7a. The hash function ("good, fast AND ch
27 matches
Mail list logo
