Re: [Cfrg] Big-key cryptography

["Grigory Marshalko" <[e-mail]>]

Hi, Aaron,

I agree that with developmnets in hardware the problem is going to be less serious on the one hand, but on the other hand we would always have enough room for suspicions :)  E.g.  https://www.alchemistowl.org/pocorgtfo/pocorgtfo03.pdf p.20 shows how linux random generation could fail in case of backdored RDRAND.
 
 

Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation "Cryptography and security mechanisms" (ТC 26)
www.tc26.ru
15 декабря 2015 г., 15:48, "Aaron Zauner" <[e-mail]> написал:
> Hi Grigory,
> 
> See also Ryan's reply.
> 
> Grigory Marshalko wrote:
> 
>> Hi Aaron,
>> 
>> I mean that when we speak about key generation we should always control the amount of entropy. So
>> the bigger the key the more entropy we need. That is the main problem in this approach - how to
>> generate the initial key/state (By pool I mean entropy pool like in Fortuna RBG).
>> Regards,
> 
> Generation of "randomness" is not really a big issue anymore (at least
> on Linux - probably pretty similar on other Operating Systems). These
> days modern Intel Chips come with a RDRAND instruction that is mixed
> into the pool (with many other inputs, e.g. IRQs). RDRAND
> 
> ```
> The RDSEED instruction was added to Intel Secure Key for seeding another
> pseudorandom number generator,[16] available in Broadwell CPUs. The
> entropy source for the RDSEED instruction runs asynchronously on a
> self-timed circuit and uses thermal noise within the silicon to output a
> random stream of bits at the rate of 3 GHz.
> ``` -- https://en.wikipedia.org/wiki/RdRand
> 
> If you're really clever you could do something like how BoringSSL seeds:
> ```
> TLS servers that are pushing lots of AES-CBC need the RNG to be really
> fast because each record needs a random IV. Because of this, if
> BoringSSL detects that the machine supports Intel's RDRAND instruction,
> it'll read a seed from urandom, expand it with ChaCha20 and XOR entropy
> from RDRAND. The seed is thread-local and refreshed every 1024 calls or
> 1MB output, whichever happens first.
> ``` -- https://www.imperialviolet.org/2015/10/17/boringssl.html
> 
> HTH,
> Aaron