Thorsten Glaser 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 needed).
> You’
Gunnar Wolf 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 scen
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 u
On 6/13/14, Theodore Ts'o 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, it appea
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 microco
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
(com
On 6/13/14, Theodore Ts'o 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 you
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 blacklist
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
> > resultin
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 ba
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 o
On 13 June 2014 06:27, Gunnar Wolf 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 as the best
Ugh, sorry to follow up to myself, but I got a key part of this wrong.
Russ Allbery 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 the AES bloc
Gunnar Wolf 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 considerably
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,
Josh Triplett 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 believe that they'
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 t
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, j
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
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
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,
Josh Triplett 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 an influence on ou
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 wit
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 SHA
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.
Th
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).
>
Jacob Appelbaum wrote:
> On 6/11/14, 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].
>
> Which library is using it?
I didn't want to name names and am more interested in the general
que
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
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 ado
On 6/11/14, 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].
Which library is using it?
>
> I don't have a stong opinion on the security of RDRAND, which is a
> contentious topic in a domain
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 muc
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 deve
32 matches
Mail list logo
