[Cryptography] Quillon Graph: A private, post-quantum electronic cash system
Viktor S. Kristensen
overdrevetfedmetodologi at pm.me
Tue Jan 13 04:11:12 EST 2026
Bear, Peter,
You're both making valid points, and the tension between your positions is exactly the right framing for this problem.
Bear is right about the pathology of premature standards.
The DES pattern—standardization → mandatory adoption → FUD-driven uptake → research ossification → decade of vulnerability—is real and documented. Bear's concern about NIST's lattice-only recommendation deserves serious weight. I share his suspicion: any guidance to deploy lattice algorithms by themselves is indeed a red flag. The algorithms haven't had sufficient cryptanalytic attention, and history suggests first-generation standards rarely survive contact with reality.
This is why Q-NarwhalKnight explicitly does not follow NIST's lattice-only recommendation. Our architecture is:
Security = Classical ∨ Post-Quantum
Signatures: Ed25519 AND Dilithium5 (both must be broken)
KEMs: X25519 AND Kyber1024 (both must be broken)
Symmetric: XChaCha20-Poly1305 (256-bit, already 128-bit PQ-secure)
If lattice cryptography turns out to be compromised—whether by mathematical breakthrough, implementation flaw, or deliberate sabotage—the classical layer remains. We treat NIST's selections as "best available hypothesis" rather than "truth," and the system is designed for algorithm replacement without chain reset.
Peter is also right about the counterfactual.
Without DES, we wouldn't have gotten 3DES or AES—we'd have gotten a thousand proprietary schemes, each with its own undiscovered vulnerabilities. The "snake oil displacement" function of standards is real. The question isn't "standards vs. no standards" but "when is a standard mature enough to be net positive?"
Bear's answer: "Not yet. We need a few hundred attempted solutions before we can discern criteria."
This is intellectually honest. But it faces a timing problem.
Hashpower as organic security growth:
There's another dimension to blockchain security that doesn't apply to ephemeral encryption: cumulative work. Q-NarwhalKnight tracks security as log₂(total network computational work). Every mined block increases this. The relationship is:
S(n) = log₂(Σ 2^dᵢ) for blocks i=1 to n
At 60-80 security bits, you reach "Bitcoin-grade" attack resistance. At 100+ bits, you're in quantum-ready territory. The point is: security isn't static. A network that starts weak becomes stronger through participation.
This creates a virtuous cycle: more miners → more cumulative work → higher security bits → more network value → more miners. The cryptographic primitive choices (SHA-3-256, Dilithium5) set the ceiling, but hashpower determines how quickly you approach it.
SHA-3-256 mining already provides 128-bit quantum security via Grover's bound. The post-quantum signatures protect against HNFL (harvest-now-forge-later) attacks on exposed public keys. The cumulative work model means the chain itself becomes exponentially harder to rewrite over time.
This isn't a replacement for sound cryptographic choices—it's a complement. The hash function and signature scheme define what "secure" means; the hashpower determines how expensive attacks become in practice.
The decision-theoretic framing:
The DES analogy has a crucial asymmetry. DES protected ephemeral communications—once the session ended, the ciphertext's value decayed. A 56-bit key that held for 5 years was "good enough" for most 1977 use cases.
HNDL inverts this. For immutable ledgers and archived communications, the secrecy horizon τ → ∞. The question isn't "will the standard hold for 5 years?" but "will it hold forever?" Shannon proved the answer is "no" for any computationally-secure scheme. We're negotiating how long "eventually broken" takes.
Under this framing:
- If we wait for Bear's "few hundred solutions" and CRQC arrives first → catastrophic, irreversible
- If we deploy hybrid now and lattice is broken → classical layer holds
- If we deploy hybrid now and classical is broken → lattice layer holds
- If we deploy hybrid now and both hold → no harm
The asymmetry favors preparation. This isn't certainty—it's decision theory under uncertainty, which Hellman articulated: "Waiting for proof is itself a choice, and often the wrong one when stakes are asymmetric."
On Bear's "only take-home lesson" (2x symmetric key length):
This is correct for symmetric crypto. Grover's algorithm gives a quadratic speedup, so AES-256 becomes AES-128-equivalent under quantum attack. That's manageable.
The problem is asymmetric crypto. Shor's algorithm doesn't halve security—it eliminates it. RSA-4096, ECDSA-P521, Ed25519—all become O(n³) polynomial time. There's no "just double the key" fix for factoring and discrete log. We need entirely different mathematical foundations.
Whether those foundations are lattices, codes, isogenies, or something yet undiscovered—I genuinely don't know. Bear is right that we're striking before the iron is warm. But the alternative is striking after the iron has already forged our chains.
The honest summary:
- Bear is right: premature standards are dangerous, and we don't know what good PQ crypto looks like
- Peter is right: standards prevent worse outcomes (snake oil proliferation)
- Neither proves what to do now
Q-NarwhalKnight's position: deploy hybrid classical+lattice, treat lattice as provisional, maintain crypto-agility for algorithm replacement, leverage hashpower accumulation for compound security growth, and accept that we're making a bet under uncertainty. Shannon proved we can't escape time forever; we can only maximize the horizon.
The harvest began years ago (LONGHAUL, UPSTREAM). The variance on decryption timelines is larger than we assumed (AI acceleration). Acting now isn't certainty—it's acknowledging we can't afford to be wrong.
Regards,
Viktor S. Kristensen
Really important if something matters
Afsendt med Proton Mail sikker e-mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - overdrevetfedmetodologi at pm.me - 0x5F4716BA.asc
Type: application/pgp-keys
Size: 1722 bytes
Desc: not available
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260113/416665ab/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260113/416665ab/attachment.sig>
More information about the cryptography
mailing list