[Cryptography] randomness +- entropy

[ianG]

On 9/11/13 16:59 PM, Theodore Ts'o wrote:
> 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.


Ah, point.  You pointed out earlier that AES was attractive because of 
the AES-NI instruction ... which indicates a desire for speed.

I'm not sure about the need for speed here.  I can't see the motivation 
for it at all in pure RN project terms, it seems to just be the normal 
obsession of programmers?

(In amusing contrast, many were sold on DRBG_EC, because it was slower, 
in part...)

Also, it seems the preference to many is to block while not receiving 
quality RNs;  is speed really an issue?

> 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.


Presumably, if your need is only for whitening the output, you could 
also look at SHA3.  The core algorithm comes from the same team (or 
close) and it has a lot of flexibility in its sponge construction that 
might help it play a bigger part.  It should be faster than AES.


> [1] http://www.literatecode.com/aes256

iang