On Tue, May 12, 2020 at 11:18:02AM -0400, Terry Moore wrote:
> A useful definition requires that third-party code will not have surprising
> security defects compared to their operation on other operating systems.
There are other concerns for whether third party code works well..
I'll just copy w
On Tue, May 12, 2020 at 12:37:57PM +, nia wrote:
> These use arandom exclusively on NetBSD:
> - gnutls (via nettle _rnd_get_system_entropy)
> Prefers getentropy and only uses getrandom if there's no getentropy.
> - openssl (syscall_random)
> Prefers getentropy and only uses getrandom if the
[trimming cc list to tech-crypto]
> Date: Tue, 12 May 2020 11:45:58 -0400
> From: Thor Lancelot Simon
>
> 1) It's hard to understand how many bits of entropy to assign to a
>sample from one of these sources. [...]
>
>The delta estimator _was_ good for these things, particularly for
>
On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote:
>
> Adding more sources could mean
> reintroducing some timing based sources after careful analysis, but
> also things like having the installer install an initial random seed
> on the target machine (and if the installer itself la
jo...@bec.de (Joerg Sonnenberger) writes:
>Please think what that statement means. Consider for fun emulating a 20
>year old computer with a deterministic high precision model keeping all
>storage in memory. There is no source of entropy in such a system and no
>way for the emulation to tell.
Sad
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
On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote:
> I don't particularly care if we require 100 or 384 bits of estimated
> entropy, nor do I particularly care if the entropy estimate of a
> keystroke timestamp is 0 or 1 bit. But I do very much care that if I
> accidentally try to
nia wrote:
> I disagree that measuring "full entropy" is something that's possible
> to do in a sane, fair, or uncontroversial way.
Advocating the use of /dev/urandom and its equivalents on that basis
basically boils down to "because we can't agree on what level of
security we should require or ho
On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote:
> This unfortunate situation should be addressed by providing more
> entropy sources, not by burying our heads in the sand and pretending
> we have entropy when we don't. Adding more sources could mean
> reintroducing some timing
I have changed the subject line since this is veering off the original
topic.
Martin Husemann wrote:
> On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote:
> > we have entropy when we don't. Adding more sources could mean
> > reintroducing some timing based sources after careful an
On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote:
> we have entropy when we don't. Adding more sources could mean
> reintroducing some timing based sources after careful analysis, but
> also things like having the installer install an initial random seed
> on the target machine (
nia wrote:
> > For the OpenBSD strategy to work, the system needs to actually refuse
> > to run if the seed can't be loaded (or full entropy achieved in some
> > other way). NetBSD doesn't do that. As long as there is any way
> > userland can start before full entropy has been achieved, all APIs
12 matches
Mail list logo
