Building the Future-Proofing Forensics Pipeline with Dilithium

Digital forensics relies on a chain of custody (CoC) to protect evidence. If a defense attorney can show that a log file was edited after collection, the case can fall apart. For the past 30 years, we’ve used standard hashing (SHA-256) and symmetric/asymmetric encryption (RSA) to prove the integrity of evidence.

But time is running out. Traditional asymmetric encryption methods (like RSA and ECC) face obsolescence due to the rapid advancement of quantum computers. A sufficiently powerful quantum computer running Shor’s algorithm could theoretically forge digital signatures, breaking the CoC retroactively.

This paper outlines an approach to create a forward-looking architecture: a Quantum-Resistant Chain-of-Custody pipeline for high-speed environments such as Remote Monitoring and Management (RMM) and endpoint forensics.

Why “Good Enough” is Not Good Enough – Challenges

A standard forensic investigation follows a sequential path:

1. Collection: An agent collects a RAM dump or event log.
2. Hashing: We hash the collected evidence (e.g., SHA-256(evidence.log)).
3. Signing: The investigator signs the hash with their private key (RSA-2048).
4. Storage: The collected evidence is stored in an S3 bucket for 3 years.

Vulnerability: The problem lies in step 3. If an attacker records the encrypted signature today and uses a quantum computer to decrypt the investigator’s private key in five years, they could re-sign tampered evidence with the investigator’s key. The CoC would be broken.

To prevent this, we require two improvements:

• A blockchain to provide immutable timestamping
• Post-quantum cryptography to provide quantum-resistant signatures

Design – The “Ledger Layer”

Rather than relying on a single, potentially editable evidence locker (which admins can modify), we write forensic metadata to a tamper-proof ledger.

Components:

• Agent: Lightweight collector (Python/Go) deployed on the endpoint
• Merkle Tree: Batches many logs into a single hash to reduce blockchain load
• Algorithm: CRYSTALS-Dilithium (recently approved by NIST as ML-DSA), resilient to quantum attacks

Implementation – Building the PQC Pipeline

We can test this design using Python. We use a standard Merkle tree to batch logs and a PQC library to sign the root.

Step 1 – Batch Evidence Using Merkle Trees

We cannot send every single log entry to the blockchain — it is too slow and costly. A Merkle tree batches many logs and reduces blockchain load.

python

import hashlib

class MerkleTree:

def __init__(self, logs):

self.leaves = [self.hash_data(log) for log in logs]

self.root = self.build_tree(self.leaves)

def hash_data(self, data):

# SHA-256 is still quantum-safe for *hashing* (Grover’s algorithm only halves security)

return hashlib.sha256(data.encode('utf-8')).hexdigest()

def build_tree(self, nodes):

if len(nodes) == 1:

return nodes[0]

 

new_level = []

for i in range(0, len(nodes), 2):

left = nodes[i]

# Handle odd number of leaves by duplicating the last one

right = nodes[i+1] if (i+1) < len(nodes) else left

combined = self.hash_data(left + right)

new_level.append(combined)

 

return self.build_tree(new_level)

# Simulation

evidence_batch = [

"LogID:101 | User:Admin | Action:Login",

"LogID:102 | User:Admin | Action:Powershell_Execution",

"LogID:103 | User:System | Action:File_Delete"

]

tree = MerkleTree(evidence_batch)

print(f"Merkle Root to Sign: {tree.root}")

Step 2 – Sign the Merkle Root Using Post-Quantum Cryptography

Once we have the Merkle root, we sign it. Instead of RSA, we use a library supporting Dilithium.

(Note: For Production, Use liboqs or a FIPS-Validated Module. Below illustrates the conceptual logic.)

# Pseudo-code for PQC signing (Conceptual)

# In production, use wrappers like 'liboqs-python'

def sign_evidence_root(merkle_root, private_key_dilithium):

"""

Signs the Merkle Root using NIST-approved ML-DSA (Dilithium).

"""

# 1. Import PQC Library

# import oqs

# 2. Initialize Signer

# signer = oqs.Signature("Dilithium3")

# 3. Sign the Hash

# signature = signer.sign(merkle_root.encode())

# return signature

pass

Step 3 – Write to the Blockchain

Finally, the signature and Merkle root are written to either a private blockchain (Hyperledger Fabric) or a public blockchain (Ethereum) as a transaction.

Transaction payload: {Root: "a1b2…", Signature: "xyz…", Timestamp: 1715000000}

Integration into Enterprise RMM Workflows

For 20,000 endpoints (as I experienced in a major organization), this process must be invisible to the end-user.

1. Trigger: The EDR identifies a threat (e.g., a Yara match)
2. Snapshot: The RMM agent captures the required event logs
3. Local Hash: The agent hashes the data locally
4. Aggregation: The central server receives hashes from 500 agents, builds a Merkle tree, and writes the Merkle root to the blockchain every 10 minutes

Why This Matters for Security Professionals

You may ask, “Are you overdoing it?” Currently, yes. However, forensic data is typically stored for 5–7 years for legal purposes.

• Admissibility: Courts require proof that evidence has not been modified
• Internal Threats: If a malicious admin removes a log, the Merkle root on the blockchain no longer matches the database. Tampering is mathematically provable

Conclusion

We are entering a transition phase in cryptography. By combining Merkle trees for scaling and post-quantum algorithms for durability, security professionals can establish a chain of custody that remains intact through the next decade of computing advancements. We do not need to wait for quantum computers; we need to secure our evidence against them today.