tech-userlevel archive

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

RE: getrandom and getentropy

Andress Gustaffson wrote

> But I do very much care that if I
> accidentally try to generate an ssh key on a system that has no
> entropy at all, it must not succeed.

This above example is a question about ssh, not about the APIs getrandom()
or getentropy().

A kernel API cannot solve requirements of this kind. For this, you have to
look at the source of your application (ssh-keygen in this case), and you
must convince yourself that it will always use the APIs correctly on your
system. (We could argue that ssh-keygen shouldn't hang -- it should exit
with an informative error message. Since security is all about guiding users
to make proper decisions, silently hanging is very likely to be the wrong
behavior in any case.)

But more generally: no kernel API can provide security, because security is
defined by the circumstances.

The question here is more of a practical one. Are getrandom() and
getentropy() (those two APIs) defined in a useful way or not?

This is a question about how third-party code will be used.

We expect that third-party code will be compiled for NetBSD.

A useful definition requires that third-party code will not have surprising
security defects compared to their operation on other operating systems.

An incredibly useful definition would cause third-party code will work
better on NetBSD than on other systems (for some definition of "better" --
in this case, less likely to use predictable random numbers).

We cannot expect that a kernel API will make defective third-party code work
acceptably on NetBSD.

NetBSD-specific code can do better than third-party code, I believe. I don't
think this discussion is intended to restrict how NetBSD research will be
restricted or constrained; just how to enable third party code to be run in
a reasonable way on NetBSD.

Best regards,

Home | Main Index | Thread Index | Old Index