tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: cprng_fast implementation benchmarks



On Thu, Apr 24, 2014 at 07:23:41PM +0000, Paul_Koning%Dell.com@localhost wrote:
> 
> I do disagree.  The reason is that I see no requirements that make it
> possible to decide whether the weak generator is useful.

Here are some cases where the "fast" CPRNG is used:

        1) Generation of ip_id values
        2) Generation of ephemeral port numbers
        3) Generation of explicit IVs for use in cryptographic network
           protocols
        4) Randomization of addresses for mappings of userspace processes
        5) Generation of the random "canary" used by the userspace stack
           smash protection code

I think these cases have some things in common and we can begin to intuit
some general rules from them.

It seems to me that we are generally looking at cases where:

        * The value of the resource directly being protected is ephemeral

        * An active attack is required in order to exploit any weakness
          in the RNG

        * The constant factor for an adversary to attack the RNG
          is quite large (for example, making a process crash across the
          network)

        * Nonetheless attacks on non-cryptographic RNGs have been empirically
          sucessful in all of these cases.

I don't think anyone knows much about how to design a RNG that's "just strong
enough" even if we had a much more detailed threat model (though one might
argue that one could keep subtracting rounds from ChaCha and arrive at ChaCha4
or so forth; and there is the intriguing suggestion to be found various places
that, in fact, the NSA does do things very much like this, with Skipjack
having been designed to be just as strong as it needed to be and no stronger).

But we do know how to select an RNG that meets some minimum strength criteria
and is faster than the "fast" RNG we already have.  And that is what we are
doing in this discussion.

Thor


Home | Main Index | Thread Index | Old Index