Skip to content
PQC Shield
Open workspace

Security

Hybrid post-quantum, by default.

Every Seal and every Vault envelope uses a hybrid construction that combines a battle-tested classical primitive with a NIST-standardised post-quantum primitive. An attacker has to break both to recover the data — there is no single-algorithm lever to pull.

Seal — court-defensible signatures

  • · ECDSA P-256 + ML-DSA-65 (FIPS 204) embedded as PAdES. Both signatures cover the same byte range; verification requires both to match.
  • · RFC 3161 timestamp from a trusted TSA, embedded in the CMS structure alongside the signature. Replay protection comes from the TSA token + SigningTime; we never trust client clocks.
  • · We store the SHA-256 hash, the certificate of sealing, and the audit metadata. We do not retain the original PDF.

Vault — recipient-bound encryption

  • · Each recipient has their own X25519 + ML-KEM-768 (FIPS 203) key bundle. The platform combines both shared secrets via HKDF-SHA-256 and uses the result to wrap the per-envelope AES-256-GCM data-encryption key.
  • · Recipient secret keys are envelope-encrypted at rest behind a tenant-scoped hardware-backed key alias. Enterprise BYOK ties the alias to the customer’s own key-management infrastructure so we never see the unwrapping key in plaintext.
  • · The encrypted blob lives in object storage with envelope encryption enforced at the storage layer, public access fully blocked, versioning enabled, and configurable retention windows per plan.
  • · Recipient identity is proven at decrypt time via a one-time email link plus a 6-digit OTP delivered to the named address. The link alone cannot decrypt — the OTP defends against link-forwarding.

What we retain — and what we don't

  • · Hashes, not plaintext. Originals never persist. Sealed PDFs stream back to you and we drop them. Vault decrypts stream once to the recipient and we zero the plaintext bytes.
  • · Audit trail.We retain who sealed/vaulted what (by hash), when, and from which IP. For Vault, we record every successful decrypt — that’s the proof of delivery your audit case needs.
  • · API keys. Stored as SHA-256 hashes, never reversible. The plaintext is shown once, at creation.

Independent verification

  • · The public verifiervalidates a Seal against any tenant, anywhere, without an account. You don’t need PQC Shield to verify a PQC Shield seal — both classical and post-quantum signatures, plus the RFC 3161 timestamp, are checked end-to-end.
  • · Reader compatibility. Sealed PDFs open in any compliant PDF reader. Mainstream readers will validate the cryptographic chain and confirm the document hasn’t been modified; the signer identity is bound to the workflow audit trail rather than to a single reader’s built-in trust list. Recipients who want a reader-native trusted identity inside Adobe Reader can pin our root via Adobe’s “Add to Trusted Certificates” flow, and broader trust-store integrations are part of the program roadmap.

Reporting a vulnerability

    Email security@pqcshield.cloud with reproduction steps. Acknowledgement within 1 business day; we’ll work with you on disclosure timing. See SECURITY.md in the repo for the full policy.