Re: [tor-bugs] #10676 [Tor]: Verify urandom-style RNG is seeded before generating ID keys

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#10676: Verify urandom-style RNG is seeded before generating ID keys
-----------------------------+--------------------------------------------
     Reporter:  nickm        |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  major        |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-server rng urandom startup
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------------------------
Description changed by nickm:

Old description:

> In a better world, every kernel would have a /dev/urandom interface that
> would block if it hadn't been seeded enough.  I hear that some operating
> systems do this already.
>
> Unfortunately, the world is what it is, and a typical /dev/urandom
> implementation treats the case where its internal entropy estimator is
> low exactly the same as the case when its .
>
> So we should try to protect ourselves from cases where we start up on
> systems with limited entropy and /dev/urandom refuses to tell us so.
> Here's a design sketch:
>
> 1. If we're generating an identity key when we haven't generated one
> before, or if we are starting Tor for the first time with a given
> DataDirectory, we should first try to read a single byte from
> /dev/random, and block until we can.  This will ensure that the kernel
> RNG has (by its own lights) reached full entropy at least once, which
> guarantees cryptographic quality of the rest of the /dev/urandom stream.
>
> 2. Optionally, we can keep some RNG output in a file on disk in our data
> directory, and use it as an extra seed on subsequent Tor boots,
> regenerating it each time we start Tor.  Combined with 1 above, this
> would protect us -- at least as well as most operating systems protect us
> -- from ever running our RNG in a low-entropy environment.
>
> 3. Optionally, we could to the trick in 1 above every time we start Tor.

New description:

 In a better world, every kernel would have a /dev/urandom interface that
 would block if it hadn't been seeded enough.  I hear that some operating
 systems do this already.

 Unfortunately, the world is what it is, and a typical /dev/urandom
 implementation treats the case where its internal entropy estimator is low
 exactly the same as the case when its internal entropy estimator has never
 gotten high at all.

 So we should try to protect ourselves from cases where we start up on
 systems with limited entropy and /dev/urandom refuses to tell us so.
 Here's a design sketch:

 1. If we're generating an identity key when we haven't generated one
 before, or if we are starting Tor for the first time with a given
 DataDirectory, we should first try to read a single byte from /dev/random,
 and block until we can.  This will ensure that the kernel RNG has (by its
 own lights) reached full entropy at least once, which guarantees
 cryptographic quality of the rest of the /dev/urandom stream.

 2. Optionally, we can keep some RNG output in a file on disk in our data
 directory, and use it as an extra seed on subsequent Tor boots,
 regenerating it each time we start Tor.  Combined with 1 above, this would
 protect us -- at least as well as most operating systems protect us --
 from ever running our RNG in a low-entropy environment.

 3. Optionally, we could to the trick in 1 above every time we start Tor.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10676#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs