search for: csprng

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a legacy interface which dates back to a time when people didn't have as much trust in...

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a legacy interface which dates back to a time when people didn't have as much trust in...

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 15:12:30 +0200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 15:12:30 +0200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's

...u assume that getrandom works like /dev/random. This is not the > case. It is a full deterministic RNG like /dev/urandom (which is > seeded during its operation as entropy is available). My understanding was that all three methods of obtaining entropy from userspace all receive data from the CSPRNG in the kernel, and that the only difference is that /dev/random and getrandom may block depending on the kernel's estimate of the currently available entropy. > getrandom *only* differs from /dev/*u*random in that it waits > initially such that the system collected 128 bits of entropy....

v2: - Fix seeding. - Add a test that nbdkit-random-plugin is producing something which looks at least somewhat random. Rich.

...hat's worth). Attacker 2 seems like the only situation where choice of PRNG might actually matter in practice. Are there other classes of attackers you have in mind? Of course, AES is _really_ fast [4] and in general, for a security application, I can't think of a good reason not to use a CSPRNG when random numbers are warranted. 1. http://users.ece.cmu.edu/~ejschwar/papers/usenix11.pdf 2. http://www.reteam.org/papers/e59.pdf 3. http://www.isg.rhul.ac.uk/tls/TLStiming.pdf 4. http://cr.yp.to/aes-speed/aesspeed-20080926.pdf -- Stephen Checkoway

...state. > + * > + * This is based on the xoshiro/xoroshiro generators by David Blackman > + * and Sebastiano Vigna at http://xoshiro.di.unimi.it/ . Specifically > + * this is ‘xoshiro256** 1.0’. > + * > + * This does _NOT_ generate cryptographically secure random numbers > + * (CSPRNG) and so should not be used when cryptography or security is > + * required - use gcrypt if you need those. > + */ > + > +/* You can seed ‘struct random_state’ by setting the s[] elements > + * directly - but not you must NOT set it all to zero. OR if you have s/not you/note you/ &...

...om numbers, quickly, with explicit state. + * + * This is based on the xoshiro/xoroshiro generators by David Blackman + * and Sebastiano Vigna at http://xoshiro.di.unimi.it/ . Specifically + * this is ‘xoshiro256** 1.0’. + * + * This does _NOT_ generate cryptographically secure random numbers + * (CSPRNG) and so should not be used when cryptography or security is + * required - use gcrypt if you need those. + */ + +struct random_state { + uint64_t s[4]; +}; + +static inline uint64_t +rotl (const uint64_t x, int k) +{ + return (x << k) | (x >> (64 - k)); +} + +/* Returns 64 random bits...

...om numbers, quickly, with explicit state. + * + * This is based on the xoshiro/xoroshiro generators by David Blackman + * and Sebastiano Vigna at http://xoshiro.di.unimi.it/ . Specifically + * this is ‘xoshiro256** 1.0’. + * + * This does _NOT_ generate cryptographically secure random numbers + * (CSPRNG) and so should not be used when cryptography or security is + * required - use gcrypt if you need those. + */ + +/* You can seed ‘struct random_state’ by setting the s[] elements + * directly - but not you must NOT set it all to zero. OR if you have + * a 64 bit seed, you can use xsrandom below to...

On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote: > > > We would also include a secure random number generator which links >> > against OpenSSL. This would of course be an optional module disabled >> > by default, but is necessary so the randomization is cryptographically >> > secure and useful in security applications.

> > We would also include a secure random number generator which links > > against OpenSSL. This would of course be an optional module disabled > > by default, but is necessary so the randomization is cryptographically > > secure and useful in security applications. > > I am not sure why you need this feature. You can provide LLVM with a > SEED value that can be