Post-Quantum Migration for Sealed Archives

How SALT-sealed accounting archives remain verifiable as cryptographic standards evolve. The plan for re-sealing without losing the original chain of attestation.

Why this plan exists

SHA-256 is currently considered cryptographically sound. The same was true of MD5 and SHA-1, both of which have since been deprecated as cryptographic primitives. Any system designed for long-term integrity must anticipate the eventual deprecation of its current algorithms.

SALT-sealed archives are designed to remain verifiable across decades. This document describes how that property is maintained as cryptographic standards evolve. The procedure is standard practice in long-lived digital archiving — it is not novel — but documenting it explicitly is part of audit-grade discipline.

The core principle: an archive's evidentiary value should not depend on the continued strength of any single algorithm. Re-sealing under newer algorithms preserves the original timestamp chain as historical evidence and adds a fresh attestation under contemporary cryptography.

When re-sealing is triggered

Sealed Ledger monitors recommendations from major standards bodies (NIST, IETF, ENISA) and adjusts the SALT cryptographic profile as their guidance evolves. The triggers for a re-sealing campaign are:

  • NIST formally deprecates the current hash algorithm. Historical example: NIST deprecated SHA-1 for digital signatures in 2013; full retirement followed years later, with sufficient time for affected systems to migrate.
  • A practical attack on the current algorithm is published. Even before formal deprecation, demonstrable collision or preimage attacks would prompt re-sealing.
  • NIST finalizes post-quantum hash standards. The NIST post-quantum cryptography standardization process is ongoing; once final standards are published and broadly implemented, SALT will offer them as the recommended algorithm.
  • A user explicitly requests re-sealing. Some users (e.g., those facing decades-long evidentiary horizons) may choose to re-seal proactively before any external trigger.

How re-sealing works

The principle

Re-sealing does not modify the existing archive. It produces a new layer of attestation over the existing archive, computed under a stronger algorithm and signed by a current TSA. The original seal remains intact and verifiable as long as its algorithm holds; the new seal provides a fresh attestation under the new algorithm.

The result is an archive with cumulative attestations: a chain of seals across cryptographic generations, each providing evidence that the archive existed in its current form before the next era's algorithms were used.

The procedure

  1. Verify the existing seal. Before re-sealing, confirm that the current seal still verifies under its original algorithm. A re-sealing campaign run on broken archives would produce no useful evidence.
  2. Compute a new hash under the new algorithm. The same database file is hashed under SHA-3, SHAKE-256, or whatever post-quantum hash has been standardized.
  3. Obtain a new TSA timestamp signing the new hash. The TSA service used for re-sealing must support the new algorithm.
  4. Append the new seal to the existing one. The new seal is recorded alongside the original in manifest.json, which is structured to accommodate multiple seals across generations. The original seal record is preserved verbatim, and the database itself is unchanged — re-sealing produces a new manifest, not a new database.
  5. Re-bundle and deliver to the user. A re-sealed bundle is delivered to the original archive's custodian; the custodian decides whether to retain the original-only bundle, the re-sealed bundle, or both.

What re-sealing preserves

A re-sealed archive carries a chain of attestations:

  • The original capture metadata (when, by whom, from which source) is unchanged
  • The per-row provenance hashes inside the database are unchanged
  • The original TSA seal is preserved as a historical record
  • A new TSA seal under contemporary cryptography is added

A reviewer evaluating a re-sealed archive can choose which generation of attestation to verify against. The original seal proves "this archive existed in this form before [original date]." The new seal proves "this archive exists in this form as of [new date], verified under [new algorithm]." Together they form an unbroken chain.

What if re-sealing isn't done in time?

If a hash algorithm is broken before an archive is re-sealed, the archive's seal under that algorithm becomes forgeable in principle. The archive's evidentiary value diminishes — though it does not necessarily reach zero.

What's still defensible

  • The archive may still be verifiable under different attestations: bank statements, third-party records, prior tax filings, or other evidence that was valid at the time.
  • The seal's metadata (timestamp, TSA identity, schema version) remains documentary evidence of when the archive was created, even if cryptographically forgeable.
  • If multiple parties (auditor, opposing counsel, regulator) hold copies of the archive obtained at different times before the algorithm broke, those copies serve as cross-validation.

What's lost

  • The cryptographic guarantee of integrity. After a break, the archive cannot be cryptographically distinguished from a forged archive of the same age.
  • The strongest legal positioning. A sealed archive under a broken algorithm becomes indistinguishable from circumstantial documentary evidence.

For this reason, archives expected to retain evidentiary value for decades should be re-sealed proactively, not reactively. Sealed Ledger will offer re-sealing services to past customers when triggers are met, but the user's custody of the archive is what makes re-sealing possible at all.

Sealed Ledger's commitments

Regarding cryptographic migration:

  • Monitor standards. Sealed Ledger tracks NIST, IETF, and similar bodies' guidance on cryptographic primitives. Material changes are reflected in the SALT specification and announced on this page.
  • Provide re-sealing as a service. When triggers are met, Sealed Ledger offers re-sealing for past customers' archives at fair pricing. The user delivers the archive; Sealed Ledger re-seals and returns it.
  • Open the verifier. The verification scripts bundled with each SALT archive are version-locked at delivery. Sealed Ledger maintains an open-source verifier that supports current and historical algorithms, ensuring archives produced under older algorithms remain verifiable indefinitely.
  • Document the chain. Each re-sealing campaign produces a public record describing the trigger, the new algorithm, and the migration window. Auditors evaluating a re-sealed archive can trace the cryptographic provenance.

What Sealed Ledger does not commit to:

  • Maintaining custody of past archives. Re-sealing requires the user to deliver the archive to Sealed Ledger; we cannot re-seal what we no longer hold.
  • Indefinite operation. If Sealed Ledger ceases operation, the open-source verifier remains available, and any TSA's published certificates remain usable for verification.

Current cryptographic profile

As of this document's revision date, SALT uses:

  • Hash algorithm: SHA-256 (FIPS 180-4)
  • Time-stamp protocol: RFC 3161
  • Default Time Stamp Authority: FreeTSA (https://freetsa.org)
  • Per-record canonicalization: JSON canonicalization with stable key ordering before hashing
  • Bundle signature scope: The complete snapshot.db file as a single unit
  • Encryption at delivery: AES-256-GCM via openssl (PBKDF2 key derivation, 600,000 iterations) or ChaCha20-Poly1305 via age. Symmetric, user-supplied passphrase, no escrow.

The next anticipated profile change is the addition of SHA-3 as a co-recorded hash, expected when commercial TSA support for SHA-3 is widely available. This would not deprecate SHA-256 but would add a parallel attestation under a different cryptographic family.

A formal post-quantum profile will be published once NIST finalizes its post-quantum hash recommendations and TSA infrastructure supports them.

This document is published as a draft and may be revised. Substantive cryptographic profile changes are versioned and dated.