[Cryptography] Quillon Graph: A private, post-quantum electronic cash system

[Viktor S. Kristensen]

Peter,

  Your demo is a nice touch: factoring a deliberately weak 1024-bit RSA key classically in microseconds neatly proves weak keys are weak. Point taken.

  But "quantum computers haven't broken real-world crypto yet" isn't the same as "quantum computers can't break real-world crypto." That line of reasoning proves too much — by that logic, we wouldn't have migrated from DES to AES until someone built a practical DES cracker and used it on live traffic. That isn't prudent engineering; it's retrospective. (The temporal security paper, Section 6.2, formalizes this as survival bias: "Organizations that weren't prepared don't get to tell their story.")

  On HNDL:

  The "Harvest Now" part is already happening — agencies collect encrypted traffic at scale (UPSTREAM, PRISM, Snowden 2013). "Decrypt Later" is the bet against time. Your position seems to be "the bet will never pay off." Mine is: for data that lives forever on an immutable ledger, I'd rather not take that bet.

  We agree on current quantum capabilities — they're toys. We disagree on whether the trajectory matters for systems meant to persist indefinitely. Section 4.1 of the paper quantifies this as τ_secrecy divergence: under QC maturation, E[τ_secrecy] < ∞ for classical crypto; E[τ_secrecy] → ∞ for PQ crypto until lattice algorithms fall. Bitcoin's 2009 transaction graph is still here, and it'll still be here if quantum computers mature (whether that's 2035, 2050, or never).

  Going hybrid costs about 3x signature size and 2x key-exchange overhead. If you're right and QC never arrives, we waste some bandwidth. If you're wrong and QC does arrive, systems that prepared survive. The asymmetry favors preparation — Section 7.3 frames this as Pascal's Wager for cryptographic infrastructure: bounded downside (bandwidth) vs. unbounded downside (retroactive compromise).

  Out of curiosity — for your factoring demo, did you use trial division or Fermat on a key with factors close to √n? Either way, it was amusing.

  Best regards,
  Viktor

  P.S. On a personal note, your "Guts" presentation series and "Cryptographic Security Architecture: Design and Verification" have been foundational reading for our team. Your decades-long commitment to pragmatic, real-world security engineering - particularly your work on analyzing implementation failures and the gap between theoretical security and deployed systems - has shaped how we approach threat modeling. We cite your certificate handling research in our temporal verification framework. Thank you for consistently elevating the discourse in this field.

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/20260108/e2351e4e/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/20260108/e2351e4e/attachment.sig>