Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
T
tails
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 952
    • Issues 952
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 10
    • Merge Requests 10
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • tails
  • tails
  • Issues
  • #17154

Closed
Open
Opened Oct 15, 2019 by segfault@segfaultMaintainer

Improve entropy gathering

Originally created by @segfault on #17154 (Redmine)

The Linux kernel uses multiple sources of randomness to initialize its cryptographically secure pseudo-random number generator (CSPRNG). This includes various sources with dubious quality wrt. randomness: the kernel command-line, serial numbers, MAC addresses, timing information…

This is totally fine, because most of these sources are not credited as good/reliable entropy, which means that the values are mixed into the entropy pool, but they do not increase the entropy counter. (By default, the kernel currently only credits inter-interrupt timings and inter-keyboard timings).

When the entropy counter reaches a certain threshold (currently 512 bits, but it’s currently being discussed on the kernel mailing list to reduce that to 256 bits) is the entropy pool marked as initialized.

Until the entropy pool is marked as initialized, reads from /dev/random and calls to the getrandom syscall are blocking, and reads from /dev/urandom return not-cryptographically secure random numbers.

If the entropy pool is seeded with predictable inputs, all of /dev/random, /dev/urandom, and getrandom return not-cryptographically secure random numbers.

Both Debian and Tails currently add additional sources which do increase the entropy counter. I would like to re-evaluate the use of those sources.

Related issues

  • Related to #7102
  • Related to #5650 (closed)
  • Related to #17124 (closed)
  • Related to #17443 (closed)
  • Related to #16891
Edited Jun 28, 2020 by segfault
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tails/tails#17154