On 03/03/19 17:59, Kurt Roeckx wrote:
> I think the only sane things are:
> - Use a hardware RNG (CPU, TPM, chaos key, ...)
> - Credit a seed file stored during the previous boot
> - Wait for new entropy from other sources
>
> Note that is can be a combination of all 3.
>
> We currently do not
On Sun, 2019-03-03 at 22:55 +0100, Kurt Roeckx wrote:
> On Sun, Mar 03, 2019 at 08:19:44PM +, Ben Hutchings wrote:
> > On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
> > [...]
> > > Most people will actually have at least 2 hardware RNGs: One in
> > > the CPU and one in the TPM. We can
On Sun, Mar 03, 2019 at 08:19:44PM +, Ben Hutchings wrote:
> On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
> [...]
> > Most people will actually have at least 2 hardware RNGs: One in
> > the CPU and one in the TPM. We can make the kernel trust those as
> > entropy source without using
On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
[...]
> Most people will actually have at least 2 hardware RNGs: One in
> the CPU and one in the TPM. We can make the kernel trust those as
> entropy source without using something in userspace to feed it.
> I'm not sure in the kernel has the
I think the only sane things are:
- Use a hardware RNG (CPU, TPM, chaos key, ...)
- Credit a seed file stored during the previous boot
- Wait for new entropy from other sources
Note that is can be a combination of all 3.
We currently do not credit the seed file, for various good
reasons. We
]] Thorsten Glaser
> … this was not true for me. Not before init takes over, anyway (as
> haveged does not have any initramfs integration), but we’re talking
> about “crng init done” here, not “fast init done”. In my scenario,
> haveged was started much too late in the boot to be useful (after
>
> "Thorsten" == Thorsten Glaser writes:
Thorsten> It’s not about what we feed to the kernel, but about the
Thorsten> property of it distributing the input evenly across the
Thorsten> output. The basic tenet here is that, if I have 128 bytes
Thorsten> of random input from the
Ben Hutchings dixit:
>On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
>>Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
>>> • during postinst, creates a 128-byte random seed file in /
>>
>>Can you confirm that this is done with data from
&
Sebastian Andrzej Siewior dixit:
>so I have one older box that suffers from that. I installed haveged and
>seemed to went away:
I tried that, after the suggestion to use haveged went up, but…
>As far as I understand, it would reach the "init done" state before
>systemd took over, right?
… this
> "Ben" == Ben Hutchings writes:
>> If the seed > files used in two different boots are somewhat
>> correlated, and the > entropy estimation doesn't account for
>> that, the output of /dev/random > may also be somewhat correlated
>> between the boots, which is not > supposed
On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
[...]
> > to initialise a stretching RNG (arc4random)
>
> Why are you feeding this through a separate hashing function rather
> than letting the kernel PRNG's hasher do it ? I am seriously
> unconvinced that arc4random is a good idea
On Thu, 2019-02-28 at 11:56 +, Ian Jackson wrote:
> Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> > On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > > Generally you don't ever
> > > need to use /dev/random instead of /dev/urandom un
Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
> • during postinst, creates a 128-byte random seed file in /
Can you confirm that this is done with data from
getrandom(,,GRND_RANDOM) ? (Presumably with GRND_NONBLOCK too.)
> – after the root filesystem is read-writ
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
>> Ben Hutchings writes: >[Someone:] >> The
>> additional entropy gathered is for extra safety; it is
Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > Generally you don't ever
> > need to use /dev/random instead of /dev/urandom unless you make
> > assumptions about cryptograph
Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
> Ben Hutchings writes:
> >[Someone:]
> >> The additional entropy gathered is for extra safety; it is not
> >> *depended* on for basic security assumptions.
> > [...]
> It is, because t
> "Ben" == Ben Hutchings writes:
>> The additional entropy gathered is for extra safety; it is not
>> *depended* on for basic security assumptions.
Ben> [...]
Ben> It is, because the the kernel is told to treat it as providing
Ben> a certain number of bits of entropy.
I
On Tue, 2019-02-26 at 22:29 +0200, Uoti Urpala wrote:
> On Tue, 2019-02-26 at 19:10 +, Ben Hutchings wrote:
> > But if the input to the seed doesn't provide enough entropy, the seed
> > is not completely secret (that is, you can recover it with less work
> > than a brute force search). The
On Mon, 2019-02-25 at 14:36 -0500, Sam Hartman wrote:
> > > > > > "Ben" == Ben Hutchings writes:
>
> Ben> The output of the RNG may well become public, for example in
> Ben> document UUIDs. So when estimating the entropy that the new
> Ben> seed file will provide for the next boot,
> "Ben" == Ben Hutchings writes:
Ben> The output of the RNG may well become public, for example in
Ben> document UUIDs. So when estimating the entropy that the new
Ben> seed file will provide for the next boot, none of the entropy
Ben> in the old seed file should be
On 2019-02-24 19:52:59 [+], Thorsten Glaser wrote:
> tl;dr: it adds entropy during initramfs/as early as possible during
> boot *and* tells the kernel it did so, to make its crng initialised,
> and ensures a subsequent boot has a different seed, also updated
> periodically and on shutdown for
On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
[...]
> Generally you don't ever
> need to use /dev/random instead of /dev/urandom unless you make
> assumptions about cryptography failing.
[...]
I think I agree with that, but there is no way to add entropy that
unblocks getrandom() without
On Mon, 2019-02-25 at 16:48 +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
>
> >> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
> >> accredit them yet, just remembers the amount written)
> >
> >How do you determine the number of bytes here?
>
> 32 +
Ben Hutchings dixit:
>> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>> accredit them yet, just remembers the amount written)
>
>How do you determine the number of bytes here?
32 + arc4random_uniform(256 - 32 + 1)
[…]
>The major input into the new seed file contents
On Mon, 2019-02-25 at 18:27 +0200, Uoti Urpala wrote:
> Ben Hutchings wrote:
> > The major input into the new seed file contents is the old seed file
> > contents. You are adding very little entropy on x86, and possibly
> > almost none on other architectures.
> >
> > Please reconsider this, as
On Mon, Feb 25, 2019 at 03:53:09PM +, Ben Hutchings wrote:
The major input into the new seed file contents is the old seed file
contents.
Yes, I'd just drop the seed file once used, then have a scheduled job
write a new one at some point in the future if the random quality is
high enough.
On Sun, 2019-02-24 at 19:52 +, Thorsten Glaser wrote:
[...]
> I’ve written something, a linux-any package, that…
>
> • during postinst, creates a 128-byte random seed file in /
> • updates that in a daily cronjob (using same tool as during
> boot except with more bits taken from the kernel)
On Sun, 2019-02-24 at 20:10 +, Thorsten Glaser wrote:
> Hi Philipp,
>
> >FTR this is supposedly fixed on the main architectures featuring an
> RNG
> >in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which
> Ben
>
> that’s what I referred to by…
>
> >>• it does not use/add CPU
On 24/02/2019 20:00, Philipp Kern wrote:
On 2/24/2019 8:52 PM, Thorsten Glaser wrote:
In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during boot; a
message “random: crng init
Uoti Urpala dixit:
>entropy to be secure. Consider the following scenario:
>
>Daemon
There are no daemons running at that time. This is run in
initramfs, just after the root filesystem has been mounted,
with no background tasks save udev running, and network has
not been set up (unless NFS or
Hi Philipp,
>FTR this is supposedly fixed on the main architectures featuring an RNG
>in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which Ben
that’s what I referred to by…
>>• it does not use/add CPU RNG output where present
>> ‣ though Linux can now do that itself, some
On 2/24/2019 8:52 PM, Thorsten Glaser wrote:
> In buster/sid, I noticed a massive delay booting up my laptop
> and some virtual machines, which was reduced by hitting the
> Shift and Ctrl keys multiple times randomly during boot; a
> message “random: crng init done” would appear, and boot would
>
Hello fellow developers (and some users),
I would like to present a recent (this week) project of mine.
Background story:
In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during
33 matches
Mail list logo
