Evaluate an entropy sample and its source evidence

Before you start.

Set up your workspace

Open /explorer/entropy and its request workspace, then inspect the catalog and source-key API references below. Public discovery needs no credential. Do not generate or store security-sensitive production entropy for this tutorial.

Examples are illustrative test plans, not customer results. Use only agreed access and non-production material.

Make the first read, then interpret it.

GET /api/v2/entropy

This public request needs no credential. It only reads existing information; it does not generate a sample or run an execution.

curl --fail-with-body --silent --show-error \
  'https://api.hybrid-chain.com/api/v2/entropy'

Read the response deliberately

• Read maximum_entropy_bytes and maximum_noise_bytes from the current response rather than copying a historical limit.
• Follow the published source-key operation and record the returned key identifier and retrieval time.
• A catalog response describes capabilities; it does not prove you are entitled to generate a protected sample.

Request paths, authentication modes and named response fields were checked against the published OpenAPI contract. Values are deliberately not filled with a fake live response. Follow the operation links for current schemas and errors.

The workflow at a glance.

Work through one useful case.

A team is assessing an external randomness source for a future application. It first wants to establish what was supplied, how the source evidence is checked, and what additional analysis remains before production use.

Keep one working record throughout

Create a private sample-review worksheet with requested class/size, catalog limits, verification-key identifier, observation time, source-envelope verification and application-analysis outcome. The first exercise is public discovery; sample generation is a separately authorized step.

1. 01

   Inspect the catalog before choosing a sample

   Read the supported physical sample classes, byte limits, assurance description, and discovery paths. Choose only a documented class and size. Record the intended use separately: a sample that can be requested is not automatically appropriate for key generation, simulation, or another security-sensitive purpose.

   Do this

   1. Run the public catalog request and inspect the limits and assurance description.
   2. Choose a supported non-production sample size and write the intended analysis question.
   3. Separate randomness/entropy and noise sample requirements rather than treating their byte limits as interchangeable.

   Expected result

   The worksheet contains current discovery values and a specific evaluation purpose.

   If your result is different

   If the catalog is unavailable, stop discovery and record the error. Do not use a cached limit as proof of current generation availability.

   Result: The evaluation has an explicit sample type, supported size, and application-specific acceptance question.

2. 02

   Establish the source verification context

   Read the gateway-pinned Ed25519 public JWK and follow the deployed verification format. Record the relevant key identifier and retrieval time. Do not trust a key supplied solely by an untrusted sample, and do not assume today's current key verifies every historical envelope.

   Do this

   1. Read the source-key route linked in the contract.
   2. Record its key identifier and retrieval time, and open the envelope-verification specification.
   3. For historical evidence, check the matching key/version procedure rather than assuming today's key verifies every sample.

   Expected result

   You can explain where the trusted verification context came from and whether it applies to the sample being reviewed.

   If your result is different

   A key embedded in an untrusted sample is not automatically trusted. Resolve discovery/version mismatches before reporting verification.

   Result: The reviewer can state which trusted verification context was used and which historical checks remain unresolved.

3. 03

   Request and inspect a protected test sample

   Only after authorization, construct the sample request from the current schema with its required signature and idempotency key. Keep credentials and sample material out of public logs. Verify the returned source envelope using the documented signed representation, not a reserialized or hand-edited version.

   Do this

   1. Only with agreed entropy:write and request-signing access, construct a small test request from the current sample schema.
   2. Inspect the returned envelope in Entropy Lab or the approved client and run the documented source-signature verification.
   3. Record pass/fail/unresolved privately; never publish sample bytes, bearer credentials or signing material in your report.

   Expected result

   The source-verification result is an actual observation, not a green badge inferred from an HTTP success.

   If your result is different

   If the signature fails, check exact signed bytes, key identity and envelope format. Do not rewrite or normalize the sample until it happens to verify.

   Result: The report records the actual verification outcome and the non-secret references needed to review it.

4. 04

   Evaluate the consuming application's requirements

   Run the agreed analysis and define behavior for an invalid proof, missing source, unsuitable sample, or unavailable service. Statistical results are observations about the tested data, not a universal security guarantee. Any later integration needs its own design review, conditioning strategy, and failure policy.

   Do this

   1. Run the agreed application analysis separately from signature verification.
   2. Write what happens when the source is unavailable, the proof is invalid or results are inconclusive.
   3. Keep any production fitness decision with the security owner and retain the limits of the test.

   Expected result

   The report separates source provenance, observed sample behavior and application-security acceptance.

   If your result is different

   A passing statistical test or valid signature alone cannot establish cryptographic fitness. Do not relabel the application quantum-safe on that basis.

   Result: The team has evidence to decide whether to continue, with provenance and application-security conclusions kept separate.

Test where the workflow stops.

A useful pilot explains failure as clearly as success. Record what you observed rather than presenting these expected checks as completed results.

Signed sample material is altered

The integrity check must not report the altered envelope as verified.

Verification key is missing or does not match

Record verification as unresolved or failed; never silently substitute an untrusted key.

Request exceeds a documented limit

Handle the actual validation result; do not silently truncate and claim an equivalent sample.

Source is unavailable or analysis is inconclusive

Follow the application's agreed stop/fallback policy and make the loss of assurance visible.

Your acceptance checklist.

Retain the environment, contract version, test time, redacted observations, unresolved dependencies, and responsible reviewer in your private evaluation report.

Keep the contract close.

These links point to documented operations, not executable controls. Check the current request schema, scopes, errors, and implementation status before using them. No credentials or live customer responses are embedded in this guide.

Read the published OpenAPI definition

Choose your next step.

Keep your worksheet and error notes. Continue with the next technical exercise using the same reference trail, and mark any stage that remains untested rather than treating the checklist as a completed deployment.

Need help with access or an unavailable integration? Contact the team with a redacted error and the guide step. Never send credentials or private records.