DCS Labs · Research

Six open problems, one discipline.

Each programme in the lab is an answer to a research question. We publish a verifier and test vectors under licence, share the specification under NDA, and label every result with the evidence behind it.

The six areas Our method
StandardsFIPS 203 · 204 · 205
FormatsRFC 8785 · RFC 6962
VerifiersOpen, offline
01 Areas

The questions we work on.

PQ · R-Series · post-quantum

Hybrid post-quantum signatures and migration

How do you move a live estate from classical to post-quantum keys without breaking the evidence it already produced?

  • Hybrid Ed25519 + ML-DSA-65 receipts where both legs must hold
  • Suite agility: adding ML-DSA-87 as an opt-in profile
  • Before-and-after migration evidence (R+13)

Go deeper →

AI · R-Series · AI agents

Verifiable AI agents

What is the smallest record that lets anyone check, later and offline, what an agent did and under which rule?

  • Intent, policy, result hash and signer in one receipt
  • Every hop between systems receipted (Connector OS)
  • Human gates for money and autonomy

Go deeper →

DL · Defence · COSRYX · ORBIT

Evidence under link loss

How does a machine keep proving what it did when it cannot reach anyone for minutes, or months?

  • Store, seal, forward: receipts made at the edge
  • Bounded autonomy inside signed limits
  • Clock-skew limits and deny-by-default verification

Go deeper →

LH · R-Series · R+15

Long-horizon evidence

Can a record stay verifiable for decades, after the algorithm that signed it is retired?

  • Key history: which key was valid, when (R+14)
  • Hash-based archive signatures and renewal receipts (R+15)
  • Verification that never depends on DCS existing

Go deeper →

OT · IoT / OT

Critical-infrastructure migration

How do you bring post-quantum trust to devices that cannot be changed and stay in service for twenty years?

  • A gateway that carries identity for devices
  • Hash-based firmware signing with state off the device
  • Migration evidence per device class

Go deeper →

AS · How we prove it

Assurance methods

How do you know a security claim is true when much of the code is written with AI?

  • Reviews by two different AI model families
  • Mutation testing: deliberate defects the tests must catch
  • Three verifiers in three languages that must agree

Go deeper →

02 Built on published standards

Nothing proprietary in the cryptography.

SIGNATURES

FIPS 204 · RFC 8032

ML-DSA for the post-quantum leg, Ed25519 for the classical leg. Hash-based signatures (FIPS 205, LMS / XMSS) for archives and firmware.

KEY EXCHANGE

FIPS 203

ML-KEM with X25519 for transport. The key exchange protects the link; it never appears inside a receipt.

FORMAT

RFC 8785 · RFC 6962

Canonical JSON bytes so every verifier signs and checks the same thing; transparency-log proofs for inclusion.

All the standards R-Series builds on

Want to collaborate on research? Architecture, live demonstrations and detailed status are shared in a private technical briefing, under NDA. Write to hello@dcslabs.ai.

Request a technical briefing