News for hackers. Stuff that matters.

A comment on The getrandom(2) system call was requested by the LibreSSL Portable developers. Parent comment

Re:The getrandom(2) system call was requested by the LibreSS... by clarry on Thursday July 17, 2014 @04:37PM (#8050067)
It seems pointless indeed. On the other hand, I'm almost glad the overengineering only went that far. Actually I'm expecting much worse after reading Theodore's ideas on the IETF list.. we'll see what kind of a library interface they'll come up with, if they make something besides getentropy().

  But if we get all applications to use the same library, we can
  abstract away not only differences in operating system but also
  security policies vis-a-vis DRBG/NDRBG blocking/nonblocking.  So what
  *I* would prefer is a library interface where the application declares
  what it wants the random numbers for:

  * Monte carlo simulations
  * Padding
  * IV
  * Session key
  * long-term key

  etc.  The library can then decide whether or not the overall system
  policy should force application to block when generating long-term
  keys, ala gpg, or whether it should getting non-blocking entropy
  directly from the kernel, or whether using a userspace DRBG which is
  initialized from kernel-supplied entropy is the right answer.
From https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms...
[ Parent | on HN ]
Re:The getrandom(2) system call was requested by the LibreSS... by MichaelGG on Thursday July 17, 2014 @08:20PM (#8051027)
What is a case where a random IV needs a different entropy source than a session key?

And if we're assuming the entropy pool is being compromised (full state read by attacker) from time to time, isn't it foolish to be generating keys on such a machine? Why would new state not be compromised in he same way the previous state was? I understand the system design may want to provide a robust RNG, but further than that seems slightly pointless.

[ Parent | on HN ]