Key Takeaways
- SILMARILS achieves “substantially smaller” keys and signatures than all three NIST-standardized post-quantum schemes — Dilithium, Falcon, and SPHINCS+ — while maintaining post-quantum security in a transferable designated-verifier (TDV) setting.
- The scheme operates in both two-party and three-party modes, with three-party mode delivering statistically secure signatures at error probability 1/p — where p is the prime defining the underlying finite field F_p.
- For security architects evaluating on-chain signature overhead or multi-party authentication workflows, SILMARILS represents a credible lightweight alternative — provided it clears peer review and standardization scrutiny currently absent from this preprint.
Last updated: June 2025
[IMAGE: A macro-level visualization of interlocking cryptographic lattice structures over a dark blockchain node network, with cyan light beams representing secret-sharing splits between two and three party nodes, cinematic deep-black background with teal accents, 8K quality, no text or human faces]
Why Your PQC Migration Plan May Already Have a Blind Spot
Your organization is mid-migration. You’ve audited your TLS certificate chain, you’re tracking NIST’s 2024 finalization of ML-DSA (Dilithium), ML-KEM, and SLH-DSA (SPHINCS+), and your security architects are mapping key sizes against storage and bandwidth budgets. So far, so standard.
Here’s the scenario that breaks the plan: a blockchain-based audit trail where every transaction carries a full Dilithium signature. At 2,420 bytes per signature for Dilithium’s Level 2 parameter set, a high-throughput chain accumulates gigabytes of signature data per day. Your on-chain storage costs scale linearly with every signed event. The compliance burden doesn’t shrink — it compounds.
Post-quantum cryptography (PQC) is the discipline of designing cryptographic systems that resist attacks from both classical and quantum computers, including Shor’s algorithm attacks on RSA and elliptic-curve schemes. The NIST PQC standardization process, finalized in August 2024, produced three signature standards — but none were designed with designated-verifier or information-theoretic security as primary objectives.
SILMARILS, introduced in a June 2025 arXiv preprint (arXiv:2605.03230), targets exactly this gap: a post-quantum signature scheme built from a minimal algebraic core that produces substantially smaller artifacts than the NIST standards, while adding a privacy property those standards don’t offer.
What SILMARILS Actually Does — and Why the TDV Property Matters
The Designated-Verifier Model Explained
A transferable designated-verifier (TDV) signature scheme changes the trust topology of a standard signature. In a conventional scheme, any party who receives a valid signature can verify it and prove to a third party that the signer produced it. In a TDV scheme, only a pre-designated verifier can initially verify the signature — and that verifier can simulate accepting transcripts that are computationally indistinguishable from real ones.
This is not a bug. It’s the design. The designated verifier cannot prove to external parties that a signature is genuine, because they could have fabricated an identical-looking transcript themselves. This property — Jakobsson-Sako-Impagliazzo DV security — is precisely what makes TDV signatures valuable in contexts where signer deniability or selective disclosure is a compliance or operational requirement.
When public verification becomes necessary, the designated verifier in SILMARILS may publish a receipt r. Even with r in hand, no external party can determine whether the underlying transcript was genuinely signed or simulated. The privacy guarantee survives the disclosure event.
The Algebraic Core: Minimal by Design
SILMARILS is built over F_p — a finite field defined by a prime p — using true randomness and perfect 2-out-of-2 Shamir secret sharing. “Perfect” here has a precise meaning: the secret sharing scheme leaks zero information about the secret to any single share holder. This is information-theoretic security, not computational security — it holds regardless of adversary compute power, including quantum adversaries.
The scheme supports two operational modes:
- Two-party mode: Realizes the TDV signature scheme with EUF-CMA^(¬DV) security — existential unforgeability under chosen-message attack for all parties who are not the designated verifier. This is proven in both the Random Oracle Model (ROM) and the Quantum Random Oracle Model (QROM), covering adversaries with quantum query access.
- Three-party mode: Adopts the broadcast model of Fitzi et al., extending it to quantum adversaries with classical I/O. Achieves statistically secure signature protocol with simulation-based security and error probability 1/p.
Critical finding: Standard EUF-CMA security cannot hold for the designated verifier — by construction, not by weakness. The designated verifier’s simulation capability is the feature. SILMARILS instead proves EUF-CMA^(¬DV) for all non-designated verifiers, preserving unforgeability where it operationally matters.
Technical Comparison: SILMARILS vs. NIST PQC Signature Standards
| Property | Dilithium (ML-DSA) | Falcon | SPHINCS+ (SLH-DSA) | SILMARILS |
|---|---|---|---|---|
| Security basis | Module lattice | NTRU lattice | Hash function | F_p + secret sharing |
| Designated-verifier support | No | No | No | Yes (TDV) |
| Information-theoretic security | No | No | No | Yes (partial) |
| QROM security proof | Yes | Yes | Yes | Yes |
| Key/signature size | Large (baseline) | Medium | Very large | Substantially smaller* |
| Three-party mode | No | No | No | Yes |
| Signer deniability | No | No | No | Yes |
| NIST standardized | Yes (2024) | Yes (2024) | Yes (2024) | No (preprint) |
| Peer-reviewed | Yes | Yes | Yes | Not yet |
*Exact byte counts not published in the preprint. “Substantially smaller” is the authors’ claim; independent verification pending.
What the Size Advantage Means Operationally
For a CISO evaluating blockchain-based audit logging, document notarization, or multi-party authorization workflows, signature size is not an academic metric. It determines:
- On-chain storage costs: Every byte in a smart contract transaction has a gas or storage cost. Smaller signatures reduce per-transaction overhead directly.
- Bandwidth budgets: High-frequency signing operations — IoT telemetry, financial transaction streams — multiply signature size by event volume.
- HSM and secure enclave constraints: Hardware security modules have strict memory limits. Smaller key material expands the range of compatible hardware.
The absence of exact byte counts in the preprint is a genuine gap. Security architects should treat the size advantage as directionally credible but not yet operationally plannable until the full paper publishes verified benchmarks.
Industry Context: Where SILMARILS Fits the PQC Regulatory Landscape
NIST Timelines and the Standardization Gap
NIST finalized its first three post-quantum signature standards in August 2024 — ML-DSA (Dilithium), ML-KEM for key encapsulation, and SLH-DSA (SPHINCS+). NIST’s guidance to federal agencies sets a migration deadline pressure: systems handling sensitive data should begin PQC transitions immediately, with legacy algorithm deprecation targeted for 2030 in many frameworks.
SILMARILS is not on this standardization track. It is a June 2025 preprint with no published peer review, no NIST submission, and no known implementation in production systems. Organizations operating under FIPS compliance mandates or federal procurement requirements cannot substitute SILMARILS for NIST-approved algorithms today.
What SILMARILS represents is a research signal: the NIST-standardized schemes were not designed to be the final word on post-quantum signatures. Specialized use cases — designated-verifier workflows, blockchain applications, multi-party computation — have distinct requirements that the general-purpose NIST standards don’t fully address.
Who Is Moving on Designated-Verifier PQC
The broader market for designated-verifier and privacy-preserving signature schemes is nascent but accelerating. Blockchain platforms handling regulated financial data face dual pressure: post-quantum migration mandates from regulators and on-chain efficiency requirements from operators. Traditional PQC standards impose storage overhead that conflicts with both.
The Fitzi et al. broadcast model — which SILMARILS extends to quantum adversaries — was originally developed for Byzantine agreement in distributed systems. SILMARILS’ extension of this framework to quantum adversaries with classical I/O is technically significant: it means the three-party security proof holds against adversaries who can make quantum queries to oracles but interact with the protocol classically. This covers the realistic near-term threat model where quantum computers exist but aren’t yet integrated into network stacks.
The extension of simulation-based security frameworks to quantum adversaries with classical I/O may establish new paradigms for provably secure multi-party signature protocols — potentially influencing cryptographic standards beyond the current NIST PQC selections.
The BeQuantum Perspective: Evaluating SILMARILS for Real Deployments
At BeQuantum, our Digital Notary infrastructure processes document authentication workflows where signature size directly affects throughput and storage architecture. When we evaluate emerging PQC schemes, we apply three filters before any production consideration: security proof completeness, implementation availability, and standardization trajectory.
SILMARILS clears the first filter partially. The QROM security proof for EUF-CMA^(¬DV) is a rigorous result, and the extension of Fitzi et al. to quantum adversaries is technically sound as presented. The information-theoretic foundation — Shamir secret sharing over F_p — is well-understood and auditable.
It does not yet clear the second or third filters. No reference implementation is published. No concrete security parameter sets (analogous to NIST security levels 1, 3, and 5) are specified. The prime p defining F_p is unspecified in the preprint, which means the error bound 1/p for three-party mode is currently unquantified.
For organizations using BeQuantum’s PQC Layer for certificate lifecycle management, the practical path is: monitor SILMARILS through peer review, flag it for evaluation if your use case involves designated-verifier workflows or blockchain signature storage, and maintain NIST-standardized algorithms as your compliance baseline. The two approaches are not mutually exclusive — a hybrid architecture can deploy NIST-approved algorithms for regulatory compliance while piloting SILMARILS in non-regulated internal workflows where size efficiency is the priority.
IceCase hardware deployments should note that any future SILMARILS integration would require validation of the F_p arithmetic implementation against side-channel attack vectors — a gap the preprint does not address.
What Your Security Team Should Do in the Next 90 Days
1. Audit your designated-verifier use cases now. Within 30 days, identify any workflows in your organization that currently use or could benefit from signer deniability — document notarization, selective audit disclosure, multi-party authorization chains. Map these against your current signature scheme inventory. If you’re using RSA or ECDSA for these workflows, you have both a quantum vulnerability and a missed privacy opportunity.
2. Benchmark your on-chain signature overhead. Within 60 days, if your organization operates or integrates with blockchain infrastructure, calculate your current per-day signature storage volume using your existing scheme. Model what that volume looks like under Dilithium (2,420-byte signatures at Level 2) versus a hypothetical substantially-smaller alternative. This gives you a quantified business case to present when SILMARILS or comparable schemes reach production readiness.
3. Track the SILMARILS peer review process. Within 90 days, assign a member of your cryptography team to monitor arXiv:2605.03230 for updated versions, peer review outcomes, and any reference implementation releases. Set a re-evaluation trigger: if a peer-reviewed version with concrete parameter sets publishes, escalate to formal security assessment. Do not deploy the current preprint in any production or compliance-sensitive context.
Frequently Asked Questions
Q: Can SILMARILS replace Dilithium or Falcon in our current PQC migration plan?
A: Not today, and not for compliance-sensitive deployments. SILMARILS is a June 2025 preprint with no peer review, no NIST standardization track, and no published reference implementation. Dilithium (ML-DSA) and Falcon are NIST-standardized as of August 2024 and are the correct choice for any deployment subject to federal, FIPS, or regulatory mandates. SILMARILS is worth tracking for designated-verifier and blockchain-specific use cases once it clears peer review and publishes concrete parameter sets.
Q: What does “information-theoretic security” mean for my threat model?
A: Computational security — which underpins Dilithium, Falcon, and SPHINCS+ — means an adversary with bounded compute power cannot break the scheme. Information-theoretic security means an adversary with unlimited compute power cannot break it, because the scheme leaks no mathematical information about the secret. SILMARILS achieves this for its secret-sharing layer via perfect 2-out-of-2 Shamir secret sharing over F_p. This is a stronger guarantee than computational security and holds unconditionally against quantum adversaries — but it applies specifically to the secret-sharing component, not the entire signature scheme.
Q: Why can’t the designated verifier in SILMARILS be held to standard EUF-CMA security?
A: Because the designated verifier can simulate accepting transcripts that are indistinguishable from real signatures — that’s the core TDV property. If the designated verifier could forge signatures, that’s not a vulnerability; it’s the designed behavior that enables signer deniability. SILMARILS instead proves EUF-CMA^(¬DV): existential unforgeability for every party who is not the designated verifier. The signer is protected against external forgery. The designated verifier’s simulation capability is scoped and intentional, not an attack surface.
