Feature #7642

Investigate whether we should resume shipping a static random seed

Added by anonym 2014-07-22 16:47:54 . Updated 2018-08-22 13:10:43 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2016-09-02
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Starter:
0
Affected tool:
Deliverable for:

Description

With the seed both public and the same each boot for a given Tails release, this may make the output of /dev/urandom predictable.

Team: DrWhax, sycamoreone, bertagaz for review, segfault


Subtasks

Feature #11758: Analyze early boot entropy gathering Resolved sycamoreone

0


Related issues

Related to Tails - Feature #6116: Audit random seed Confirmed
Related to Tails - Feature #7675: Persist entropy pool seeds Duplicate 2016-11-04
Related to Tails - Feature #11897: Persist a random seed across boots Needs Validation 2016-11-04
Related to Tails - Feature #11898: Have a readable blueprint about randomness in Tails Resolved 2016-11-04
Has duplicate Tails - Feature #7646: Investigate whether we should ship /var/lib/systemd/random-seed Duplicate 2014-07-23

History

#1 Updated by intrigeri 2014-07-22 17:17:33

  • Priority changed from Elevated to High

#2 Updated by intrigeri 2014-07-23 09:00:34

  • related to Feature #7646: Investigate whether we should ship /var/lib/systemd/random-seed added

#3 Updated by intrigeri 2014-07-27 17:12:15

  • Status changed from Confirmed to In Progress
  • The urandom initscript makes it clear that the assumption for this file is that its content is “unique to this machine and not known to attackers”… which is not the case when we ship that file in our ISO images.
  • If that file doesn’t exist, the initscript seeds urandom with the output of date +%s.%N only, which is probably even worse than the current state of things.
  • The same initscript says that “re-using a seed compromises security”.
  • Only /dev/urandom is at risk here. /dev/random is not.

Next things to do:

  1. Look at how other Live systems handle this problem. I suspect Ubuntu or Liberte Linux have something.
  2. Look at how cloud images handle this problem. IIRC Ubuntu has an online entropy service; maybe others have something better in our context.
  3. Research if it would be an improvement to seed urandom from /dev/random (note: probably it’s a stupid idea).

#4 Updated by ioerror 2014-07-27 17:45:39

Wow - we should absolutely not have a static seed across all images!

#5 Updated by intrigeri 2014-07-27 18:02:16

> Wow - we should absolutely not have a static seed across all images!

Yay, well, OK, that’s the starting point. But then… what? :)

#6 Updated by ioerror 2014-07-27 23:08:27

intrigeri wrote:
> > Wow - we should absolutely not have a static seed across all images!
>
> Yay, well, OK, that’s the starting point. But then… what? :)

I would not ship /var/lib/systemd/random-seed in an ISO.

If we want to seed the RNG and keep a cache of it: I would suggest that persistance be enabled and that we cache a system wide seed after the first boot and at the first clean shutdown. I would also suggest that we use haveged as well as other other entropy collection daemons. It would be nice to have study (read: a survey of packages, etc) of all the useful entropy gathering daemons that might be of use on a Tails system.

Regarding the choices:

_Look at how other Live systems handle this problem. I suspect Ubuntu or Liberte Linux have something.
_

I suspect that other Live systems do not handle this problem well at all. Liberte source is here: https://github.com/mkdesu/liberte.git

In Liberté Linux, I don’t see any obvious details on how the RNG is seeded at boot time. It is a Gentoo-based LiveUSBs/CD build: http://wiki.gentoo.org/wiki/LiveUSB

I don’t see any obvious discussions about how Gentoo deals with the need for entropy at boot time. Perhaps the author of Liberté Linux might have some thoughts on the matter?

_
Look at how cloud images handle this problem. IIRC Ubuntu has an online entropy service; maybe others have something better in our context._

There has been a great deal of discussion about this topic in the last few years. In short, the answer is to install haveged: https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

The longer answer is this paper by Brendan Kerrigan and Yu Chen: http://harvey.binghamton.edu/~ychen/chen-kerrigan.pdf

Basically - the cloud doesn’t get entropy for free and many systems aren’t really designed well for this specific issue.

_Research if it would be an improvement to seed urandom from /dev/random (note: probably it’s a stupid idea).
_

If we have entropy, we don’t need to seed urandom, right?

#7 Updated by intrigeri 2014-07-27 23:22:30

First, as said on IRC already, thanks a lot for this input. Much appreciated.

> If we want to seed the RNG and keep a cache of it: […]

OK, this could be good, but it doesn’t solve the problem for users who don’t have persistence enabled.

> I would also suggest that we use haveged as well as other other
> entropy collection daemons. It would be nice to have study (read: a survey of
> packages, etc) of all the useful entropy gathering daemons that might be of use on
> a Tails system.

You may want to have a look at Feature #5650 :)

… and you may want to give a hand to the Debian maintainer, and/or to gently nag the Ubuntu people (who have upgraded the package many times without contributing it back to Debian) so that they share their stuff properly with Debian.

> Perhaps the author of Liberté Linux might have some thoughts on the matter?

I’ll ask..

>> Look at how cloud images handle this problem. IIRC Ubuntu has an online entropy
>> service; maybe others have something better in our context.

> There has been a great deal of discussion about this topic in the last few years.
> In short, the answer is to install haveged: […]

>> Research if it would be an improvement to seed urandom from /dev/random (note: probably it’s a stupid idea).

> If we have entropy, we don’t need to seed urandom, right?

Newbie question (given haveged feeds /dev/random, not /dev/urandom): is urandom seeded by /dev/random in any way?

  • If it is, then letting the urandom initscript seed it with only the date/time should be fine, right, if I’m following you.
  • If it’s not, then haveged doesn’t solve this problem at all. Correct?

Another newbie question: why is it better to seed urandom with the date/time only (which will happen if we stop shipping /var/lib/urandom/random-seed in ISOs) than seeding it with the date/time concatenated to a fixed, publicly known value?

#8 Updated by ioerror 2014-07-27 23:50:11

intrigeri wrote:
> First, as said on IRC already, thanks a lot for this input. Much appreciated.
>
> > If we want to seed the RNG and keep a cache of it: […]
>
> OK, this could be good, but it doesn’t solve the problem for users who don’t have persistence enabled.
>

They have a lot of problems - for example - they have no Tor guard caching. Also, they’re not in such a bad state - if they’re not caching anything, they probably do a bunch of stuff on the system differently each time - perhaps even with different hardware, different networks, different timings of hardware interrupts, etc.

> > I would also suggest that we use haveged as well as other other
> > entropy collection daemons. It would be nice to have study (read: a survey of
> > packages, etc) of all the useful entropy gathering daemons that might be of use on
> > a Tails system.
>
> You may want to have a look at Feature #5650 :)
>

I’ve left a relevant comment on Feature #5650.

> … and you may want to give a hand to the Debian maintainer, and/or to gently nag the Ubuntu people (who have upgraded the package many times without contributing it back to Debian) so that they share their stuff properly with Debian.
>

I don’t know what help I can offer at the moment. :)

> > Perhaps the author of Liberté Linux might have some thoughts on the matter?
>
> I’ll ask..

Thank you. :)

>
> >> Look at how cloud images handle this problem. IIRC Ubuntu has an online entropy
> >> service; maybe others have something better in our context.
>
> > There has been a great deal of discussion about this topic in the last few years.
> > In short, the answer is to install haveged: […]
>
> >> Research if it would be an improvement to seed urandom from /dev/random (note: probably it’s a stupid idea).
>
> > If we have entropy, we don’t need to seed urandom, right?
>
> Newbie question (given haveged feeds /dev/random, not /dev/urandom): is urandom seeded by /dev/random in any way?

I suggest reading man urandom for a primer. In short, yes but not always (and thus the problem with /dev/urandom) - quote the man page:

The  character  special files /dev/random and /dev/urandom (present since Linux 1.3.30) provide an interface to the kernel's random number generator.  File /dev/random has major device number 1 and minor device number 8.  File /dev/urandom has major device number 1 and minor device number 9.

The  random  number  generator  gathers  environmental  noise  from device drivers and other sources into an
entropy pool.  The generator also keeps an estimate of the number of bits of  noise  in  the  entropy  pool.
From this entropy pool random numbers are created.

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool.  /dev/random should be suitable for uses that need very high quality randomness such as one-time  pad  or  key  generation.  When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A read from the /dev/urandom device will not block waiting for more entropy.  As a result, if there  is  not sufficient  entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.  Knowledge of how to do this is not available  in  the  current unclassified  literature, but it is theoretically possible that such an attack may exist.  If this is a concern in your application, use /dev/random instead.

>
> * If it is, then letting the urandom initscript seed it with only the date/time should be fine, right, if I’m following you.

A modern kernel will behave differently than an older kernel. I believe the answer is ‘yes’ with a modern kernel and with an older kernel, I believe the answer was ‘no’ for embedded devices.

> * If it’s not, then haveged doesn’t solve this problem at all. Correct?

I think that a freshly booted system, with a cached seed and running haveged does solve the problem. I also think that a freshly booted system, without a cached seed and running haveged does solve the problem after some amount of time running.

>
> Another newbie question: why is it better to seed urandom with the date/time only (which will happen if we stop shipping /var/lib/urandom/random-seed in ISOs) than seeding it with the date/time concatenated to a fixed, publicly known value?

Is it? I wonder if not manually seeding it at all is actually better? :-)

The basic issue is one of entropy - a date and time is not very entropic but it is most certainly more entropic than a fixed, known value. If the date and time is outputting microseconds, I would say that is better but obviously, it falls within a known range, probably it is brute forceable and so on. It would be interesting to see a writeup on the number of bits of entropy (sources, actual bits, etc) that are likely present for a given Tails boot on a given machine (say an X60).

As far as not shipping random-seed - I’m confused, my randomly picked tails system doesn’t seem to have this file:

# ls -al /var/lib/urandom/random-seed
ls: cannot access /var/lib/urandom/random-seed: No such file or directory

Is that file shipping in 1.1?

#9 Updated by intrigeri 2014-07-28 10:54:01

#10 Updated by cypherpunks 2014-07-28 12:26:41

I (oerror) added rng-tools to a Tails build:

root@amnesia:/home/amnesia# /etc/init.d/rng-tools start
Starting Hardware RNG entropy gatherer daemon: (Hardware RNG device inode not found)
/etc/init.d/rng-tools: Cannot find a hardware RNG device to use.

There are two things that seem obvious to me - one is to ensure that such a device inode be added to the ISO and the other is that it should fail gracefully. I think the second happens automatically.

It seems that we probably want to configure rngd:
http://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny
https://www.gnu.org/software/hurd/user/tlecarrour/rng-tools.html
https://www.kernel.org/doc/Documentation/hw_random.txt

#11 Updated by intrigeri 2014-07-28 13:50:24

> I (oerror) added rng-tools to a Tails build:

Great. Please report about it on the relevant ticket (Feature #5650), not here.

#12 Updated by intrigeri 2014-07-28 14:40:32

ioerror wrote:
> intrigeri wrote:
>> > If we want to seed the RNG and keep a cache of it: […]
>>
>> OK, this could be good, but it doesn’t solve the problem for users who don’t have persistence enabled.

> They have a lot of problems - for example - they have no Tor guard caching.

Nobody has that yet — if you want to follow-up on it, please do it on Feature #5462.

> Also, they’re not in such a bad state - if they’re not caching anything, they probably do a bunch of stuff on the system differently each time - perhaps even with different hardware, different networks, different timings of hardware interrupts, etc.

This doesn’t match how many users I know use Tails without persistence, but it might still be a valid point. I’m not skilled enough in this area to judge, so I’ll have to trust you on that one :)

>> Newbie question (given haveged feeds /dev/random, not /dev/urandom): is urandom seeded by /dev/random in any way?

> I suggest reading man urandom for a primer. In short, yes but not always (and thus the problem with /dev/urandom) […]

Ah, right, both basically take their bits from the same entropy pool. http://www.2uo.de/myths-about-urandom/ helped me understand how this all works. Still:

  • the same article also says “In fact, there isn’t just one, but three pools filled with entropy. One primary pool, and one for /dev/random and /dev/urandom each, feeding off the primary pool. Those three pools all have their own entropy counts, but the counts of the secondary pools (for /dev/random and /dev/urandom) are mostly close to zero, and “fresh” entropy flows from the primary pool when needed, decreasing its entropy count";
  • haveged(8) says that haveged fills the /dev/random entropy pool.

So, if both are correct, then while “If we have entropy, we don’t need to seed urandom” per-se is probably correct, it seems to me that haveged will not contribute to “we have entropy”. Worth noting, I think.

>> * If it is, then letting the urandom initscript seed it with only the date/time should be fine, right, if I’m following you.

> A modern kernel will behave differently than a traditional kernel. I believe the answer is ‘yes’ with a modern kernel […]

OK, I now get this part.

>> Another newbie question: why is it better to seed urandom with the date/time only (which will happen if we stop shipping /var/lib/urandom/random-seed in ISOs) than seeding it with the date/time concatenated to a fixed, publicly known value?

> Is it?

I don’t know. I was tentatively inferring this by you advocating not shipping /var/lib/urandom/random-seed, which in practice, if we do nothing special additionally, means that /dev/urandom is seeded by date +%s.%N.

> I wonder if not manually seeding it at all is actually better? :-)

OK. I wonder too :)

> As far as not shipping random-seed - I’m confused, my randomly picked tails system doesn’t seem to have this file: […] Is that file shipping in 1.1?

Yes, it is:

sudo mount -o loop tails-i386-1.1.iso /mnt/tmp && sudo mount -o loop /mnt/tmp/live/filesystem.squashfs /mnt/tmp2 && ls -l /mnt/tmp2/var/lib/urandom
total 512
-rw------- 1 root root 512 Jul 22 17:10 random-seed

I see it in a running Tails 1.1 too. Its mtime confirms that it’s been updated at boot time (by the urandom initscript, most likely).

#13 Updated by intrigeri 2014-07-28 14:50:06

#14 Updated by intrigeri 2014-08-01 09:41:09

So, the long-term plan, for persistence users, is Feature #7675. It covers neither the short term, nor people using Tails without persistence. It seems that our options are:

  1. keep things as-is => urandom is seeded by date +%s.%N + a publicly known value
  2. drop the publicly known value => urandom is seeded by date +%s.%N only
  3. disable (at least the relevant part of) the urandom initscript => urandom is only seeded by the kernel, somehow

Solution 2 doesn’t look better than solution 1 to me, so the choice seems to be between solution 1 and 3. 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 above). Asked for advice on the -dev@ list, in the How to seed urandom (or not)? thread.

#15 Updated by BitingBird 2014-08-29 14:50:51

Do we still want this for 1.1.1, or do we postpone ?

#16 Updated by intrigeri 2014-08-29 17:50:19

  • Target version changed from Tails_1.1.1 to Tails_1.2
  • % Done changed from 0 to 10

Postponed. Next step is to wrap one’s mind around all the info that’s on this ticket and the related ones, read and understand the thread about it on tails-dev@, and come up with a reasonable proposal.

#17 Updated by intrigeri 2014-10-06 05:39:51

  • Target version changed from Tails_1.2 to Tails_1.2.1

Postponing, again.

#18 Updated by intrigeri 2014-11-25 07:53:14

  • Target version changed from Tails_1.2.1 to Tails_1.3

#19 Updated by intrigeri 2015-02-10 18:21:29

  • Assignee set to intrigeri
  • Target version changed from Tails_1.3 to Tails_1.4

I’ll try to work on it for Tails 1.4.

#20 Updated by intrigeri 2015-04-22 01:02:08

  • Target version changed from Tails_1.4 to Hole in the Roof

#21 Updated by intrigeri 2015-07-13 03:56:31

  • Assignee deleted (intrigeri)

#22 Updated by intrigeri 2015-07-18 06:29:44

  • blocks Bug #9262: Port our ISO build system to Jessie added

#23 Updated by intrigeri 2015-07-29 00:33:59

That’s the only remaining blocker for porting our ISO build system to Jessie (Bug #9262). I won’t have time to complete it in time for the 1.5 freeze (July 31). Help is welcome :)

#24 Updated by sajolida 2015-08-14 11:55:34

  • Assignee set to bertagaz

#25 Updated by intrigeri 2015-09-16 14:25:04

bertagaz, what’s your ETA on this one? I guess not before October 15, and there’s no big hurry, but I’d love to have a better idea of when we can complete Bug #9262.

#26 Updated by intrigeri 2015-10-05 13:29:01

intrigeri wrote:
> bertagaz, what’s your ETA on this one? I guess not before October 15, and there’s no big hurry, but I’d love to have a better idea of when we can complete Bug #9262.

Ping?

#27 Updated by intrigeri 2015-12-13 13:00:19

  • Target version changed from Hole in the Roof to Tails_2.0

Note that this will transitively block something I need to complete early in March (Feature #5926), via Bug #9262 and Feature #6297. So ideally it should be completed for 2.0, and worst case a bit later. I’ll thus have to take it over unless I see answers (at least a suitable ETA) here within a few weeks.

#28 Updated by intrigeri 2015-12-14 02:45:32

  • blocks Feature #6297: Save list of packages used at ISO build time added

#29 Updated by sycamoreone 2015-12-16 15:27:56

A few question about this:

  • Is this is still in the somebody needs “to wrap one’s mind around all the info that’s on this ticket and the related ones, read and understand the thread about it on tails-dev@, and come up with a reasonable proposal” state? Or is there already an almost finished proposal around somewhere?
  • Would it help if somebody started to at least write all this stuff up in one place?
  • Is there already a blueprint? (Probably not, as I can’t find one.)
  • Couldn’t this borrow (at least some design, but maybe also implementation) from the persistent Tor state work?

#30 Updated by sycamoreone 2015-12-16 15:58:42

Another questions: As far as I can see /var/lib/urandom/random-seed and /var/lib/systemd/random-seed do the same thing, except that /var/lib/urandom/random-seed needs to be written into /dev/urandom by an init script instead of systemd being able to take care of it.

Is there (after Bug #9262#note-26) any technical reason why this ticket is a blocker instead of Feature #7646?

(

#31 Updated by bertagaz 2015-12-21 02:46:15

Sorry, wanted to reply sooner but I’ve been busy with the 1.8.1 release

sycamoreone wrote:
> * Is this is still in the somebody needs “to wrap one’s mind around all the info that’s on this ticket and the related ones, read and understand the thread about it on tails-dev@, and come up with a reasonable proposal” state? Or is there already an almost finished proposal around somewhere?

There’s no proposal anywhere, so it’s definitely welcome if someone does this work. It’s on my plate, but help is greatly appreciated :)

> * Would it help if somebody started to at least write all this stuff up in one place?

When redmine ticket comments number goes this high, it sure is helpful.

> * Is there already a blueprint? (Probably not, as I can’t find one.)

Nope, there’s not. You can either create one in your own repo and ask for a merge, or ask someone to create it so that you can modify it afterward through the web interface of the website. Which solution do you prefer?

> * Couldn’t this borrow (at least some design, but maybe also implementation) from the persistent Tor state work?

Well, as I understood from Feature #7642#note-14, there’s a ticket/plan for users having persistence activated. The question still to resolve is to define a short term plan, and see what to do for people using Tails without persistence.

> Another questions: As far as I can see /var/lib/urandom/random-seed and /var/lib/systemd/random-seed do the same thing, except that /var/lib/urandom/random-seed needs to be written into /dev/urandom by an init script instead of systemd being able to take care of it.
>
> Is there (after Bug #9262#note-26) any technical reason why this ticket is a blocker instead of Feature #7646?

It seems that on Sid, both are present, so I guess the question is still relevant for Jessie and newer Debian version.

A difference I can see between them is that systemd’s urandom.service doesn’t melt the seed with a date.

#33 Updated by intrigeri 2016-01-02 04:47:14

As discussed with sycamoreone: this blocks the freezable APT repo, and my last sprint about it is early March, so we need to have reached a conclusion on this ticket earlier. sycamoreone thinks it’s doable.

#34 Updated by intrigeri 2016-01-02 04:51:30

  • Blueprint set to https://tails.boum.org/blueprint/randomness_seeding/

#35 Updated by flyingkiwiguy 2016-01-05 19:30:29

intrigeri wrote:
> FWIW, here’s my current stack of “resources I should read about this topic, some day”:
>
> * https://github.com/QubesOS/qubes-issues/issues/673
> * https://phabricator.whonix.org/T379
> * https://github.com/QubesOS/qubes-issues/issues/1311
> * https://github.com/grml/grml-debootstrap/issues/91
> * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789960

To add to the discussion from a crypto perspective please see:

https://www.av8n.com/computer/htm/secure-random.htm#sec-read-only

#36 Updated by sycamoreone 2016-01-05 19:52:50

Thanks, I will have a lock at this also. I actually had a document of the same author open in a tab to be read, but the page you linked is three years newer.

(People have been writing an awful lot about randomness generation, and too much of it is just opinions and feelings. It is quite hard to find the good parts.)

#37 Updated by bertagaz 2016-01-27 10:49:46

  • Target version changed from Tails_2.0 to Tails_2.2

#38 Updated by intrigeri 2016-02-13 03:38:37

bertagaz, sycamoreone:

As said earlier (elsewhere), what I need quickly is a mere yes/no answer regarding if it’s OK to stop shipping this file (that we have been shipping for a while). An awesome design to do all the random stuff nicely can wait a bit more. I won’t tell you what is the answer that would make my life easier, in order not to corrupt your reasoning (even though a quick look at the related tickets would trivially give you this info).

Full disclosure so you understand better my timeline, that is a bit tighter than what I’ve communicated to both of you previously (by ~2 weeks): ideally I need the yes/no answer in time for me to propose updating debootstrap to the version from jessie-backports in time for the Tails 2.2 freeze (February 24), which will unblock Feature #6297, that is part of something I need to complete by April 15, and 2.2 is our last major release before this deadline, so if I miss it it’ll be a bit crazy.

So ideally I need the yes/no answer by the end of next week (February 21). Does this sound plausible? If it doesn’t, please do publish whatever notes/results you have already, so I can deal with my deadline myself without reinventing a wheel that you are apparently already inventing twice.

Thanks in advance!

#39 Updated by bertagaz 2016-02-14 14:06:24

  • Assignee changed from bertagaz to intrigeri
  • QA Check set to Info Needed

intrigeri wrote:
> bertagaz, sycamoreone:
>
> As said earlier (elsewhere), what I need quickly is a mere yes/no answer regarding if it’s OK to stop shipping this file (that we have been shipping for a while). An awesome design to do all the random stuff nicely can wait a bit more. I won’t tell you what is the answer that would make my life easier, in order not to corrupt your reasoning (even though a quick look at the related tickets would trivially give you this info).

Sorry for the lag, I was documenting to work on all the related questions, a bit too broad I guess.

My answer on the very question of this ticket is: whatever. :)

Having only "`date +s.%N`" or `"date +s.%N` + a known seed" doesn’t change the amount of bits of entropy the seeding operation brings. So we could as well remove it if it’s what you prefer.

#40 Updated by intrigeri 2016-02-15 10:05:33

  • Assignee changed from intrigeri to sycamoreone
  • QA Check changed from Info Needed to Ready for QA

> My answer on the very question of this ticket is: whatever. :)

> Having only "`date +s.%N`" or `"date +s.%N` + a known seed" doesn’t change the amount of bits of entropy the seeding operation brings. So we could as well remove it if it’s what you prefer.

sycamoreone, can you please check if this matches your conclusions?

#41 Updated by intrigeri 2016-02-18 16:43:12

> Sorry for the lag, I was documenting to work on all the related questions, a bit too broad I guess.

Note that for “all the related questions”, I’m told that some people met at 32c3 and came up with a plan (that is left to be published, I think).

#42 Updated by bertagaz 2016-02-18 17:54:52

intrigeri wrote:
> Note that for “all the related questions”, I’m told that some people met at 32c3 and came up with a plan (that is left to be published, I think).

Yeah, heard about that, but didn’t see nothing yet, and still wondering if it did happen.

#43 Updated by intrigeri 2016-02-21 13:24:39

  • related to deleted (Feature #7646: Investigate whether we should ship /var/lib/systemd/random-seed)

#44 Updated by intrigeri 2016-02-21 13:24:49

  • has duplicate Feature #7646: Investigate whether we should ship /var/lib/systemd/random-seed added

#45 Updated by intrigeri 2016-02-21 15:02:31

  • Subject changed from Investigate whether we should ship /var/lib/urandom/random-seed to Investigate whether we should resume shipping a static random seed
  • Priority changed from High to Elevated

On Tails 2.x we ship /var/lib/urandom/random-seed, that would be used by the urandom initscript… except that initscript is masked by urandom.service, so what matters now is how /lib/systemd/systemd-random-seed load behaves in the absence of any /var/lib/systemd/random-seed (Tails 2.0.1 ships no such file).

My understanding of the source code (229-1) is that in this case, systemd-random-seed load won’t write anything to /dev/urandom (so we rely purely on the kernel and current system entropy to get /dev/urandom right). This is basically what Jake suggested earlier on this ticket, combined with Feature #10779. Given we’ve been in undefined behavior area forever, this new behavior can’t be much worse, and the fact it’s the new debootstrap and systemd default behavior tends to reassure me somewhat.

So, my course of action from here will be:

  1. I’m retitling this ticket so that it reflects what is the baseline (that is, the current situation).
  2. I’ll make this ticket not block Bug #9262 and Feature #6297 anymore => this ticket becomes less urgent, and it can be addressed as part of the randomness big picture.
  3. I’ll try to handle Feature #10779 in time for Tails 2.2, to mitigate regressions that not seeding urandom at all anymore might have brought.

[In passing, in this 1st boot without seed situation, systemd-random-seed load will read some data from /dev/urandom and save it to /var/lib/systemd/random-seed so that next boot (on a non-amnesic system) has a seed, just in case since systemd-random-seed save would normally do it at shutdown time.]

#46 Updated by intrigeri 2016-02-21 15:02:45

  • blocked by deleted (Bug #9262: Port our ISO build system to Jessie)

#47 Updated by intrigeri 2016-02-21 15:02:50

  • blocked by deleted (Feature #6297: Save list of packages used at ISO build time)

#48 Updated by cypherpunks 2016-03-02 03:30:42

Just want to add some input here regarding `date +s.%N`. I think it’s redundant. I’m pretty sure the Linux kernel already seeds the entropy pool with the data on start up, in addition to various other aspects unique to devices on the system (MAC addresses, internal states, UUIDs, etc). I’m not 100% sure that it seeds it with the current date or only with per-boot jiffies.

http://lxr.free-electrons.com/source/drivers/char/random.c
http://lxr.free-electrons.com/ident?i=add_device_randomness

#49 Updated by sycamoreone 2016-04-03 17:40:03

  • Target version changed from Tails_2.2 to Tails_2.3

#50 Updated by anonym 2016-05-08 05:10:24

  • Target version changed from Tails_2.3 to Tails_2.4

#51 Updated by kurono 2016-05-31 17:26:31

As discussed in the IRC, I have been reading about this ticket and decided to help a little bit.
I have improved the blueprint and proposed an complementary solution to the randomness seeding problem in Tails.
The new blueprint is here:
https://git-tails.immerda.ch/kurono/tails/log/?h=fix/7642-static-random-seed
Any feedback is welcome.

#52 Updated by intrigeri 2016-05-31 18:08:29

> The new blueprint is here: https://git-tails.immerda.ch/kurono/tails/log/?h=fix/7642-static-random-seed

Merged, so we can now see it on the live website.

#53 Updated by anonym 2016-06-08 01:34:53

  • Target version changed from Tails_2.4 to Tails_2.5

#54 Updated by intrigeri 2016-06-09 12:50:53

hi kurono!

kurono wrote:
> Any feedback is welcome.

I’ve read your blueprint update, and quite some parts of it lack some post-Wheezy updates, and are comparing stuff with the “same known and constant seed file” scenario, even though (as other text you pasted to the blueprint shows) it is obsolete. Can you please fix that?

Also, what’s new in this blueprint update is actually about a way to implement Feature #7675, so let’s follow-up on this there :) Spoiler: I like the idea! And it’s fully compatible with the ideas that were already on Feature #7675 :)

Now, giving back this ticket to sycamoreone, for the review that should allow us to close it.

#55 Updated by intrigeri 2016-08-02 09:31:53

  • Target version changed from Tails_2.5 to Tails_2.6

#56 Updated by sycamoreone 2016-08-15 08:13:00

Yet another point to keep in mind: The /dev/random driver will be changed in the 4.8 release: http://lkml.iu.edu/hypermail/linux/kernel/1607.3/00275.html

In particular the notes say that:

> This set of patches also […] and will take advantage of a hw random number
> generator (if present) to initialize the /dev/urandom pool.

It might be, that this solves part of our problems.

> random: initialize the non-blocking pool via add_hwgenerator_randomness()

#57 Updated by Dr_Whax 2016-08-20 12:11:38

  • Description updated

#58 Updated by Dr_Whax 2016-08-20 12:12:50

  • Target version changed from Tails_2.6 to 2017

#59 Updated by kurono 2016-09-12 02:18:42

I have added some changes to the blueprint, regarding the Tails Installer solution and how to generate secure random
numbers in Python by standard libraries, that work on several OS. The changes are in the branch kurono:fix/7642-static-random-seed.

I am not sure whether this should go here, or in another ticket. My opinion is that this ticket is already solved.

#60 Updated by intrigeri 2016-09-12 03:01:19

> I have added some changes to the blueprint, regarding the Tails Installer solution and how to generate secure random numbers in Python by standard libraries, that work on several OS. The changes are in the branch kurono:fix/7642-static-random-seed.

Merged!

> I am not sure whether this should go here, or in another ticket. My opinion is that this ticket is already solved.

I’ll let you discuss this with those who are leading the randomness effort :)

#61 Updated by intrigeri 2017-07-25 07:17:44

  • Assignee changed from sycamoreone to Dr_Whax

sycamoreone has not been active on this ticket for 11 months, so reassigning to another member of this team.

#62 Updated by BitingBird 2017-08-28 20:04:49

  • Description updated

#63 Updated by BitingBird 2017-08-28 20:06:16

#64 Updated by Anonymous 2018-01-15 14:10:27

  • Target version changed from 2017 to 2018

2017 is over.

#65 Updated by Anonymous 2018-08-18 13:11:53

  • related to Feature #11898: Have a readable blueprint about randomness in Tails added

#66 Updated by Anonymous 2018-08-18 13:13:37

Kurono said he thinks this ticket is solved. What do you think?
In the blueprint you say a random seed will make the build unreproducible?
I’m unsure what the status for this ticket is. Can you please try to clarify this?

#67 Updated by segfault 2018-08-22 10:20:56

u wrote:
> Kurono said he thinks this ticket is solved. What do you think?
> In the blueprint you say a random seed will make the build unreproducible?

It would make the build unreproducible if we would ship a per-build generated random seed in the ISO, which we do not.

> I’m unsure what the status for this ticket is. Can you please try to clarify this?

I’m also unsure. I think we investigated whether we should ship a random seed, the results are on the blueprint, and we have worked on two tickets which will improve the situation (Feature #7675 and Feature #11897).

We don’t have a solution to provide unique random seeds in the ISO / USB image, so we could keep this ticket open to investigate this further - but I don’t think there is any solution to this and that we won’t have another choice than to rely on entropy gathering mechanisms during first boot of a USB image / during every boot of an ISO.

#68 Updated by intrigeri 2018-08-22 11:00:12

> It would make the build unreproducible if we would ship a per-build generated random seed in the ISO, which we do not.
> […]
> We don’t have a solution to provide unique random seeds in the ISO / USB image

If “unique” means “per-release but shared between all Tails version N on first boot”, then we could ship a per-release generated random seed in the ISO, e.g. based on the Git commit the tag points to.

#69 Updated by segfault 2018-08-22 11:03:36

intrigeri wrote:
> > It would make the build unreproducible if we would ship a per-build generated random seed in the ISO, which we do not.
> > […]
> > We don’t have a solution to provide unique random seeds in the ISO / USB image
>
> If “unique” means “per-release but shared between all Tails version N on first boot”, then we could ship a per-release generated random seed in the ISO, e.g. based on the Git commit the tag points to.

I don’t think that would help, we would need a random seed that is unique per boot device.

#70 Updated by intrigeri 2018-08-22 11:34:06

> I don’t think that would help, we would need a random seed that is unique per boot device.

I got that part, I was confused by the discussion about reproducibility (most users don’t build their own ISO so I inferred the question was about what we ship in the ISO, which can’t possibly be unique per device). So the question is: is no seed at all better or worse, for first boot, that one that’s shared by all Tails of a given version. I did not read the blueprint recently so I’ll shut up now, because I assume that’s exactly of the questions the blueprint answers :)

#71 Updated by segfault 2018-08-22 12:42:36

intrigeri wrote:
> > I don’t think that would help, we would need a random seed that is unique per boot device.
>
> I got that part, I was confused by the discussion about reproducibility (most users don’t build their own ISO so I inferred the question was about what we ship in the ISO, which can’t possibly be unique per device).

The part about reproducibility was unrelated to the part about the status of the ticket, i.e. whether we should investigate further.

> So the question is: is no seed at all better or worse, for first boot, that one that’s shared by all Tails of a given version. I did not read the blueprint recently so I’ll shut up now, because I assume that’s exactly of the questions the blueprint answers :)

Yes, that is answered in the blueprint: “Tails does not ship /var/lib/urandom/random-seed in the ISO, since it means shipping a fixed known value for every Tails installation, which in turn means that entropy contribution would be zero”. Shipping a seed does not provide better non-predictable randomness (it’s also not worse than no seed, but why should we ship it if it doesn’t have any benefit).

So, do we agree that we can close this as resolved?

#72 Updated by intrigeri 2018-08-22 13:10:43

  • Status changed from In Progress to Resolved
  • Assignee deleted (Dr_Whax)
  • QA Check changed from Ready for QA to Pass

Yes! Thank you all :)