Project

General

Profile

Feature #7642

Investigate whether we should resume shipping a static random seed

Added by anonym about 3 years ago. Updated about 2 months ago.

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

0%

QA Check:
Ready for QA
Feature Branch:
Type of work:
Research

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 gatheringConfirmedsycamoreone


Related issues

Related to Tails - Feature #6116: Audit random seed Confirmed
Related to Tails - Feature #7675: Persist entropy pool seeds Confirmed 11/04/2016
Related to Tails - Feature #11897: Create random seed at installation time with Tails Installer In Progress 11/04/2016
Duplicated by Tails - Feature #7646: Investigate whether we should ship /var/lib/systemd/random-seed Duplicate 07/23/2014

History

#1 Updated by intrigeri about 3 years ago

  • Priority changed from Elevated to High

#2 Updated by intrigeri about 3 years ago

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

#3 Updated by intrigeri about 3 years ago

  • 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 about 3 years ago

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

#5 Updated by intrigeri about 3 years ago

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 about 3 years ago

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 about 3 years ago

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 #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 about 3 years ago

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

I've left a relevant comment on #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 about 3 years ago

#10 Updated by cypherpunks about 3 years ago

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 about 3 years ago

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

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

#12 Updated by intrigeri about 3 years ago

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 #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 about 3 years ago

#14 Updated by intrigeri about 3 years ago

So, the long-term plan, for persistence users, is #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 about 3 years ago

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

#16 Updated by intrigeri about 3 years ago

  • 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 about 3 years ago

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

Postponing, again.

#18 Updated by intrigeri almost 3 years ago

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

#19 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

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

#21 Updated by intrigeri over 2 years ago

  • Assignee deleted (intrigeri)

#22 Updated by intrigeri over 2 years ago

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

#23 Updated by intrigeri about 2 years ago

That's the only remaining blocker for porting our ISO build system to Jessie (#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 about 2 years ago

  • Assignee set to bertagaz

#25 Updated by intrigeri about 2 years ago

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

#26 Updated by intrigeri about 2 years ago

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

Ping?

#27 Updated by intrigeri almost 2 years ago

  • 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 (#5926), via #9262 and #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 almost 2 years ago

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

#29 Updated by sycamoreone almost 2 years ago

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 almost 2 years ago

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 #9262#note-26) any technical reason why this ticket is a blocker instead of #7646?

(

#31 Updated by bertagaz almost 2 years ago

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 #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 #9262#note-26) any technical reason why this ticket is a blocker instead of #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 almost 2 years ago

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 almost 2 years ago

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

#36 Updated by sycamoreone almost 2 years ago

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 over 1 year ago

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

#38 Updated by intrigeri over 1 year ago

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 #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 over 1 year ago

  • 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 over 1 year ago

  • 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 over 1 year ago

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 over 1 year ago

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 over 1 year ago

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

#44 Updated by intrigeri over 1 year ago

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

#45 Updated by intrigeri over 1 year ago

  • 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 #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 #9262 and #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 #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 over 1 year ago

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

#47 Updated by intrigeri over 1 year ago

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

#48 Updated by cypherpunks over 1 year ago

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 over 1 year ago

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

#50 Updated by anonym over 1 year ago

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

#51 Updated by kurono over 1 year ago

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 over 1 year ago

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 over 1 year ago

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

#54 Updated by intrigeri over 1 year ago

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

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

#55 Updated by intrigeri about 1 year ago

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

#56 Updated by sycamoreone about 1 year ago

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 about 1 year ago

  • Description updated (diff)

#58 Updated by Dr_Whax about 1 year ago

  • Target version changed from Tails_2.6 to 2017

#59 Updated by kurono about 1 year ago

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 about 1 year ago

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 3 months ago

  • 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 about 2 months ago

  • Description updated (diff)

#63 Updated by BitingBird about 2 months ago

  • Related to Feature #11897: Create random seed at installation time with Tails Installer added

Also available in: Atom PDF