Project

General

Profile

Feature #16977

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

Added by intrigeri 3 months ago. Updated 30 days ago.

Status:
Rejected
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.

History

#1 Updated by intrigeri 3 months ago

#2 Updated by segfault 3 months 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 3 months ago

  • Description updated (diff)

#4 Updated by cypherpunks 3 months 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 3 months 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.

#6 Updated by segfault about 1 month ago

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 30 days ago

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 30 days ago

  • Blocked by deleted (Feature #11897: Persist a random seed across boots)

#9 Updated by segfault 30 days ago

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

Also available in: Atom PDF