IdeaWell

Project ideas from Hacker News discussions.

AMD's random number generator can't generate a 0?

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1 – Distrust of hardware RNGs (potential backdoors / lack of auditability)
Many commenters worry that relying on a single, sealed hardware source like Intel’s RDRAND could hide a backdoor. As leonidasrup quoted Theodore Ts’o:

“I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction.”

Theme 2 – The AMD Zen2 RDRAND zero‑missing bug
A large part of the thread focuses on the observation that rdrand16 on Zen2 never returns zero (or reports an error). Users reproduced the issue and debated its relevance. For example, jstanley noted:

“I can reproduce it with rdrand16, rdrand32 is fine but rdrand16 can never generate all 0s.”

Theme 3 – Best practices for random number generation
Discussants repeatedly stress that secure randomness should come from multiple, mixed sources and that rolling your own RNG is risky unless you have no alternative. strenholme explained his approach:

“I use, in security critical contents of my software … a type of random number generator called an XOF (extendable‑output function).”
Others, like sltkr, added:
“The only legitimate reason to roll your own is when you're developing for an embedded system or a bootloader … where there is no kernel API available.”

🚀 Project Ideas

RDRAND Zero‑Bias Detector

Summary

  • A lightweight CLI tool that repeatedly executes RDRAND/RDSEED instructions and checks for stuck‑at‑zero or other bias patterns (e.g., the Zen 2 zero‑bug) using simple statistical tests.
  • Core value: gives developers and system admins an quick, auditable way to verify that their hardware RNG behaves as expected before relying on it for cryptographic workloads.

Details

Key Value
Target Audience Security‑conscious developers, DevOps engineers, hardware vendors
Core Feature Run configurable numbers of RDRAND/RDSEED invocations, output histogram, flag any value with observed frequency deviating beyond a configurable threshold (e.g., zero count = 0)
Tech Stack C (or Rust) with inline asm/syscalls for RDRAND, optional use of perf counters for statistical analysis; build with Makefile/Cargo
Difficulty Low
Monetization Hobby

Notes

  • HN commenters highlighted the Zen 2 RDRAND never‑zero issue and expressed distrust of unauditable hardware RNGs; a simple detector would let them confirm or rule out such bugs on their own machines (as jstanley did).
  • Could spark discussion on best practices for hardware RNG validation and be integrated into CI pipelines for security‑critical builds.

EntropyXOF Attestation Service

Summary

  • A hosted API that combines multiple entropy sources (software timers, user input, network jitter, optional hardware RNG) through a cryptographic XOF (e.g., SHAKE256) and returns signed entropy blobs with proof of provenance.
  • Core value: provides applications with verifiable, high‑quality entropy that mitigates reliance on any single potentially backdoored hardware source.

Details

Key Value
Target Audience SaaS providers, fintech, blockchain nodes, any service needing trustworthy randomness
Core Feature Accepts client‑provided entropy seeds, mixes them with internal timed jitter via XOF, returns base64‑encoded output plus a signed attestation (using a service key) that the output was generated correctly
Tech Stack Go or Rust backend, SHAKE256 from std crypto libs, ED25519 signatures for attestation, deployed on Kubernetes with TLS
Difficulty Medium
Monetization Revenue-ready: Subscription tiered (free dev tier, paid per‑GB entropy)

Notes

  • Commenters such as strenholme and Taek advocated mixing entropy from multiple sources and using XOFs to defeat hardware backdoors; this service offers that as a turnkey solution.
  • Enables practical debate about remote attestation of entropy and could be used by projects that currently rely on /dev/urandom but want stronger guarantees.

SecureEntropy Mixer Library

Summary

  • An easy‑to‑link C/Rust library that lets applications combine entropy from RDRAND, getentropy, CPU jitter, and user‑supplied sources using a proven XOF construction, with optional runtime health checks to downweight biased sources.
  • Core value: delivers cryptographically strong random numbers while protecting against a single compromised or faulty entropy source, addressing the "don’t roll your own RNG" fear with a vetted building block.

Details

Key Value
Target Audience Library authors, embedded firmware developers, crypto‑toolkit maintainers
Core Feature API secure_random_buf(buf, len) that internally gathers entropy from configurable sources, feeds them into SHAKE256/XOF, and can detect and suppress sources that exhibit bias (e.g., repeated zeros)
Tech Stack C11 with optional intrinsics for RDRAND; Rust version using rand_core and sha3 crates; minimal dependencies, no syscalls beyond clock_gettime
Difficulty Medium
Monetization Hobby (MIT/Apache‑licensed)

Notes

  • The thread highlighted strenholme’s XOF‑based RNG and concerns about kernel RNG reliability; this library gives developers a secure, auditable alternative that can be used in userspace or freestanding environments.
  • Provides a concrete tool for the discussion on mixing entropy sources and could become a reference implementation for secure RNG in projects ranging from TLS libraries to hardware wallets.

Read Later