中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC016
Before a blockchain application relies on a newly generated key, its team needs evidence about the process that produced it. Which maintained component generated it? Was the environment initialized correctly? Could a test image have copied secret state? What happens when generation fails? A long, random-looking output cannot answer these readiness questions.
This article is a pre-use review lab for a fictional museum’s twenty-device blockchain-record project. The deliverable is an acceptance plan: evidence to request, failure cases to test, and reasons to withhold approval. It does not generate real keys or teach readers to repair production wallets. No classroom value should protect real assets or accounts.
For entropy, probability, statistical tests and their mathematical limits, use the existing Why Mathematics? Random Number Generators, Entropy and Statistical Tests. This lesson applies those foundations to a narrower engineering decision: whether a specific key-generation workflow is ready for its intended blockchain role.
Choose your reading route
In this guide
- 1. Define the key’s role before approving its generator
- 2. Ask for a process map, not a sample secret
- 3. Keep one concise randomness model in view
- 4. Separate arithmetic tests from deployment evidence
- 5. Identify what changed between prototype and deployment
- 6. Define acceptance and stopping conditions in advance
- 7. Fictional project review: twenty display devices
- 8. Use key-generation APIs for their actual purpose
- 9. Do not confuse private-key generation with every nonce
- 10. A review checklist without collecting secrets
- 11. Practice: decide whether the evidence is sufficient
- 12. Frequently asked questions
- Sources and next reading
For a project meeting, read the role definition, evidence requests, twenty-device scenario and acceptance checklist. For testing work, focus on environment differences, copied state and visible failure behavior. The short randomness reminder links back to the mathematical prerequisite rather than repeating its investigations.
The previous article explained key derivation and identity binding. This article stops at generation and readiness for enrollment. Ongoing custody, backup operations, transaction approval and incident response receive separate treatment later in the series.
Back to contents · Next section
1. Define the key’s role before approving its generator
The museum wants its devices to submit signed exhibit-record updates to a fictional controlled blockchain. Each device’s submission identity will be enrolled under an explicit policy after generation and verification. This is a teaching project, not a design for a public validator network.
The team also uses transport credentials and administrator access. Those roles should not be treated as interchangeable merely because they all involve cryptography. The review identifies which key is being generated and which operations it will authorize. A test that validates one role cannot silently approve every secret on the device.
Write the scope as a sentence: “This review covers generation of the device’s record-submission signing key before enrollment in the specified demonstration network.” Then identify the target algorithm, implementation, parameters and operating environment. Do not choose them by copying a key length from an unrelated system.
The blockchain cannot look backward into the factory and certify how the key was created. A transaction signature might verify perfectly even if the private key was copied from a test image. Correct use of a key after generation is not proof of independent, unpredictable generation.
Back to contents · Next section
2. Ask for a process map, not a sample secret
The first evidence request is a map of components and boundaries. It should name the platform key-generation interface, the maintained cryptographic implementation, the relevant configuration, and how the application receives either a usable key object or a failure result.
The map also records what is persistent, what is created at installation, what is created at first launch, and what is restored from an image. These distinctions turn the vague question “is our randomness good?” into concrete questions about state and lifecycle.
No reviewer needs a production private key to inspect that map. Ask for documentation, configuration references, non-secret test results and clearly isolated test fixtures. A process that requires staff to paste secret material into an ordinary ticket or chat creates a new exposure rather than supplying good review evidence.
The museum distinguishes claims from evidence. “Uses a secure library” is a claim. An identified version, documented key-generation path, confirmed production configuration and reproducible non-production tests provide more useful support. None alone establishes that every surrounding control is correct.
Back to contents · Next section
3. Keep one concise randomness model in view
A source contributes uncertainty; a cryptographic generator processes inputs and state; an algorithm-specific procedure produces permitted key objects. These layers must fit together. NIST SP 800-90A Revision 1, SP 800-90B, and SP 800-90C address generator mechanisms, entropy sources, and constructions respectively.
The review does not estimate entropy from the apparent complexity of one key. A deterministic transformation of a small candidate set cannot create new independent uncertainty merely by printing a longer result. A documented cryptographic deterministic generator can nevertheless be suitable when correctly initialized, protected and used within its requirements.
The practical question is what supports the actual component’s assumptions in the actual environment. The museum should not replace an unanswered question with a homemade mixture of clocks, device names and hashes. Nor does citing a standard automatically certify the complete deployment.
Back to contents · Next section
4. Separate arithmetic tests from deployment evidence
A known-answer test can show that an implementation produces an expected result for specified test inputs. It does not show that production secrets are unpredictable. In fact, fixed test inputs are deliberately reproducible, which makes their accidental presence in production especially important to detect.
Statistical output tests answer other limited questions. NIST SP 800-22 explains why they cannot by themselves certify cryptographic suitability. A passing frequency chart does not show that a seed was never copied or that the deployment’s error path preserves its security requirements.
For the museum, the evidence pack therefore has separate categories: algorithm correctness, configuration, source and generator assumptions, lifecycle behavior, and protection against disclosure. A result in one category is not copied into the others as a general green tick.
The team also preserves negative test results and their interpretation. If a deliberate simulated API failure is silently ignored, that is an application failure-handling defect even when the cryptographic library passes all its own tests. Reviewing the boundary is part of reviewing the system.
Back to contents · Next section
5. Identify what changed between prototype and deployment
The prototype ran on a developer’s laptop. The exhibition devices use a different operating environment and a prepared image. That change deserves an explicit comparison instead of an assumption that identical application code means identical generation behavior.
Record the relevant implementation versions, supported interfaces, initialization requirements, deployment configuration and documented behavior around restore or duplication. Ask which properties are guaranteed by the platform and which the application must preserve. If the documentation is unclear, the uncertainty remains a review item; inventing a seeding workaround is not evidence that the gap has closed.
The review also distinguishes a reset that reuses an intentionally retained identity from a reset that is supposed to create a new identity. Both may be legitimate policies in different systems. The failure is an accidental mismatch between the intended identity lifecycle and what the device actually does.
A device that is intentionally restored with its old enrolled key is not independently generating a new key. A report should describe that operation honestly rather than count it as another successful fresh-generation trial.
Back to contents · Next section
6. Define acceptance and stopping conditions in advance
For this fictional project, the team approves enrollment only when the specified production generation path is identified, its prerequisites are met, the application handles failures visibly, and the image contains no unintended copied key or test-generation state. The team also checks that diagnostic paths do not disclose generated material.
These are process criteria, not a claim that a classroom review replaces professional security assurance. The team records who owns each unresolved question and which evidence would resolve it. “The demonstration is tomorrow” is a scheduling fact, not evidence of unpredictability.
An inconclusive test should remain inconclusive. If the team cannot determine whether a snapshot contains sensitive generator state, it should not label the snapshot clean because no duplicate happened to appear in a small sample. A lack of observed collision is not proof of independence.
The stopping rule is clear: do not enroll newly generated identities under an assurance claim that the available evidence does not support. Investigate the uncertain boundary through the platform’s documented mechanisms and qualified review, without collecting or publishing the real secrets.
Back to contents · Next section
7. Fictional project review: twenty display devices
A museum is preparing twenty display devices. Each will authenticate educational messages in a closed demonstration system. The team proposes installing one ready-made machine image on every device, including all application state captured during testing.
The reviewer asks whether that image contains a fixed test seed, pre-generated private keys, or initialized generator state that should not be duplicated. If every device starts from the same deterministic state and follows the same input sequence, it may reproduce the same outputs. Twenty boxes do not automatically create twenty independent secrets.
The team revises its plan: the production design must use the platform’s supported cryptographic key-generation facilities, establish the required initialization on each device, and document how restoration, cloning, or process duplication is handled by the relevant components. This is a requirement to verify, not an invitation to improvise fresh seeding code.
Next, the reviewer asks what happens if generation fails. A developer suggests falling back to a timestamp so the exhibition can open on time. That would silently replace the promised security property with a different process. The team rejects the fallback and defines a visible failure path that does not proceed with an inadequately generated secret.
The example shows why secure generation includes lifecycle events and error behavior. A diagram drawn only for a successful first launch misses the conditions where real deployments often become confusing.
Back to contents · Next section
8. Use key-generation APIs for their actual purpose
A low-level random-byte function and an algorithm-specific key-generation function have different jobs. The latter can enforce the key type, parameter requirements, and representation expected by its API. Random bytes are raw material, not automatically a valid key object for every algorithm.
The W3C Web Cryptography API Recommendation distinguishes random-value generation from operations such as generating cryptographic keys. Its discussion also warns that an API cannot solve all the security problems of the surrounding web application. A malicious or compromised application can misuse information even when a cryptographic primitive is correctly implemented.
For the museum project, the review asks which maintained platform interface is used, which algorithm and parameters are selected, and how errors are surfaced. It does not ask the team to paste real keys into a browser console or send them to a public “randomness checker.”
A secure-looking webpage is not evidence that its operator cannot observe inputs. Keeping secrets out of unnecessary diagnostic and support channels is part of the generation workflow, even though storage and custody receive fuller treatment later in the series.
Back to contents · Next section
9. Do not confuse private-key generation with every nonce
The word nonce appears in several cryptographic and blockchain contexts, but requirements depend on the protocol. Some values primarily need uniqueness; others have stronger unpredictability or secrecy requirements. A transaction sequence number is not interchangeable with a signing algorithm’s per-message secret value.
RFC 6979 describes deterministic generation for DSA and ECDSA signatures. This illustrates why “every signature must call a fresh external random source in exactly the same way” is too broad. It does not remove the need for secure initial private-key generation or justify reusing arbitrary fixed signing values.
The safe learning habit is to name the algorithm and the role of the value before stating its requirements. “We already have a random number” is not enough to show it is suitable for a different cryptographic purpose.
This section is a terminology boundary, not a signing implementation guide. Real code must follow the scheme and library’s specified behavior, including how it handles per-operation values and errors.
Back to contents · Next section
10. A review checklist without collecting secrets
You can review the design without asking anybody to reveal actual private material. Request descriptions and evidence about the process:
- Which platform and maintained implementation perform generation?
- Which algorithm, parameters, and valid-key rules apply?
- Where does the required uncertainty enter, and what assumptions support it?
- How are initialization, reseeding where applicable, and lifecycle events handled?
- What happens on an error or an unavailable prerequisite?
- Can test fixtures, snapshots, or cloning reproduce secret state unintentionally?
- Does any logging, analytics, crash reporting, or support workflow expose generated material?
- What does the testing evidence establish, and which risks remain outside it?
For the museum, these questions become acceptance criteria. A screenshot of a long key is not evidence of a sound process. A test passing on one laptop does not establish behavior on every deployed device. A claim of standards compliance needs a clearly identified scope and supporting evidence.
The review should be proportionate to the system’s consequences, but it should not replace unanswered questions with decorative terminology. If the team cannot identify the generator or explain its failure behavior, that is a concrete gap to resolve before trusting the result.
Back to contents · Next section
11. Practice: decide whether the evidence is sufficient
Case 1. The library passes its known-answer tests, but the production image still contains the fixed test-generation configuration.
Answer. Do not approve the production path. The tests support algorithm behavior for their inputs, not the suitability of fixed generation inputs in deployment.
Case 2. Twenty devices show different public identifiers. Nobody checked what was included in their cloned starting state.
Answer. The observation is useful but insufficient. Different identifiers in a small sample do not establish the source, state-handling or independence assumptions.
Case 3. A simulated generation failure causes the application to use a timestamp-derived replacement and continue enrollment.
Answer. The application has failed the stated error-handling requirement. It silently changed the generation process instead of surfacing an unmet prerequisite.
Case 4. A restored device deliberately retains its enrolled identity, exactly as documented by the lifecycle policy.
Answer. Describe it as restoration of the existing identity. It is not a fresh independent key-generation event, but reuse is not automatically a defect when it is the explicit intended policy.
Case 5. A support request asks staff to send a real seed to prove which generator was used.
Answer. Decline that evidence method. Review the documented process and non-secret diagnostics instead; transmitting the seed creates exposure without establishing the full generation history.
Case 6. All statistical checks pass, but the team cannot identify the deployed key-generation API or its failure behavior.
Answer. Those process questions remain unresolved. The statistical results do not answer them, so readiness has not been established under this lab’s criteria.
Back to contents · Next section
12. Frequently asked questions
Can I judge a key by how complicated it looks?
No. You need evidence about its generation and handling. A copied value can look just as complicated as an independently generated one.
Are deterministic generators always bad?
No. Cryptographic deterministic generators are a standard part of many designs. Their initialization, state handling, construction, and use limits matter.
Does hashing weak input add entropy?
A deterministic transformation does not create new independent uncertainty from nothing. It may change representation while leaving the underlying candidate set small.
Should I invent a key generator for learning?
You can study tiny labelled models that never protect anything. Production generation should use the target scheme’s maintained, appropriate implementation rather than a classroom invention.
Back to contents · Next section
Sources and next reading
Sources checked on 12 October 2026, Singapore time. SP 800-90A Revision 1 is dated June 2015, with a Revision 2 draft linked by NIST. SP 800-90B is dated January 2018 and has a May 2025 errata notice. SP 800-90C became final on 25 September 2025. SP 800-22’s April 2010 publication carries a 2022 revision decision. The W3C source is the dated 26 January 2017 Recommendation; RFC 6979 is dated August 2013 and is Informational.
- NIST SP 800-90A Revision 1: deterministic random-bit mechanisms.
- NIST SP 800-90B: entropy-source design and assessment.
- NIST SP 800-90C: random-bit generator constructions.
- NIST SP 800-22: statistical testing and its limitations.
- W3C Web Cryptography API: API responsibilities and security considerations.
- RFC 6979: a specific deterministic-signature construction.
The museum-device review and readiness cases are original educational examples. Return to key derivation to connect starting material with a key hierarchy. Continue to the comparison of encryption, hashing, and signing to decide which operation a task actually requires.