[Cryptography] randomness +- entropy
Theodore Ts'o
tytso at mit.edu
Sat Nov 9 08:59:16 EST 2013
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
More information about the cryptography
mailing list