Quantum-Safe Ingestion

Quantum-Safe Ingestion

Post-quantum protection for legacy mainframe data

Banking, insurance and public sector organisations hold decades of records in EBCDIC, packed decimals and COBOL layouts. RSA and elliptic curve encryption will not withstand a capable quantum computer. Quantum-Safe Ingestion reads that data read-only, seals each record at the point of entry, and proves each step in a signed audit chain. The source system does not change.

  • Read-only on the source system
  • FIPS 203 and FIPS 204 post-quantum standards
  • Offline by design
  • A person signs each high-impact action
The application in use, from the setup to the evidence package. Sample data, recorded at 6x speed.

One record

What happens to 13 bytes from a 1980s file

Select a stage. The record below is an illustration with sample values, and the bytes are correct EBCDIC and packed decimal.

C1 C3 C3 E3 F0 F0 F4 F1 F7 01 23 45 0C

The tool opens the file read-only. Nine bytes of EBCDIC text, then four bytes of packed decimal. A text editor shows these bytes as noise.

The process

Eight steps, each with a proof

  1. Read the source

    Read-only access to the legacy data. Nothing is written to the source system or installed on it.

  2. Read the copybook

    Deterministic rules turn the COBOL copybook into a layout. No AI model reads the file.

  3. Sign the layout

    An authorised person approves each layout with a reason and a passphrase before the reader uses it.

  4. Seal each record

    AES-256-GCM seals each record at the point of entry. A record that fails a rule is rejected, with its reason.

  5. Link each event

    An HMAC-SHA-512 audit chain links each event to the event before it.

  6. Sign the checkpoints

    ML-DSA-87 signs the head of the chain. ML-KEM-1024 establishes the keys.

  7. Deliver

    JSON Lines, CSV or Parquet, with a signed manifest and control totals. The tool authenticates each record before it writes it.

  8. Give the evidence

    One evidence package. A third party verifies it with one public key and without the tool.

The Overview screen with the audit chain after an ingest run
The Overview screen after a run, with the audit chain and the six stages of one record.

Cryptography

Standard algorithms, each for one job

The tool contains no algorithm of its own. Each one is a published standard, and the implementations are those of OpenSSL.

JobAlgorithmStandardKind
Seal each recordAES-256-GCMFIPS 197, SP 800-38DSymmetric
Link the audit chainHMAC-SHA-512FIPS 198-1, FIPS 180-4Symmetric
Establish the keysML-KEM-1024FIPS 203Asymmetric, post-quantum
Sign the checkpointsML-DSA-87FIPS 204Asymmetric, post-quantum

These four algorithms are in the CNSA 2.0 suite. The tool rotates the keys on request, and the chain records each rotation.

Agents

Code processes the data. The agents monitor and propose.

A prompt only asks a model to obey. So the limits of each agent are in code, and a person signs each decision.

Instructions are code

The rules, the limits and the prompt of each agent are in versioned source files, not in free text.

Signed identity

The identity of each agent covers its code and its prompt, and the owner signs it. A change to one of them makes the identity not valid until the owner signs again.

Enforced limits

A control frame checks the actions of each agent against its permitted scope. It refuses an action outside that scope and stops the agent. A reviewer must sign before the agent runs again.

Human approval

Each high-impact action needs an approval with a reason and a passphrase. The audit chain holds each approval.

No language model

Monitor agent

It applies 14 fixed rules to the session. The same input always gives the same alarms. In the control test, one changed bit in one record gives a critical alarm.

The only language model

Layout drafter

It drafts a layout from a copybook. It reads the copybook and never a record. Its draft has no effect until a person signs it.

The Agents screen with the register of agents and their signed identities
The Agents screen with the register and the state of each identity.

Responsible AI

The application states where it stops

AI governance
Each agent is in a register with its job, its connection, its owner and its state.
Identity
No agent runs without an identity that the owner signed.
Ethics
A review of 41 items checks the application. Each open finding shows the condition that closes it.
Accountability
Three roles hold the control: the data owner, the approver and the incident reviewer. The owner signs the review of roles and the procedure for harm.
Transparency
The Trust screen states what is implemented and lists the limits of the tool.
Accessibility
The screens pass a check against WCAG 2.1 AA criteria.
The Trust screen with the implemented controls and the open findings
The Trust screen.

Coverage

What the reader knows

40

Character sets

Single-byte and double-byte, for Europe, the Americas, the Middle East and East Asia.

COMP-3

Number formats

Packed, zoned, binary and floating point numbers, with each sign code of the standard.

OCCURS

Tables

Tables with a variable count, also inside other tables. REDEFINES with a selected view.

F V B S

Record formats

Fixed, variable, blocked and spanned records.

Operation

How it runs

Offline by design

The application opens no port and sends no request. The data stays on the computer that runs the tool.

No change to the source

The tool opens each file read-only. It installs nothing on the legacy system.

Verified build

A SHA-512 list covers each file of the application folder. One command checks the folder against the list.

Control tests

The operator can edit an audit entry, change one bit, delete a record or wipe the chain. The engine finds each change.

Empty at the start

The application has no built-in identity, profile or sample record. The first run starts with the setup of the three roles.

Desktop application

A Python engine with a desktop application for Windows.