From: Alexander Dahl <post@lespocky.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH] haveged: add entropy daemon
Date: Thu, 6 Jul 2017 11:13:26 +0200 [thread overview]
Message-ID: <20170706091326.GD27745@falbala.home.lespocky.de> (raw)
In-Reply-To: <20170630121607.sgwh5z7njnhaliid@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1517 bytes --]
Hello,
On Fri, Jun 30, 2017 at 02:16:07PM +0200, Michael Olbrich wrote:
> On Fri, Jun 30, 2017 at 09:19:18AM +0200, Alexander Dahl wrote:
> > Besides: is there any way to have this random generator stuff
> > certainly ready before generating dropbear keys (rc-once)?
>
> I think /dev/random and getrandom() can block until then. Something could
> be built on top of that. However you need to be careful: This may block a
> very long time on an idle embedded system.
I had a look into dropbearkey now. As far as I understand the code,
dropbear just uses /dev/urandom, but tries to feed some entropy into
it before doing anything with randomness. The "documentation" in
default_options.h suggests /dev/random is used for keygen, but I think
it's wrong (our outdated) and only non blocking randomness is used.
dropbear can use prngd or egd, but no hint in the code on haveged. The
only thing I found on dropbear profiting from haveged is an old ticket
in the OpenWRT bugtracker, but they just do the "hopefully wait long
enough" thing. [1]
So I guess to improve this situation someone may have to talk to
upstream dropbear to discuss some possibilies?
Greets
Alex
[1] https://dev.openwrt.org/ticket/9631
--
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: C28E E6B9 0263 95CF 8FAF 08FA 34AD CD00 7221 5CC6 ***
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 91 bytes --]
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
next prev parent reply other threads:[~2017-07-06 9:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 21:49 Robert Schwebel
2017-06-30 7:19 ` Alexander Dahl
2017-06-30 12:16 ` Michael Olbrich
2017-07-02 15:37 ` Robert Schwebel
2017-07-06 9:13 ` Alexander Dahl [this message]
2017-07-02 15:36 ` Robert Schwebel
2017-07-04 10:48 ` Alexander Dahl
2017-07-06 11:54 ` [ptxdist] [PATCH 0/2] haveged: bbinit startup and more download URLs Alexander Dahl
2017-07-06 11:54 ` [ptxdist] [PATCH 1/2] haveged: Add URL for upstream tarball archive Alexander Dahl
2017-07-06 11:54 ` [ptxdist] [PATCH 2/2] haveged: Introduce bbinit startup Alexander Dahl
2017-06-30 8:19 ` [ptxdist] [PATCH] haveged: add entropy daemon Michael Olbrich
2017-06-30 8:32 ` Robert Schwebel
2017-07-02 15:26 ` Robert Schwebel
2017-06-30 12:12 ` Michael Olbrich
2017-07-02 15:27 ` Robert Schwebel
2017-07-02 15:35 ` [ptxdist] [PATCHv2] " Robert Schwebel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170706091326.GD27745@falbala.home.lespocky.de \
--to=post@lespocky.de \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox