Re: [PATCH][RFC] CPU Jitter random number generator (resent)

2013-05-21 Thread Stephan Mueller
On Tue, 21 May 2013 17:39:49 -0400 Sandy Harris wrote: Hi Sandy, > On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote: > > > I continue to be suspicious about claims that userspace timing > > measurements are measuring anything other than OS behaviour. > > Yes, but they do seem to contain s

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

2013-05-21 Thread Sandy Harris
On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote: > I continue to be suspicious about claims that userspace timing > measurements are measuring anything other than OS behaviour. Yes, but they do seem to contain some entropy. See links in the original post of this thread, the havege stuff and

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

2013-05-21 Thread Theodore Ts'o
I continue to be suspicious about claims that userspace timing measurements are measuring anything other than OS behaviour. But that doesn't mean that they shouldn't exist. Personally, I believe you should try to collect as much entropy as you can, from as many places as you can. For VM's, it me

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

2013-05-21 Thread Stephan Mueller
On Tue, 21 May 2013 12:09:02 -0400 Sandy Harris wrote: Hi Sandy, > I very much like the basic notion here. The existing random(4) driver > may not get enough entropy in a VM or on a device like a Linux router > and I think work such as yours or HAVEGE ( > http://www.irisa.fr/caps/projects/hipsor

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

2013-05-21 Thread Sandy Harris
I very much like the basic notion here. The existing random(4) driver may not get enough entropy in a VM or on a device like a Linux router and I think work such as yours or HAVEGE (http://www.irisa.fr/caps/projects/hipsor/) are important research. The paper by McGuire et al of "Analysis of inheren

[PATCH 2/2] crypto: sha256_ssse3 - add sha224 support

2013-05-21 Thread Jussi Kivilinna
Add sha224 implementation to sha256_ssse3 module. This also fixes sha256_ssse3 module autoloading issue when 'sha224' is used before 'sha256'. Previously in such case, just sha256_generic was loaded and not sha256_ssse3 (since it did not provide sha224). Now if 'sha256' was used after 'sha224' usa

[PATCH 1/2] crypto: sha512_ssse3 - add sha384 support

2013-05-21 Thread Jussi Kivilinna
Add sha384 implementation to sha512_ssse3 module. This also fixes sha512_ssse3 module autoloading issue when 'sha384' is used before 'sha512'. Previously in such case, just sha512_generic was loaded and not sha512_ssse3 (since it did not provide sha384). Now if 'sha512' was used after 'sha384' usa

[PATCH] crypto: sha512_generic - set cra_driver_name

2013-05-21 Thread Jussi Kivilinna
'sha512_generic' should set driver name now that there is alternative sha512 provider (sha512_ssse3). Signed-off-by: Jussi Kivilinna --- crypto/sha512_generic.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/crypto/sha512_generic.c b/crypto/sha512_generic.c index 4c58620..6ed124f 10064

[PATCH] crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations

2013-05-21 Thread Jussi Kivilinna
The _XFER stack element size was set too small, 8 bytes, when it needs to be 16 bytes. As _XFER is the last stack element used by these implementations, the 16 byte stores with 'movdqa' corrupt the stack where the value of register %r12 is temporarily stored. As these implementations align the stac

Re: linux-next: Tree for May 15 (crypto /crct10dif)

2013-05-21 Thread Herbert Xu
On Mon, May 20, 2013 at 12:09:45PM -0700, Tim Chen wrote: > On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote: > > > > > Nope this is still broken. We need to move the actual crct10dif > > code into crypto/. I'll fix up the patch in the tree. > > > > Also I'm going to get rid of crc_t10dif_u