Feature #16977

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

Added by intrigeri 2019-08-14 06:12:04 . Updated 2019-10-15 13:12:02 .

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

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Discussion on this started on Feature #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 Feature #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.

Subtasks

History

#1 Updated by intrigeri 2019-08-14 06:12:34

#2 Updated by segfault 2019-08-14 09:38:06

  • Description updated

Continuing the discussion from Feature #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 Feature #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 2019-08-14 15:06:05

  • Description updated

#4 Updated by cypherpunks 2019-08-14 22:23:43

> 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 Feature #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 2019-08-15 07:33:58

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

#6 Updated by segfault 2019-10-15 05:41:40

I would like to reject this ticket, because I am now convinced that it’s a bad idea to credit the entropy of a seed we store unencrypted. But it seems like I don’t have the permission to set the ticket status to “Rejected”.

#7 Updated by intrigeri 2019-10-15 12:24:34

> But it seems like I don’t have the permission to set the ticket status to “Rejected”.

I believe you do have the permission, but one can’t close a ticket that is blocked by another one :)

#8 Updated by segfault 2019-10-15 13:10:00

#9 Updated by segfault 2019-10-15 13:12:02

  • Status changed from Confirmed to Rejected

intrigeri wrote:
> > But it seems like I don’t have the permission to set the ticket status to “Rejected”.
>
> I believe you do have the permission, but one can’t close a ticket that is blocked by another one :)

Ah yes, that was the problem, thanks :)