6 ms·

> The getrandom(2) system call was requested by the LibreSSL Portable > developers. It is analoguous to the getentropy(2) system call in > OpenBSD. Oh the

by kps 12y ago

> The getrandom(2) system call was requested by the LibreSSL Portable > developers. It is analoguous to the getentropy(2) system call in > OpenBSD. Oh the joy of NIH.

aylons 12y ago
I didn't understand what you meant by you commentary. The above excerpt shows they assuming upfront that they got the idea from BSD. As a system call is not an application that may be ported, they need to recode it. If the point was the name change, I guess this is only to keep consistency within the system, and far from a problem.
- tptacek 12y ago
  They took the sane design from BSD ("here's a single system call that gives you crypto-safe entropy") and effectively made a family of system calls that replicate all the pointless drama of /dev/random and urandom. The NIH criticism is valid.
  - clarry 12y ago
    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/msg00120.html https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms...
    - MichaelGG 12y ago
      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.
deleted 12y ago
[deleted]
yxhuvud 12y ago
If they are not able to get the exact semantics of the getentropy call, then a namechange is perfectly justified.
killertypo 12y ago
if your job is providing security and GOOD security relies on GOOD entropy i fail to see the issue...
neckbeard 12y ago
Keep reading the thread - Ted explains that decision.
kllrnohj 12y ago
Oh the joy of not reading the thread. > The getrandom(2) system call is a superset of getentropy(2). > The reason for the additional flags is that I'm trying to solve more problems than just getentropy()'s raison d'etre. And you can implement getentropy(2) on top of getrandom(2) if you so desire, which they plan to do in glibc. http://lists.openwall.net/linux-kernel/2014/07/17/682 http://lists.openwall.net/linux-kernel/2014/07/17/682

by kps 12y ago

> The getrandom(2) system call was requested by the LibreSSL Portable > developers. It is analoguous to the getentropy(2) system call in > OpenBSD. Oh the joy of NIH.

aylons 12y ago

I didn't understand what you meant by you commentary. The above excerpt shows they assuming upfront that they got the idea from BSD. As a system call is not an application that may be ported, they need to recode it. If the point was the name change, I guess this is only to keep consistency within the system, and far from a problem.

tptacek 12y ago
They took the sane design from BSD ("here's a single system call that gives you crypto-safe entropy") and effectively made a family of system calls that replicate all the pointless drama of /dev/random and urandom. The NIH criticism is valid.
- clarry 12y ago
  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/msg00120.html https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms...
  - MichaelGG 12y ago
    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.

deleted 12y ago

[deleted]

yxhuvud 12y ago

If they are not able to get the exact semantics of the getentropy call, then a namechange is perfectly justified.

killertypo 12y ago

if your job is providing security and GOOD security relies on GOOD entropy i fail to see the issue...

neckbeard 12y ago

Keep reading the thread - Ted explains that decision.

kllrnohj 12y ago

Oh the joy of not reading the thread. > The getrandom(2) system call is a superset of getentropy(2). > The reason for the additional flags is that I'm trying to solve more problems than just getentropy()'s raison d'etre. And you can implement getentropy(2) on top of getrandom(2) if you so desire, which they plan to do in glibc. http://lists.openwall.net/linux-kernel/2014/07/17/682 http://lists.openwall.net/linux-kernel/2014/07/17/682