Why DiceSecret?

Back to demo

DiceSecret provides a user-controlled, physically generated, independently verifiable source of cryptographic entropy for creating high-value root secrets.

For rare, high-value root secrets, DiceSecret deliberately moves the entropy source outside the computer. Modern operating-system cryptographic random number generators, including Linux, are strong when correctly initialized and uncompromised. The advantage here is different: the physical entropy exists in an independent failure domain, can be witnessed by the user, and can be transformed by deterministic software that is separately auditable.

The problem it addresses

Strong cryptographic algorithms still depend on secret values being generated unpredictably. A mathematically strong cipher, signature scheme, or wallet can fail if its keys come from a weak or predictable randomness source.

Standards treat entropy generation as a security problem in its own right. NIST SP 800-90B specifies requirements for entropy sources, SP 800-90C describes complete random-bit generator constructions, and IETF RFC 4086 explains that secret, unguessable numbers are at the heart of cryptographic systems.

Two separate questions matter:

Is the cryptographic algorithm strong?
Was the secret actually selected unpredictably from the space we think it was?

DiceSecret is aimed at the second question.

Why an independent physical source can matter

Normally, when software displays a newly generated secret, the user trusts a large stack: hardware, firmware, operating-system entropy, cryptographic libraries, application code, build infrastructure, and sometimes JavaScript delivered over a network.

With physical dice, the user supplies the source observations. The software can then make a smaller claim: it deterministically transformed the physical results that the user witnessed into the requested bits.

Independent entropyThe secret does not depend solely on one machine RNG.

Observable sourceThe physical events exist before the software transforms them.

Verifiable calculationOpen deterministic rules can be reproduced independently.

Human recoveryThe same final bits can be represented as hex or reversible word formats.

This failure mode has happened in the real world

Debian OpenSSL, 2006-2008

A Debian-specific change crippled OpenSSL randomness and made affected cryptographic keys guessable. SSH, TLS, OpenVPN, DNSSEC, and other key material had to be regenerated.

Weak RSA and DSA keys at Internet scale

The 2012 "Mining Your Ps and Qs" study recovered many private keys because devices generated insufficiently random values, including shared RSA prime factors and vulnerable DSA signatures.

Android Bitcoin wallets, 2013

Bitcoin users were warned that defects in Android secure randomness could make wallet private keys vulnerable to theft.

Dual_EC_DRBG

NIST ultimately removed this standardized random-number generator after concerns that its design and unexplained parameters could permit prediction by an entity with secret information.

These examples do not mean modern random generators are generally unsafe. They demonstrate why the randomness layer itself is part of the trusted computing base.

Why dice, and why 128 to 256 bits?

For ideal fair independent six-sided dice, one roll has log2(6), or about 2.585, bits of raw source information. That makes the physical scale unusually convenient:

50 d6 rollsabout 129.25 raw bits

100 d6 rollsabout 258.50 raw bits

Fifty fair d6 outcomes therefore carry slightly more than 128 raw bits. Because 6^50 is not a power of two, an exact unbiased 128-bit extraction cannot use every possible 50-roll sequence. DiceSecret's exact extractor succeeds from exactly 50 d6 results about 84.2% of the time; otherwise it requests additional rolls rather than introduce conversion bias.

Those quantities line up naturally with common 128-bit and 256-bit security targets. A purpose-built electronic entropy source is a serious engineering component: standards such as NIST SP 800-90B deal with noise-source behavior, entropy estimation, health testing, and conditioning. Ordinary dice are not a certified hardware RNG, but they provide an inexpensive, observable physical source at exactly the low data rate needed for a root-secret ceremony.

Important: exact base-6 extraction does not prove that a physical die is perfectly fair. Physical bias is a different property of the entropy source. The stated raw-bit figures assume ideal fair independent dice.

Computer vision makes the manual ceremony practical

Generating 128 bits from dice by hand has always been possible. The painful part is operational: roll roughly 50 dice, preserve a deterministic order, record every value without a transcription error, and then perform or verify the conversion into bits.

Bulk packs of 50 ordinary d6 dice can often be found for around $10 or less. DiceSecret lets all 50 be thrown together and uses the trained vision model to read, order, and accumulate the results. With a clean throw and a short 10 to 20 second camera sweep, a one-batch 128-bit ceremony can complete in under about 30 seconds. If the exact extractor lands in its rejection region, or the reader skips dice, the user simply supplies more physical rolls.

The practical idea: for roughly the cost of a cheap 50-die pack and less than a minute of attention, a user can create a high-entropy physical root-secret input that they personally witnessed, while the software handles the tedious reading, ordering, and exact conversion work.

An observable and reproducible ceremony

physical dice->ordered results->deterministic extraction->128/256-bit value->hex / words / recovery

The goal is not to prove after the fact that randomness was random. The useful verification property is that a separate implementation can take the same witnessed observations and verify the deterministic entropy-to-secret calculation.

Why use an independent physical entropy source?

Modern operating-system CSPRNGs are designed for cryptographic use and are appropriate for routine key generation. DiceSecret addresses a different goal: reducing reliance on any single machine-based entropy path when creating a rare, high-value root secret.

History shows that randomness failures can arise from implementation mistakes, initialization problems, weak entropy sources, and hardware behavior. Published research has also demonstrated attacks against hardware true-random-number generators, including frequency injection through a power supply and electromagnetic analysis of ring-oscillator-based designs. These results do not imply that machine RNGs are generally weak. They show that entropy generation is part of the trusted computing base and can have failure modes of its own.

A privately rolled dice ceremony places the source observations outside the hardware, firmware, operating system, and application stack that will process or later use the secret. That independence is the useful property: a weakness in one machine-based entropy path does not become the sole origin of the root secret.

Why long-lived root secrets deserve extra care

A root secret may be created once and expected to remain trustworthy for many years, sometimes for an unknown lifetime. Over long periods, implementations, platforms, and security assumptions change, and previously unknown weaknesses can be discovered.

Using an independently generated physical source reduces the number of assumptions that must remain valid about the machine that happened to generate the secret years earlier. The dice results can be witnessed, documented, and processed by a public deterministic extractor, so the origin of the secret is not dependent solely on one historical RNG implementation.

This does not future-proof the cryptographic system that later uses the secret. Algorithms can become obsolete, implementations can leak keys, and secrets can be mishandled. DiceSecret addresses the narrower problem of how the root secret was generated.

The strongest intended form is offline

This hosted site is a demonstration of the DiceSecret workflow. The strongest intended deployment is an offline application in which camera frames, ordered dice observations, browser or application mixing, and the final secret are processed locally on a device that does not need to send the ceremony over a network.

private dice ceremony->local vision model->verified dice transcript->public deterministic extraction->local secret

The trained computer-vision model is the automation layer that makes the ceremony fast. The deterministic entropy extraction, encoding rules, test vectors, and independent verification logic can remain public and auditable even if a future offline application distributes the trained vision models under a separate commercial or licensed model.

Shipping that strongest version requires more than turning off a network connection. It requires local inference packaging, model-distribution and licensing decisions, signed builds, update and verification mechanisms, platform work, and sustained development. That may ultimately require commercial funding, licensing, partnerships, or other support.

Interested in an offline version?

Interest from potential users, security teams, wallet or key-management projects, deployment partners, or organizations interested in funding development would help determine whether a fully offline product is practical.

Project contact: admin@dicesecret.com

What DiceSecret does not solve

Physical dice bias: mathematical extraction removes base-conversion bias, not physical source bias. The stated entropy figures assume sufficiently fair, independent dice.
Malicious software: a compromised page can still steal or replace a secret. Physical entropy alone does not make malicious software trustworthy.
Poor secret handling: screenshots, cloud QR scanners, printer spools, backups, malware, or insecure storage can expose a correctly generated secret later.
Routine randomness: this is not a replacement for the operating-system CSPRNG used for ordinary ephemeral cryptographic randomness.

What this hosted demo adds

The demo uses computer vision to read and order physical d6 results. When Private browser mix is enabled, the browser also generates private random bytes with Web Crypto and XORs them with the dice-derived result. The inference server therefore sees the dice-derived side, but not the final mixed secret.

The public-demo work is intended to minimize retention, separate the browser application from inference, and make the delivered build independently identifiable. Those measures strengthen the demonstration, but they do not turn a hosted web application into the final trust model. The strongest intended form remains fully offline local inference.

Where this is most useful

DiceSecret is deliberately manual. It is most defensible for rare, high-value root secrets where the ceremony and independent verification are worth the effort: long-lived wallet roots, offline master material, or other secrets whose compromise would be unusually costly.