Post-Quantum Verification & Architecture Documentation

PQ Cloud cryptographically verifies ML-DSA-65 evidence. Your backend keeps its existing classical authorization and final business decision, and submits classical_verified=true as a customer assertion after that classical authorization succeeds. PQ Cloud requires that assertion under its HybridRequired service policy but does not independently cryptographically verify your classical signature or authorization event.

Two distinct security layers

PQ Cloud integration boundary

Core API flow

1. Store the project API key server-side.
2. Complete the existing classical authorization in your backend.
3. Build the canonical payload and sign its exact bytes with your customer-held ML-DSA-65 private key.
4. Submit the canonical payload, ML-DSA-65 evidence and your classical_verified assertion to /v1/hybrid/verify.
5. PQ Cloud cryptographically verifies the ML-DSA-65 evidence, key state and configured service policy.
6. Consume the explicit Valid / Rejected result in your own final business decision.

curl https://pq.rannta.com/v1/hybrid/verify \
  -H "x-api-key: $RANNTA_PQ_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "payload": {
      "domain": "example.com",
      "project_id": "prj_...",
      "subject": "withdrawals",
      "action": "authorize",
      "key_version": 1,
      "nonce": "unique-nonce"
    },
    "public_key_hex": "<registered-public-key-hex>",
    "key_version": 1,
    "ml_dsa_65_signature_hex": "<signature-hex>",
    "classical_verified": true
  }'

Trust and production package

• RANNTA post-quantum technical whitepaper - authorization and Mainnet validator-sensitive transport architecture.
• RANNTA X-Chain hybrid security evidence - RANNTA-published Mainnet authorization and transport acceptance record.
• Canonical payload - exact V1 byte construction and recorded one-byte mutation rejection.
• ML-DSA-65 implementation evidence - RANNTA-published implementation and production evidence with an explicit no-ACVP/CAVP/CMVP-certification notice.
• Customer-side cross-check - recorded customer-side @noble/post-quantum 0.7.1 verification and production cross-check. This is not a third-party audit.
• Threat model - hosted API and RANNTA Mainnet reference transport boundaries, replay, mutation, downgrade and session failure cases.
• Production SDKs - TypeScript and Go integration clients.
• Integration examples - exchange, treasury and validator authorization patterns.
• Operator self-test & production E2E - crypto/policy tests, fail-closed production cases and recorded verification benchmark.
• Security report - RANNTA-published production due-diligence summary, not an independent audit or certification.
• Status - live reachability plus dated release and latency snapshots where available.
• Build ID - a published build identifier, not by itself a signed provenance or immutability proof.
• Sandbox - prebuilt Rejected cases for integration testing.

Standards and certification wording

RANNTA uses the ML-DSA-65 algorithm specified by NIST FIPS 204. This standards reference does not mean that PQ Cloud is a NIST ACVP/CAVP-validated implementation or a CMVP/FIPS-validated cryptographic module. RANNTA does not claim those validations or certifications unless a specific external validation record is linked.

Raw signature verification

/v1/verify verifies supplied ML-DSA-65 public-key/signature evidence over the canonical payload. It is distinct from HybridRequired service-policy verification, which also checks the registered project key, policy state and the caller-provided classical-authorization assertion.

Key registration and rotation

Register only ML-DSA-65 public keys. PQ private keys remain in your own signer, service or HSM. Rotation evidence and rollback-negative tests are documented in the threat model.