first user of this applet will be LEDE (OpenWrt) to save an urandom seed
using getrandom() (so we are sure /dev/urandom pool is initialized)
function old new delta
getrandom_main - 178+178
.rodata
On Tue, Jun 28, 2016, at 19:56, Etienne CHAMPETIER wrote:
> first user of this applet will be LEDE (OpenWrt) to save an urandom seed
> using getrandom() (so we are sure /dev/urandom pool is initialized)
In LFS, the boot scripts use dd for this. Is there any need for an
applet?
- Lauri
--
http:/
perhaps a better aim ist to improve the $RANDOM in ash ?
re,
wh
Am 28.06.2016 18:56, schrieb Etienne CHAMPETIER:
> first user of this applet will be LEDE (OpenWrt) to save an urandom seed
> using getrandom() (so we are sure /dev/urandom pool is initialized)
>
> function
On 06/28/2016 06:56 PM, Etienne CHAMPETIER wrote:
first user of this applet will be LEDE (OpenWrt) to save an urandom seed
using getrandom() (so we are sure /dev/urandom pool is initialized)
function old new delta
getrandom_main
Hi Lauri,
2016-06-28 19:10 GMT+02:00 Lauri Kasanen :
> On Tue, Jun 28, 2016, at 19:56, Etienne CHAMPETIER wrote:
>> first user of this applet will be LEDE (OpenWrt) to save an urandom seed
>> using getrandom() (so we are sure /dev/urandom pool is initialized)
>
> In LFS, the boot scripts use dd fo
Hi Walter,
2016-06-28 19:47 GMT+02:00 walter harms :
> perhaps a better aim ist to improve the $RANDOM in ash ?
getrandom() is blocking until properly initialized,
i don't think we want such API change for $RANDOM
>
> re,
> wh
>
> Am 28.06.2016 18:56, schrieb Etienne CHAMPETIER:
>> first user o
Hi Tito,
2016-06-28 21:37 GMT+02:00 Tito :
>
>
> On 06/28/2016 06:56 PM, Etienne CHAMPETIER wrote:
>>
>> first user of this applet will be LEDE (OpenWrt) to save an urandom seed
>> using getrandom() (so we are sure /dev/urandom pool is initialized)
>>
>> function
On 06/28/2016 04:54 PM, Etienne Champetier wrote:
> Hi Lauri,
>
> 2016-06-28 19:10 GMT+02:00 Lauri Kasanen :
>> On Tue, Jun 28, 2016, at 19:56, Etienne CHAMPETIER wrote:
>>> first user of this applet will be LEDE (OpenWrt) to save an urandom seed
>>> using getrandom() (so we are sure /dev/urando
Hi Rob,
2016-06-29 23:00 GMT+02:00 Rob Landley :
>
>
> On 06/28/2016 04:54 PM, Etienne Champetier wrote:
>> Hi Lauri,
>>
>> 2016-06-28 19:10 GMT+02:00 Lauri Kasanen :
>>> On Tue, Jun 28, 2016, at 19:56, Etienne CHAMPETIER wrote:
first user of this applet will be LEDE (OpenWrt) to save an uran
On Tue, Jun 28, 2016 at 6:56 PM, Etienne CHAMPETIER
wrote:
> first user of this applet will be LEDE (OpenWrt) to save an urandom seed
> using getrandom() (so we are sure /dev/urandom pool is initialized)
Please be more specific which task you want to achieve with this tool.
I googled for this n
On Tue, Jun 28, 2016 at 7:47 PM, walter harms wrote:
> perhaps a better aim ist to improve the $RANDOM in ash ?
$RAMDOM generator in my tests passed all "dieharder -g 200 -a" tests.
How much better than this do you need?
___
busybox mailing list
busybo
On Sun, Jul 03, 2016 at 06:46:32PM +0200, Denys Vlasenko wrote:
> On Tue, Jun 28, 2016 at 7:47 PM, walter harms wrote:
> > perhaps a better aim ist to improve the $RANDOM in ash ?
>
> $RAMDOM generator in my tests passed all "dieharder -g 200 -a" tests.
> How much better than this do you need?
T
On Sun, Jul 03, 2016 at 06:44:22PM +0200, Denys Vlasenko wrote:
> On Tue, Jun 28, 2016 at 6:56 PM, Etienne CHAMPETIER
> wrote:
> > first user of this applet will be LEDE (OpenWrt) to save an urandom seed
> > using getrandom() (so we are sure /dev/urandom pool is initialized)
>
>
> Please be more
* Denys Vlasenko [04.07.2016 09:06]:
> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo
> schedstat buddyinfo >/dev/random
>
> in practice work quite satisfactorily for adding some entropy at boot time?
> If you don't think so, can you demonstrate a setup where the output is
> p
Hi Denys
TLDR: /dev/urandom is safe once initialized,
initialization take a long time on embedded device
=> use getrandom() to wait for initialization and be safe
2016-07-03 18:44 GMT+02:00 Denys Vlasenko :
> On Tue, Jun 28, 2016 at 6:56 PM, Etienne CHAMPETIER
> wrote:
>> first user of this appl
2016-07-03 18:46 GMT+02:00 Denys Vlasenko :
> On Tue, Jun 28, 2016 at 7:47 PM, walter harms wrote:
>> perhaps a better aim ist to improve the $RANDOM in ash ?
>
>
> $RAMDOM generator in my tests passed all "dieharder -g 200 -a" tests.
> How much better than this do you need?
The problem is betwee
On Mon, Jul 4, 2016 at 11:00 AM, Etienne Champetier
wrote:
>> BTW, I know that security people would scream bloody murder,
>> but wouldn't
>>
>> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo
>> schedstat buddyinfo >/dev/random
>>
>> in practice work quite satisfactorily for ad
2016-07-04 17:02 GMT+02:00 Denys Vlasenko :
> On Mon, Jul 4, 2016 at 11:00 AM, Etienne Champetier
> wrote:
>>> BTW, I know that security people would scream bloody murder,
>>> but wouldn't
>>>
>>> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo
>>> schedstat buddyinfo >/dev/rand
On 07/04/2016 11:08 AM, Etienne Champetier wrote:
> 2016-07-04 17:02 GMT+02:00 Denys Vlasenko :
>> On Mon, Jul 4, 2016 at 11:00 AM, Etienne Champetier
>> wrote:
BTW, I know that security people would scream bloody murder,
but wouldn't
cd /proc && cat cpuinfo meminfo stat interr
Hi Rob,
2016-07-05 4:23 GMT+02:00 Rob Landley :
> On 07/04/2016 11:08 AM, Etienne Champetier wrote:
>> 2016-07-04 17:02 GMT+02:00 Denys Vlasenko :
>>> On Mon, Jul 4, 2016 at 11:00 AM, Etienne Champetier
>>> wrote:
> BTW, I know that security people would scream bloody murder,
> but wouldn
On Tue, Jul 5, 2016 at 1:42 PM, Etienne Champetier
wrote:
> not exactly, as i said in my mail of 29 june 2016 at 17:04:
> you have
> - /dev/urandom, which never block
> - getrandom(), which block until /dev/urandom is properly initialized
> (system wide), then never block again and read from /dev/
Hi Denys,
2016-07-05 22:08 GMT+02:00 Denys Vlasenko :
> On Tue, Jul 5, 2016 at 1:42 PM, Etienne Champetier
> wrote:
>> not exactly, as i said in my mail of 29 june 2016 at 17:04:
>> you have
>> - /dev/urandom, which never block
>> - getrandom(), which block until /dev/urandom is properly initiali
On 07/05/2016 06:42 AM, Etienne Champetier wrote:
>> You've implied that this new API can block until it's initialized, which
>> reading from /dev/random can already do, and presumably
>> select/poll/inotify could do on /dev/random without consuming entropy.
>
> As shown in my mail from 29 june 20
On Tue, Jul 05, 2016 at 09:33:04PM -0500, Rob Landley wrote:
> On 07/05/2016 06:42 AM, Etienne Champetier wrote:
> >> You've implied that this new API can block until it's initialized, which
> >> reading from /dev/random can already do, and presumably
> >> select/poll/inotify could do on /dev/rando
On 07/05/2016 11:49 PM, Rich Felker wrote:
> On the other hand, /dev/urandom has a problem that it will give
> results before sufficient entropy has been collected, resulting in
> duplicate sequences (and thus duplicate keys generated) on identical
> devices with a fairly high probability.
Which i
On Wed, Jul 06, 2016 at 12:31 AM, Rob Landley said:
> Which is why you'd read a byte from /dev/random first if you
> need to wait for the pool to have entropy in it? Given that
> there's an existing mechanism that will block that'sbeen here
> for 20 years?
This article:
Myths about /dev/urandom
ht
I think Rob's getting somewhat too agitated here, but his arguments
are convincing.
On Wed, Jul 6, 2016 at 4:33 AM, Rob Landley wrote:
>> Entropy collection is slower on embeded devices, so you have to wait for it,
>> and
>> getrandom() claim to do exactly that
>
> By adding 3 minutes to the boo
Hi Rob,
First thanks for all your questions/arguments it help me see what i
need to explain better.
Please take a look at this article (really good explaination of the
linux rng) https://lwn.net/Articles/525459/
So linux uses 3 differents pools, input, /dev/random and /dev/urandom
pool, and it u
I just sent a long answer to Rob (with a sum up at the beginning)
2016-07-06 18:39 GMT+02:00 Denys Vlasenko :
> I think Rob's getting somewhat too agitated here, but his arguments
> are convincing.
>
> On Wed, Jul 6, 2016 at 4:33 AM, Rob Landley wrote:
>>> Entropy collection is slower on embeded
We could say that waiting 6 minutes (using /dev/random) instead of 3
minutes (using getrandom()) is acceptable, but now what if you have 10
soft wanting to do that, /dev/random might block again
This thread is a dialogue of the deaf and a strawman burning fest, and if
you keep thinking the othe
On 07/06/2016 03:10 AM, James Bowlin wrote:
> So it is not clear to me that
> It even seems possible that
> Also, I doubt Theodore Ts'o would have bothered with
> Likewise, people who seem to know a lot more about this than I do
> As said in the "myths" article:
>
> [W]hile appeal to authority i
On 07/06/2016 11:41 AM, Etienne Champetier wrote:
> Now you really hate the fact that getrandom() is a syscall.
I do not hate the fact getrandom is a syscall. I'm asking what the point
is of a new applet to call this syscall. You have suggested it could
block to show when /dev/urandom is producing
Hi Rob,
2016-07-07 17:49 GMT+02:00 Rob Landley :
> On 07/06/2016 11:41 AM, Etienne Champetier wrote:
>> Now you really hate the fact that getrandom() is a syscall.
>
> I do not hate the fact getrandom is a syscall. I'm asking what the point
> is of a new applet to call this syscall. You have sugge
On Wed, Jul 06, 2016 at 12:31:01AM -0500, Rob Landley wrote:
> On 07/05/2016 11:49 PM, Rich Felker wrote:
> > On the other hand, /dev/urandom has a problem that it will give
> > results before sufficient entropy has been collected, resulting in
> > duplicate sequences (and thus duplicate keys gener
On Fri, Jul 8, 2016 at 5:25 PM, Etienne Champetier
wrote:
>> B) To accomplish _what_? You seem to want to use the new API because it
>> exists.
>
> unblock (2 times) faster, nothing more
I think for now the applet should not be accepted.
It uses an API which is so new many build environments wou
On 07/10/2016 01:07 PM, Denys Vlasenko wrote:
> Yes, blocking for 3 minutes rather than 6 minutes is an improvement,
> but would 3 minute pause on boot be acceptable for many? I suspect
> it's still bad; and if I would have that system at hand, I'd experiment
> with making it initialize random pool
2016-07-10 20:07 GMT+02:00 Denys Vlasenko :
> On Fri, Jul 8, 2016 at 5:25 PM, Etienne Champetier
> wrote:
>>> B) To accomplish _what_? You seem to want to use the new API because it
>>> exists.
>>
>> unblock (2 times) faster, nothing more
>
> I think for now the applet should not be accepted.
>
>
On Mon, Jul 11, 2016 at 8:58 AM, Rob Landley wrote:
> On 07/10/2016 01:07 PM, Denys Vlasenko wrote:
>> Yes, blocking for 3 minutes rather than 6 minutes is an improvement,
>> but would 3 minute pause on boot be acceptable for many? I suspect
>> it's still bad; and if I would have that system at ha
On Mon, Jul 11, 2016 at 08:19:29PM +0200, Denys Vlasenko wrote:
> On Mon, Jul 11, 2016 at 8:58 AM, Rob Landley wrote:
> > Anyway, the point is you can't voluntarily collect _more_ entropy from
> > these sources. They run when there's data to gather, calling the
> > routines when there isn't new da
On Tue, Jul 12, 2016 at 4:26 AM, Rich Felker wrote:
> On Mon, Jul 11, 2016 at 08:19:29PM +0200, Denys Vlasenko wrote:
>> On Mon, Jul 11, 2016 at 8:58 AM, Rob Landley wrote:
>> > Anyway, the point is you can't voluntarily collect _more_ entropy from
>> > these sources. They run when there's data t
On 7/7/2016 11:49 AM, Rob Landley wrote:
On 07/06/2016 11:41 AM, Etienne Champetier wrote:
>Now you really hate the fact that getrandom() is a syscall.
I do not hate the fact getrandom is a syscall. I'm asking what the point
is of a new applet to call this syscall. You have suggested it could
b
On Tue, Jul 12, 2016 at 01:09:42PM -0400, Michael Conrad wrote:
> On 7/7/2016 11:49 AM, Rob Landley wrote:
> >On 07/06/2016 11:41 AM, Etienne Champetier wrote:
> >>>Now you really hate the fact that getrandom() is a syscall.
> >I do not hate the fact getrandom is a syscall. I'm asking what the poin
On 12/07/2016 23:53, Rich Felker wrote:
There are very good reasons it's a syscall rather than a device: many
use cases require a never-fails entropy source, and with the device
node approach they're vulnerable to fd-exhaustion attacks. Most
existing bad code, when faced with such a situation, fa
On 7/12/2016 5:53 PM, Rich Felker wrote:
On Tue, Jul 12, 2016 at 01:09:42PM -0400, Michael Conrad wrote:
On 7/7/2016 11:49 AM, Rob Landley wrote:
On 07/06/2016 11:41 AM, Etienne Champetier wrote:
Now you really hate the fact that getrandom() is a syscall.
I do not hate the fact getrandom is a
On Tue, Jul 12, 2016 at 06:56:50PM -0400, Michael Conrad wrote:
> On 7/12/2016 5:53 PM, Rich Felker wrote:
> >On Tue, Jul 12, 2016 at 01:09:42PM -0400, Michael Conrad wrote:
> >>On 7/7/2016 11:49 AM, Rob Landley wrote:
> >>>On 07/06/2016 11:41 AM, Etienne Champetier wrote:
> >Now you really hat
>I have a personal grudge against blocking system calls.
As do I, they're evil, evil, evil if you're trying to
write anything more involved/interactive than a pipeline
component.
-- Jim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.
46 matches
Mail list logo
