Gunnar Wolf gwolf at gwolf.org writes:
using entropy to seed a PRNG, if you have several shitty entropy
sources and one _really_ good one, and you xor them all together, the
resulting output is as random as the best of them. If your hardware
Your theory may be good, but we are talking about a
Thorsten Glaser t...@debian.org writes:
Your theory may be good, but we are talking about a scenario in which at
least one of the other sources may be not just “shitty entropy” but “a
bytestream specifically designed to counteract entropy in the output
stream of the XOR” (independence is
On 6/13/14, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Jun 13, 2014 at 06:51:44PM +, Jacob Appelbaum wrote:
I would expect that if the NSA wanted to take control of the RDRAND or
the rest of the CPU, they'd dynamically update the microcode in the
CPU to change how it behaves. To do this,
On Fri, 13 Jun 2014, Joey Hess wrote:
Henrique de Moraes Holschuh wrote:
Now, the kernel can soft-blacklist RDRAND (and RDSEED) usage[2]. In that
case, the kernel won't use it and it disappears from /proc/cpuinfo, and we
could do that also to avoid processor errata, not just due to user
On 13 June 2014 06:27, Gunnar Wolf gw...@gwolf.org wrote:
Excuse me if I'm blunt here, but I understand that, on the point of
using entropy to seed a PRNG, if you have several shitty entropy
sources and one _really_ good one, and you xor them all together, the
resulting output is as random
Martijn van Oosterhout dijo [Fri, Jun 13, 2014 at 10:09:02AM +0200]:
Excuse me if I'm blunt here, but I understand that, on the point of
using entropy to seed a PRNG, if you have several shitty entropy
sources and one _really_ good one, and you xor them all together, the
resulting output
On Wed, 11 Jun 2014, Joey Hess wrote:
I don't have a stong opinion on the security of RDRAND, which is a
contentious topic in a domain I am not expert in. However, I would much
rather rely on linux developers to make the right decision on that,
rather than libraries deciding on an ad-hoc
On Fri, Jun 13, 2014 at 10:09:02AM +0200, Martijn van Oosterhout wrote:
Excuse me if I'm blunt here, but I understand that, on the point of
using entropy to seed a PRNG, if you have several shitty entropy
sources and one _really_ good one, and you xor them all together, the
resulting
Henrique de Moraes Holschuh wrote:
Now, the kernel can soft-blacklist RDRAND (and RDSEED) usage[2]. In that
case, the kernel won't use it and it disappears from /proc/cpuinfo, and we
could do that also to avoid processor errata, not just due to user request.
However, AFAIK kernel blacklisting
On 6/13/14, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Jun 13, 2014 at 10:09:02AM +0200, Martijn van Oosterhout wrote:
Excuse me if I'm blunt here, but I understand that, on the point of
using entropy to seed a PRNG, if you have several shitty entropy
sources and one _really_ good one, and
Joey Hess wrote:
int cpu_has_rdrand()
{
uint32_t ax,bx,cx,dx,func=1;
__asm__ volatile (cpuid:\
=a (ax), =b (bx), =c (cx), =d (dx) : a (func));
return (cx 0x4000);
}
That's actually buggy on any platform building position-independent code
(common with hardened
On Fri, Jun 13, 2014 at 06:51:44PM +, Jacob Appelbaum wrote:
I would expect that if the NSA wanted to take control of the RDRAND or
the rest of the CPU, they'd dynamically update the microcode in the
CPU to change how it behaves. To do this, it appears that they'd need
to sign a microcode
Joey Hess wrote:
Josh Triplett wrote:
However, just as we encourage projects to reuse libraries rather than
copying code around, we *should* encourage projects to use standardized
randomness libraries rather than hardcoding rdrand (or, for that matter,
hardcoding /dev/urandom).
Hi,
Steve Langasek:
Debian should do the right thing, regardless of what upstreams may believe.
I don't trust the hardware random generator. At all. Given what's been
revealed about the NSA so far, being extra paranoid about anything we
cannot verify to be secure is the right thing to do.
On Wed, 11 Jun 2014, Josh Triplett wrote:
Any program desiring high-performance random numbers has a good reason to use
RDRAND or RDSEED: they produce randomness *far* faster than the kernel, and
Yes, because SIGILL is so much faster…
Anyway. Even on systems supporting RDRAND, user space
At Thu, 12 Jun 2014 08:36:16 +0200,
Matthias Urlichs wrote:
That being said, sometimes you just need the binary equivalent of an
uncompressible Lorem Ipsum text (dd if=/dev/urandom), but IMHO the kernel
could (and should) provide a device for that.
If you just want to overwrite something with
Josh Triplett j...@joshtriplett.org writes:
At least two reasons: because a random number source that doesn't
require kernel privileges should not need to take the performance hit of
going through the kernel,
I'm very dubious that this performance hit is substantial enough that it
should have
On Thu, Jun 12, 2014 at 10:19:37AM -0700, Russ Allbery wrote:
I've never seen a convincing argument that the kernel /dev/random is
likely to be *less* secure than the hardware random number generator.
It's either more secure or the same level of security. Given that, it's a
risk analysis, and
On Thu, Jun 12, 2014 at 10:23:58AM +0200, Thorsten Glaser wrote:
On Wed, 11 Jun 2014, Josh Triplett wrote:
device is inferiour to the random devices on OpenBSD/MirBSD, so you
should seed the aRC4 state with additional random bytes:
As far as I know, OpenBSD stopped using (A)RC4 for their
Hi!
On Thu, 2014-06-12 at 21:19:06 +0200, Kurt Roeckx wrote:
On Thu, Jun 12, 2014 at 10:23:58AM +0200, Thorsten Glaser wrote:
On Wed, 11 Jun 2014, Josh Triplett wrote:
device is inferiour to the random devices on OpenBSD/MirBSD, so you
should seed the aRC4 state with additional random
Kurt Roeckx dixit:
As far as I know, OpenBSD stopped using (A)RC4 for their random
number generation for good reason, even though the function is
They stopped, but not for good reason. But you can also use the
new unlicenced algorithm they use, if you really feel like it,
it’s not bad either,
Theodore Ts'o wrote:
On Thu, Jun 12, 2014 at 10:19:37AM -0700, Russ Allbery wrote:
I've never seen a convincing argument that the kernel /dev/random is
likely to be *less* secure than the hardware random number generator.
It's either more secure or the same level of security. Given that,
Josh Triplett j...@joshtriplett.org writes:
If you don't trust a hardware random number generator, you should not
xor it and another random number source together; after all, if you
believe the numbers coming out of the hardware random source are not
actually random, you might just as easily
Russ Allbery dijo [Thu, Jun 12, 2014 at 07:08:40PM -0700]:
If you don't trust a hardware random number generator, you should not
xor it and another random number source together; after all, if you
believe the numbers coming out of the hardware random source are not
actually random, you
Gunnar Wolf gw...@gwolf.org writes:
Russ Allbery dijo [Thu, Jun 12, 2014 at 07:08:40PM -0700]:
I would certainly hope that the mixing algorithm of any decent random
number source is better than just xor. And given that, I don't believe
the mathematics supports your assertion here. It's
Ugh, sorry to follow up to myself, but I got a key part of this wrong.
Russ Allbery r...@debian.org writes:
At least based on my understanding of the theory, I think that mixing a
backdoored entropy source with other entropy sources in a random number
generator like Fortuna (which is based on
I stumbled over a library which has switched to using RDRAND in a new
upsteam version (not yet packaged), instead of /dev/urandom[1].
I don't have a stong opinion on the security of RDRAND, which is a
contentious topic in a domain I am not expert in. However, I would much
rather rely on linux
Joey Hess wrote:
I stumbled over a library which has switched to using RDRAND in a new
upsteam version (not yet packaged), instead of /dev/urandom[1].
I don't have a stong opinion on the security of RDRAND, which is a
contentious topic in a domain I am not expert in. However, I would much
On 6/11/14, Joey Hess jo...@debian.org wrote:
I stumbled over a library which has switched to using RDRAND in a new
upsteam version (not yet packaged), instead of /dev/urandom[1].
Which library is using it?
I don't have a stong opinion on the security of RDRAND, which is a
contentious topic
On Wed, Jun 11, 2014 at 03:46:07PM -0700, Josh Triplett wrote:
Would it make sense to scan for the opcode?
No, let's not propagate this issue outside the kernel. Anyone wishing to
complain about the use of hardware-accelerated randomness should argue that
upstream with projects that adopt
Josh Triplett wrote:
However, just as we encourage projects to reuse libraries rather than
copying code around, we *should* encourage projects to use standardized
randomness libraries rather than hardcoding rdrand (or, for that matter,
hardcoding /dev/urandom).
Performance aside, why is a
Jacob Appelbaum wrote:
On 6/11/14, Joey Hess jo...@debian.org wrote:
I stumbled over a library which has switched to using RDRAND in a new
upsteam version (not yet packaged), instead of /dev/urandom[1].
Which library is using it?
I didn't want to name names and am more interested in the
32 matches
Mail list logo
