Tails

#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?

#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).

#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 ?

#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 :)

#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?

#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.

#32 Updated by intrigeri 2016-01-02 04:28:45

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

#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.

#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.)

#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!

#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.

#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

#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.

#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.

#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()

#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 :)

#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?