On 2 May 2022 16:34:25 CEST, Michael Conrad wrote:
>On 5/2/22 09:54, Bernhard Reutner-Fischer wrote:
>> But why is the seeding being run only at S20, way after udev?
>
>It needs to be at least late enough for the persistent storage to be mounted,
>which probably isn't the root filesystem at
On 5/2/22 09:54, Bernhard Reutner-Fischer wrote:
There is also the case (that on my systems at least) udev
initialisation reads from /dev/[u]random well before the S20
script loads any saved entropy.
I've not tried to find out what the value is used for.
I find at least one occurrence where the
On Sun, 1 May 2022 18:35:00 +0200
Emmanuel Deloget wrote:
> > There is also the case (that on my systems at least) udev
> > initialisation reads from /dev/[u]random well before the S20
> > script loads any saved entropy.
> > I've not tried to find out what the value is used for.
>
> I find at
On Sun, May 1, 2022 at 3:07 PM David Laight wrote:
> Using the same file twice is better than having nothing at all.
> At least different systems use different values.
> Unless you have a remote 'dos' attack that can crash the system
> at exactly the right point in the boot sequence this is an
>
Hi,
Le lun. 2 mai 2022 à 11:37, Denys Vlasenko a écrit :
>
> On Mon, May 2, 2022 at 8:26 AM Emmanuel Deloget wrote:
> > Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a
> > écrit :
> > > > I beg to differ, and especially on some embedded systems where the RNG
> > > > might be quite controllable
On Mon, May 2, 2022 at 11:37 AM Denys Vlasenko wrote:
>
> On Mon, May 2, 2022 at 8:26 AM Emmanuel Deloget wrote:
> > Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a
> > écrit :
> > > > I beg to differ, and especially on some embedded systems where the RNG
> > > > might be quite controllable by an
From: Alexander Dahl
> Sent: 02 May 2022 06:15
>
> Am Sat, Apr 30, 2022 at 03:12:11PM +0200 schrieb Denys Vlasenko:
> > Do you often pull power cords from machines you use for
> > somewhat important crypto operations, such as generating keys?
> > What are the chances that you also do it on a
On Mon, May 2, 2022 at 8:26 AM Emmanuel Deloget wrote:
> Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a écrit
> :
> > > I beg to differ, and especially on some embedded systems where the RNG
> > > might be quite controllable by an attacker from the outside (mostly
> > > because
> > > it lacks a
Le lun. 2 mai 2022 à 03:31, Denys Vlasenko a écrit :
>
> On Sun, May 1, 2022 at 6:35 PM Emmanuel Deloget wrote:
> > > > - RNG is seeded and credited using file A.
> > > > - File A is unlinked but not fsync()d.
> > > > - TLS connection does something and a nonce is generated.
> > > > - System
Hello Jason,
Am Fri, Apr 29, 2022 at 07:04:47PM +0200 schrieb Jason A. Donenfeld:
> Rather than having getrandom() be called in a loop that handles EINTR --
> which would require more code bloat -- we just limit the maximum seed
> size to 256 bytes, which the kernel guarantees won't be
Hello Denys,
Am Sat, Apr 30, 2022 at 03:12:11PM +0200 schrieb Denys Vlasenko:
> Do you often pull power cords from machines you use for
> somewhat important crypto operations, such as generating keys?
> What are the chances that you also do it on a machine without RTC
> clock (which would
On Sun, May 1, 2022 at 6:35 PM Emmanuel Deloget wrote:
> > > - RNG is seeded and credited using file A.
> > > - File A is unlinked but not fsync()d.
> > > - TLS connection does something and a nonce is generated.
> > > - System loses power and reboots.
> > > - RNG is seeded and credited using
I'm not sure I have any right to jump into the conversation but here I am.
Le dim. 1 mai 2022 à 15:07, David Laight a écrit :
>
> From: Jason A. Donenfeld
> > Sent: 30 April 2022 14:48
> >
> > Hi Denys,
> >
> > On Sat, Apr 30, 2022 at 3:12 PM Denys Vlasenko
> > wrote:
> > > > + /* The
From: Jason A. Donenfeld
> Sent: 30 April 2022 14:48
>
> Hi Denys,
>
> On Sat, Apr 30, 2022 at 3:12 PM Denys Vlasenko
> wrote:
> > > + /* The fsync() here is necessary for safety here, so that power
> > > being pulled
> > > +* at the wrong moment doesn't result in the seed being
On Sat, Apr 30, 2022 at 11:48 PM Jason A. Donenfeld wrote:
>
> On Sat, Apr 30, 2022 at 11:19 PM Denys Vlasenko
> wrote:
> > Thank you for the explanation. I re-adding the fsync
> > and adding a comment. Please take a look at current git.
>
> Oh god, what have you done? You have butchered seedrng
On Sat, Apr 30, 2022 at 3:48 PM Jason A. Donenfeld wrote:
> On Sat, Apr 30, 2022 at 3:12 PM Denys Vlasenko
> wrote:
> > > @@ -190,6 +192,8 @@ int seedrng_main(int argc UNUSED_PARAM, char *argv[])
> > > if (mkdir(seed_dir, 0700) < 0 && errno != EEXIST)
> > >
On Sat, Apr 30, 2022 at 11:19 PM Denys Vlasenko
wrote:
> Thank you for the explanation. I re-adding the fsync
> and adding a comment. Please take a look at current git.
Oh god, what have you done? You have butchered seedrng into garbage. I
do not agree with the changes you made. You've removed
On Sat, Apr 30, 2022 at 3:48 PM Jason A. Donenfeld wrote:
> On Sat, Apr 30, 2022 at 3:12 PM Denys Vlasenko
> wrote:
> > > + /* The fsync() here is necessary for safety here, so that power
> > > being pulled
> > > +* at the wrong moment doesn't result in the seed being used
> > >
Ok my last mail, promised.
Jason A. Donenfeld wrote in
:
..
|This reads as complete gibberish to me, sorry. Please stop with this \
|nonsense.
Like i said i think (in private?) i had only read the
"Documentation and Analysis of the Linux Random Number Generator
- Last updated: April 2020"[1]
Hi Steffen,
On Sat, Apr 30, 2022 at 8:50 PM Steffen Nurpmeso wrote:
>
> Jason A. Donenfeld wrote in
> :
> ...
> |Again, stop charging steadfastly toward creating vulnerabilities
> |because you don't understand things. The scenario is:
> |
> |- RNG is seeded and credited using file A.
> |-
Jason A. Donenfeld wrote in
:
...
|Again, stop charging steadfastly toward creating vulnerabilities
|because you don't understand things. The scenario is:
|
|- RNG is seeded and credited using file A.
|- File A is unlinked but not fsync()d.
|- TLS connection does something and a nonce is
Hi Denys,
On Sat, Apr 30, 2022 at 3:12 PM Denys Vlasenko wrote:
> > + /* The fsync() here is necessary for safety here, so that power
> > being pulled
> > +* at the wrong moment doesn't result in the seed being used twice
> > by accident. */
> > if ((unlink(filename) < 0
On Fri, Apr 29, 2022 at 7:05 PM Jason A. Donenfeld wrote:
> Rather than having getrandom() be called in a loop that handles EINTR --
> which would require more code bloat -- we just limit the maximum seed
> size to 256 bytes, which the kernel guarantees won't be interrupted.
> Additionally
Rather than having getrandom() be called in a loop that handles EINTR --
which would require more code bloat -- we just limit the maximum seed
size to 256 bytes, which the kernel guarantees won't be interrupted.
Additionally document the flock() and fsync() usage so that somebody
doesn't remove
24 matches
Mail list logo
