RANNTA PQ CloudOpen Console
Menu

ML-DSA-65 Verification Documentation

Private keys stay with you. Your backend keeps its existing classical authorization and final business decision. PQ Cloud verifies canonical payload evidence, the ML-DSA-65 signature, registered public key and HybridRequired policy, then returns Valid or Rejected.

Integration boundary

Customer
Private-key custody, signing, classical authorization and final allow/deny decision.
PQ Cloud
Canonical payload, ML-DSA-65, registered-key and policy verification.
Result
Valid or Rejected. Missing or failed verification must not be promoted to Valid.

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 and evidence to /v1/hybrid/verify.
  5. 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

  • Canonical payload — exact V1 byte construction and recorded one-byte mutation rejection.
  • ML-DSA-65 standards evidence — implementation identity, conformance tests and production HybridRequired results.
  • Independent verify — recorded customer-side @noble/post-quantum 0.7.1 verification and production cross-check.
  • Threat model — replay, mutation, key rotation, transport integrity and fail-closed evidence.
  • 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 verification benchmark.
  • Security report — downloadable production due-diligence summary.
  • Status — live reachability, release build ID and measured /v1/hybrid/verify latency.
  • Build ID — immutable Phase 2 release identifier.
  • Sandbox — prebuilt Rejected cases for integration testing.

Raw signature verification

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

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.