PQS-BFL: Post-Quantum Secure Federated Learning for Healthcare
The 20-Second Summary
Federated learning systems usually authenticate model updates with classical signatures (RSA/ECDSA), which become forgeable under Shor’s algorithm once large-scale quantum computers arrive. PQS-BFL replaces that brittle authentication layer with ML-DSA-65 (Dilithium) and uses blockchain smart contracts to verify and record update authenticity, yielding a quantum-resistant audit trail with measured overhead on MNIST, SVHN, and HAR. (Published in IEEE Networking Letters 2025; journal version in Expert Systems with Applications 2026.)
The Threat Model
Healthcare data has a unique property: it must remain confidential (and trustworthy) for decades. Genetic profiles stay relevant for a lifetime, medical records can require protection for 50+ years, and some categories of records carry reputational harm long after collection.
That long horizon creates a realistic “store now, decrypt later” threat: an attacker can capture traffic and artifacts today and wait for quantum capability tomorrow. Just as importantly for federated learning, quantum attacks break the authentication layer: once signatures can be forged, a malicious party can inject model updates that look legitimate or retroactively falsify audit trails.
Why Existing Approaches Fail
| Approach | Problem |
|---|---|
| Classical FL (FedAvg) | Uses RSA/ECDSA for update authentication—broken by Shor’s algorithm |
| Encrypted gradients | AES survives (Grover halves key size), but signatures don’t |
| Trusted aggregators | Single point of failure; no long-term auditability |
| Private blockchains | Often rely on pre-quantum consensus mechanisms |
The core issue: federated learning’s authentication layer is quantum-vulnerable, both for model updates and blockchain consensus.
My Approach: PQS-BFL
PQS-BFL (Post-Quantum Secure Blockchain-based Federated Learning) replaces the cryptographic substrate:
1. Lattice-Based Signatures
We use ML-DSA-65 (Dilithium) for update authentication. Clients sign hashes of their model updates, and smart contracts verify those signatures before recording the corresponding update hashes.
Lattice problems (like Module-LWE) are believed resistant to both classical and quantum attacks.
2. Blockchain Verification
The blockchain layer stores update hashes and verifies signatures in smart contracts to create an immutable audit trail.
3. Practical Design Choices
Two design choices matter for feasibility: we hash updates before signing to keep on-chain payloads small, and we keep bulk update transfer off-chain (to the normal FL aggregator) while using the chain for verification and auditability.
What We Measured
Setup: Experiments on MNIST, SVHN, and HAR with multiple client counts; local blockchain simulation via Ganache.
We measured (i) ML-DSA-65 signing and verification time plus signature size, (ii) blockchain transaction latency and gas usage for recording/verifying update authenticity, and (iii) end-to-end FL utility (model accuracy) and timing (round time).
Results
In the reported evaluation, ML-DSA-65 is fast at the endpoint: signing averages ~0.65 ms and verification ~0.53 ms, with 3309-byte signatures. The heavier cost sits on the blockchain side: the reported gas per update averages ~1.72×10^6, while the cryptographic work (sign + verify) is typically <0.2% of the overall transaction time in their setup. Despite the added authentication and auditability, model utility remains competitive (e.g., >98.8% accuracy on MNIST).
The key trade-off: modest overhead today for decades of protection. For healthcare data, this is the right trade.
Limitations & What I’d Do Next
Current Limitations:
Gas costs for PQC verification are higher than ECDSA and can be expensive on public networks, and the blockchain performance numbers here come from a local Ganache environment rather than a production chain. Also, the evaluation focuses on ML-DSA-65; other PQC signatures (Falcon, SPHINCS+) change the size/latency/cost trade-offs.
Future Work:
Next, I’d validate on a public testnet or consortium/permissioned chain for realistic latency and cost, compare Falcon/SPHINCS+ against ML-DSA on the same pipeline, and integrate privacy mechanisms (e.g., secure aggregation or DP) where the application threat model requires more than authentication.