[148100] in cryptography@c2.net mail archive
Re: [Cryptography] randomness +- entropy
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Sun Nov 10 04:25:06 2013
X-Original-To: cryptography@metzdowd.com
Date: Sat, 9 Nov 2013 08:59:16 -0500
From: Theodore Ts'o <tytso@mit.edu>
To: ianG <iang@iang.org>
In-Reply-To: <527E18FC.8000008@iang.org>
X-SA-Exim-Mail-From: tytso@thunk.org
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Sat, Nov 09, 2013 at 02:14:04PM +0300, ianG wrote:
> Also, your use of the AES algorithm is entirely distinct to theirs.
> You only go one way, like a hash, theirs is two way, encrypt and
> decrypt, reversibly. You may be able to happily strip out parts of
> AES in order to get a better efficiency, they cannot. E.g., it may
> be possible to use less of the code and more of the AES instructions
> directly to get all you need (I don't know, I'm just speculating
> here...).
The flip side of this is that there are multiple implementations of
AES, optimized for x86, x86_32, x86 w/ the AES-NI instruction,
Sparc64, and ARM. Plus the generic AES implementation, of course.
Replicating all of this for the /dev/random driver would be a bit
painful.
One option would be to find a generic AES algorithm which is optimized
for size, as opposed to speed (so it doesn't have any assembly
instructions or pre-generated tables which would bloat the kernel text
size). For example, Ilya Levin has one[1] which compiles down to about
5k. Presumably it would be faster than the SHA-based generation
code that I'm currently using, but I haven't tried measuring its speed
on other platforms.
- Ted
[1] http://www.literatecode.com/aes256
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
