> In addition, the notion of "entropy being consumed" is obsolete (if it was e$
Oh, it most certainly was, and is, a valid notion. It may currently
appear that the state of the art in PRNGs is good enough that you can
stream unlimited amounts of key material once you have enough entropy
on hand,
> "Just get a 128GB RAM 32 core machine like me, and then you can use
> netbsd"
Hasn't that been NetBSD's stance since 2011-03-30? (Okay, it's an
exaggeration, but not all that much of an exaggeration.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
On Sun, Jul 21, 2019 at 08:50:30PM +, paul.kon...@dell.com wrote:
> /dev/urandom is equivalent to /dev/random if there is adequate entropy,
> but it will also deliver random numbers not suitable for cryptography before
> that time.
This is somewhat misleading. The problem is that with an
TRC> There is no reason in modern cryptography to read more than one byte
TRC> from /dev/random ever in a single application; once you have done
TRC> that, or confirmed some other way that the the entropy pool is seeded,
TRC> you should generate keys from /dev/urandom.
DAH> There should be some
> On Jul 21, 2019, at 3:20 PM, Taylor R Campbell
> wrote:
>
>
> [EXTERNAL EMAIL]
>
>> Date: Sun, 21 Jul 2019 20:52:52 +0200
>> From: Manuel Bouyer
>>
>> /dev/randon actually works as documented and if rust wants /dev/urandom
>> behavior it should use /dev/urandom. Also I'd like to get
On Sun, Jul 21, 2019 at 07:20:08PM +, Taylor R Campbell wrote:
> > Date: Sun, 21 Jul 2019 20:52:52 +0200
> > From: Manuel Bouyer
> >
> > /dev/randon actually works as documented and if rust wants /dev/urandom
> > behavior it should use /dev/urandom. Also I'd like to get explained why
> > a
On Sun, Jul 21, 2019 at 06:57:30PM +, m...@netbsd.org wrote:
> On Sun, Jul 21, 2019 at 08:52:52PM +0200, Manuel Bouyer wrote:
> > On Sun, Jul 21, 2019 at 06:43:04PM +, m...@netbsd.org wrote:
> > > On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> > > > Another approach,
On Sun, Jul 21, 2019 at 07:20:08PM +, Taylor R Campbell wrote:
> This is _locally_ sensible for a library that may have many users
> beyond a compiler.
No, it can be sensible behavior to allow *optionally* checking. But it
is certainly not sensible default behavior for a library.
Joerg
> Date: Sun, 21 Jul 2019 20:52:52 +0200
> From: Manuel Bouyer
>
> /dev/randon actually works as documented and if rust wants /dev/urandom
> behavior it should use /dev/urandom. Also I'd like to get explained why
> a compiler needs that much random bits.
The difference is that /dev/random may
On Sun, Jul 21, 2019 at 08:52:52PM +0200, Manuel Bouyer wrote:
> On Sun, Jul 21, 2019 at 06:43:04PM +, m...@netbsd.org wrote:
> > On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> > > Another approach, harder, is to create a xenrnd(4) pseudodevice and
> > > hypervisor call that
On Sun, Jul 21, 2019 at 06:43:04PM +, m...@netbsd.org wrote:
> On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> > Another approach, harder, is to create a xenrnd(4) pseudodevice and
> > hypervisor call that gets bits from the host's /dev/random and injects
> > them as if from a
On Sun, Jul 21, 2019 at 11:55:23AM -0400, Greg Troxel wrote:
> Another approach, harder, is to create a xenrnd(4) pseudodevice and
> hypervisor call that gets bits from the host's /dev/random and injects
> them as if from a hardware rng.
>
>
That requires the ability coordinate "please run this
On Sun, Jul 21, 2019 at 04:53:08PM +, Taylor R Campbell wrote:
> It has become popular to redefine the traditional semantics of
> /dev/random or /dev/urandom so that one or both will block once at
> boot until the OS thinks the entropy pool may have been seeded, and
> then never block
g...@lexort.com (Greg Troxel) writes:
>Another approach, harder, is to create a xenrnd(4) pseudodevice and
>hypervisor call that gets bits from the host's /dev/random and injects
>them as if from a hardware rng.
There is a virtio-rng, implementing that interface would be compatible
with other
> Date: Sun, 21 Jul 2019 11:55:23 -0400
> From: Greg Troxel
>
> I don't think we should change /dev/random. For a very long time, the
> notion is that the bits from /dev/random really are ok for keys, and
> there has been a notion that such bits are precious and you should be
> prepared to
> Date: Sun, 21 Jul 2019 17:28:17 +0200
> From: Martin Husemann
>
> Replacing the /dev/random device node by a symlink to /dev/urandom sounds
> fine. For binaries it is easy to just use the sysctl instead to get high
> quality randomness. Are there any shell script like applications that
>
I don't think we should change /dev/random. For a very long time, the
notion is that the bits from /dev/random really are ok for keys, and
there has been a notion that such bits are precious and you should be
prepared to wait. If you aren't generating a key, you shouldn't read
from /dev/random.
On Sun, Jul 21, 2019 at 02:41:57PM +, co...@sdf.org wrote:
> hi,
>
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
Replacing the /dev/random device node by a symlink to /dev/urandom
On Sun, 21 Jul 2019 15:05:53 +
co...@sdf.org wrote:
> Rust reads a byte from /dev/random before deciding it's OK to read
> /dev/urandom. We are told this is the correct behaviour and that we
> shouldn't upstream "just use /dev/urandom/sysctl equivalent".
Who says this is correct behaviour?
On 21.07.2019 16:53, Kamil Rytarowski wrote:
> On 21.07.2019 16:41, co...@sdf.org wrote:
>> hi,
>>
>> since netbsd won't stop using broken setups like xen (which don't
>> provide randomness) to build packages, why don't we give up on
>> /dev/random entirely?
>>
>
> /dev/random is not defined in
I'm just pissed off with the current status quo that we tolerate
everything being broken.
AMD CPUs do not provide hardware RNG.
NVMe isn't used as an RNG source because it would slow it down too much.
netbsd/xen never heard about RNG. Or monotonic time. Why are we using
this to build packages?!
On 21.07.2019 16:41, co...@sdf.org wrote:
> hi,
>
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
>
/dev/random is not defined in POSIX.
> since netbsd won't stop using broken setups like xen (which don't
> provide randomness) to build packages, why don't we give up on
> /dev/random entirely?
As in, remove it from everyone's /dev and kernel, or stop using it for
package builds, or get rid of it from NetBSD/xen's /dev, or what?
I
hi,
since netbsd won't stop using broken setups like xen (which don't
provide randomness) to build packages, why don't we give up on
/dev/random entirely?
24 matches
Mail list logo
