[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