Project

General

Profile

Feature #16977

Consider crediting some of the entropy we add from an unused sector

Added by intrigeri about 1 month ago. Updated about 1 month ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

Discussion on this started on #11897 and there we agreed it was not a blocker for the initial iteration.

Crediting the entropy would cause the entropy pool to be marked as initialized, thereby:

  • Preventing warnings being printed during boot, like
    random: sgdisk: uninitialized urandom read (16 bytes read)

    and

    random: get_random_bytes called from start_kernel+0x94/0x52e with crng_init=0
  • Allowing programs which block until the entropy pool is initialized to run earlier (relevant for #16891)
  • Allowing us to check whether the entropy was actually added, by comparing /proc/sys/kernel/random/entropy_avail before and after adding the entropy

segfault's proposal is to credit up to the amount of entropy available when the seed was updated, i.e. the content of /proc/sys/kernel/random/entropy_avail.


Related issues

Blocked by Tails - Feature #11897: Persist a random seed across boots Needs Validation 11/04/2016

History

#1 Updated by intrigeri about 1 month ago

#2 Updated by segfault about 1 month ago

  • Description updated (diff)

Continuing the discussion from #11897#note-72

cypherpunks:

So I don't see why we shouldn't credit this entropy.

Because someone can retroactively determine the entropy pool contents (or a subset). Do you really want someone to be able to grab the flash drive, then from the stored seed, reconstruct a reduced keyspace for brute forcing the LUKS device?

The random seed is updated both during boot and during shutdown. So the only scenario where the random seed stored on the device would actually be the same as the one used to seed the entropy before creating the LUKS partition, is when the user never booted the device after creating the LUKS partition and didn't shut it down properly.

Also note that currently creating the LUKS partition doesn't require the entropy pool to be initialized (see #16891). As long as this is the case, it doesn't matter at all for this scenario whether we credit the entropy or not.

#3 Updated by segfault about 1 month ago

  • Description updated (diff)

#4 Updated by cypherpunks about 1 month ago

So the only scenario where the random seed stored on the device would actually be the same as the one used to seed the entropy before creating the LUKS partition, is when the user never booted the device after creating the LUKS partition and didn't shut it down properly.

Because flash drives use dynamic wear leveling, you'll be able to access most previous copies of the seed, including the one used when creating the LUKS partition. If it is created without waiting for naturally secret entropy (e.g. precise interrupt timing) and instead immediately after entropy is manually credited, then the majority of that credited entropy is written on the same device (in some unused sector) that holds the LUKS header.

Also note that currently creating the LUKS partition doesn't require the entropy pool to be initialized (see #16891). As long as this is the case, it doesn't matter at all for this scenario whether we credit the entropy or not.

Well that's unfortunate.

#5 Updated by segfault about 1 month ago

Because flash drives use dynamic wear leveling, you'll be able to access most previous copies of the seed, including the one used when creating the LUKS partition.

That's a good point.

Also available in: Atom PDF