On 8/1/14, coderman <coderman@???> wrote:
> On Fri, Aug 1, 2014 at 2:44 AM, intrigeri <intrigeri@???> wrote:
>> ...
>> [For full context, and to avoid rehashing previous discussion, please
>> read https://labs.riseup.net/code/issues/7642.]
>
> sooner or later everyone hits this bag of sticky worms... :P
>
> for the old (deprecated) Tor VM experiment i read from host sources to
> pass seeds into guests. ideally this would be combined with a strong
> entropy source like /dev/hw_random to rngd. adding haveged also a good
> idea. (for VM guests the virtio_random driver best to pull from host
> reserves)
> ... but speaking to your specific scenario:
Sure - if we have entropy, we can seed anything. :)
>
>
>
>> The long-term plan, for persistence users, is #7675 ("Persist entropy
>> pool seeds"). However, it covers neither the short term, nor people
>> using Tails without persistence.
>>
>> 1. keep things as-is => urandom is seeded by date +%s.%N + a publicly
>> known value
>
> can be better, as discussed.
>
>
>> 2. drop the publicly known value => urandom is seeded by date +%s.%N
>> only
>
> this can only be worse. don't do #2.
How is that worse? The goal is entropy collectin. A public value is
not entropic.
It may make sense to add entropy to the disk at install time from the
installing computer.
>
>
>
>> 3. disable (at least the relevant part of) the urandom initscript =>
>> urandom is only seeded by the kernel, somehow
>
> this would be less better, too.
>
The date is strictly better than no entropy at all. A date is a very
small amount of entropy but probably it is not sufficient.
>
> perhaps best compromise: #4
>
> read some bytes from /dev/urandom, in case kernel has seeded with some
> DRBG well seeded configuration.
That does that work? If we have no entropy, we have no entropy.
>
> specifically:
> 1. read 8 bytes from /dev/urandom [in case well seeded entirely in
> kernel somehow - long thread goes here]
> 2. urandom is [re]seeded by 8bytes + date +%s.%N + a publicly known value
> 3. rngd started too, if appropriate noise source present for /dev/hwrandom.
> 4. if no physical noise source present, run haveged at boot instead of
> rngd.
> 5. prompt user to use persistence for saving entropy seeds, guards, etc.
>
> you can run rngd and haveged together, but this is tricky in weird
> ways. best to pick rngd if a true hardware random number generator is
> present, and fall back to haveged if not.
We need both - we cannot known when one will not function as hardware
may change on a per boot basis.
>
>
>
>> I think it mainly depends on whether haveged (and rngd) will
>> contribute to the pool used by urandom, which is still unclear to me
>> (see note 12 on the ticket).
>
> they could, but they are also likely to contribute better later in
> system start up. seeding as above before and in addition to also
> running these daemons is still recommended.
>
>
>> Does anyone know for sure the answer to this question (pointers to the
>> relevant code might help)? Or shall I go ask Linux randomness experts,
>> such as hpa and the rngd / haveged authors?
>
> i can go into as much technical detail on the linux kernel entropy
> behavior, user space interfaces, and common supporting infrastructures
> for various distributions as you'd like.
Could you explain the (unseeded) process for entropy collection in the
kernel (3.14-1-amd64) in use on Tails? Assuming no haveged, rngd, etc.
All the best,
Jacob
