Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 939
    • Issues 939
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 30
    • Merge requests 30
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #17154

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
Time tracking