I don't see any general solution that is both correct and easy.
I don't think there is one.
In an ideal world all our computers would have a trusted source of true
randomness. In practice that is not the case. Older computers don't have a
hardware random number generator at all and newer compu
On Mon, May 14, 2018 at 03:11:30AM +0100, Ben Hutchings wrote:
> On Sun, 2018-05-13 at 23:48 +0300, Adrian Bunk wrote:
>...
> > Due to the gdm bugs mentioned above we know that there are real-life
> > situations where gdm currently uses "random" data that might be
> > predictable.
> >
> > grep t
> "Thorsten" == Thorsten Glaser writes:
Thorsten> Adrian Bunk dixit:
>> As an example, what happens if I debootstrap and deploy the
>> resulting filesytem to a large number of identical embedded
>> systems without entropy sources?
Thorsten> Just get into a habit of not do
On Sun, 2018-05-13 at 23:48 +0300, Adrian Bunk wrote:
> On Wed, May 09, 2018 at 11:46:00PM +0100, Ben Hutchings wrote:
[...]
> > # Options for a new fix
> >
> > It is unlikely that any further fix will be forthcoming on the kernel
> > side, so I believe that we need to do one of:
> >
> > 1. Add e
(Quoting somewhat out of order)
On Sun, May 13, 2018 at 09:23:39PM +, Thorsten Glaser wrote:
>
> It’s also no solution for the arc4random API… seems like a cultural
> clash (BSD expectations vs. what Linux can actually deliver).
It's instructive to look how OpenBSD solves this problem. OpenB
Theodore Y. Ts'o dixit:
>that problems helps most of our users, and we shouldn't let the
>perfect be the enemy of the good.
Agreed. Start small, then enhance one bootloader at a time.
Or boot protocol, I assume.
>Also note that the bootloader has depend on userspace to refresh the
>seed entropy,
Adrian Bunk dixit:
>As an example, what happens if I debootstrap and deploy the resulting
>filesytem to a large number of identical embedded systems without
>entropy sources?
Just get into a habit of not doing so, for example by modifying the
image during each writing process.
Having the bootloa
On Wed, May 09, 2018 at 11:46:00PM +0100, Ben Hutchings wrote:
>...
> # Security flaw and initial fix
>
> Recently it was discovered that getrandom() could return successfully
> before the RNG was really ready to produce unpredictable data. This
> issue was designated as CVE-2018-1108, and was fi
On Sun, 2018-05-13 at 11:27 +0200, Yves-Alexis Perez wrote:
> On Wed, 2018-05-09 at 23:46 +0100, Ben Hutchings wrote:
> > It is unlikely that any further fix will be forthcoming on the kernel
> > side, so I believe that we need to do one of:
> >
> > 1. Add entropy to the kernel during boot; either
On Wed, 2018-05-09 at 23:46 +0100, Ben Hutchings wrote:
> It is unlikely that any further fix will be forthcoming on the kernel
> side, so I believe that we need to do one of:
>
> 1. Add entropy to the kernel during boot; either:
>a. Improve systemd-random-seed
>b. Recommend use of haveged
On Thu, 2018-05-10 at 10:41 -0700, Russ Allbery wrote:
> It means that the configured timeout for which it's reasonable to wait for
> randomness is centralized in one service that can set that based on
> understanding of what's necessary in practice, and timeouts to catch other
> startup problems
On Thu, May 10, 2018 at 07:30:46PM +0200, Michael Biebl wrote:
>
> So we'd shift the waiting for randomness-to-be-available from one
> service to another? I don't quite see yet, where the benefit is in that.
> What's better if a wait-for-rng-ready binary blocks on getrandom()
> instead of the krb5
On 5/10/18 7:30 PM, Michael Biebl wrote:
> So we'd shift the waiting for randomness-to-be-available from one
> service to another? I don't quite see yet, where the benefit is in that.
> What's better if a wait-for-rng-ready binary blocks on getrandom()
> instead of the krb5-kdc binary itself? We wo
Michael Biebl writes:
> Am 10.05.2018 um 19:22 schrieb Russ Allbery:
>> I may be misunderstanding the nature of the issue, but I believe that a
>> Type=oneshot service that runs a small C program that calls getrandom()
>> and then exit(0) when it returns would provide a useful facility.
>> krb5-k
Hi Russ
Am 10.05.2018 um 19:22 schrieb Russ Allbery:
> Michael Biebl writes:
>> Am 10.05.2018 um 00:46 schrieb Ben Hutchings:
>
>>> One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and
>>> also proposed that systemd could provide a wait-for-rng-ready unit to
>>> support this.
>
>
Michael Biebl writes:
> Am 10.05.2018 um 00:46 schrieb Ben Hutchings:
>> One of the krb5 maintainers (Benjamin Kaduk) favours option 2b, and
>> also proposed that systemd could provide a wait-for-rng-ready unit to
>> support this.
> What exactly would such a wait-for-rng-ready service do and how
Am 10.05.2018 um 00:46 schrieb Ben Hutchings:
> 1. Add entropy to the kernel during boot; either:
>a. Improve systemd-random-seed
>b. Recommend use of haveged
> 2. For each affected userland package, either:
>a. Revert to using /dev/urandom
>b. Tolerate a longer wait for getrandom(
# Background
The Linux kernel random number generator (RNG) historically supported
two character devices for reading random data:
* `/dev/urandom`: non-blocking, may be predictable if called soon after
boot or based on other output
* `/dev/random`: blocking, intended to be cryptographically sec
18 matches
Mail list logo
