Post-quantum cryptography for ministries with secrets.
Quantum computers may soon break the mathematics behind every encrypted connection on the internet. State-level adversaries are already archiving traffic to decrypt it later. For ministries operating in hostile environments, the time to act is before the threat materializes.
The Egyptian government gave a Chinese quantum computing company a feed of encrypted traffic on Telecom Egypt. Joe had 24 hours to leave the country with his family.
A computer that changes the rules.
Classical cryptography rests on mathematical problems no computer can solve quickly.
It is 2035. Joe Bloggs is a missionary in Egypt. After crossing the street in Cairo traffic one afternoon, the police are waiting outside his school. In the station, they show him copies of receipts he sent to his sending agency: expenses related to his evangelistic activities, protected by what he was told was a secure file server. What Joe and his agency didn't know is that the Egyptian government had given a Chinese quantum computing company a feed of encrypted traffic on Telecom Egypt. He has 24 hours to leave the country. He finds out he wasn't the only one asked to leave.
How would this nightmare be possible? If we discover how to make a practical quantum computer, then almost all of the key algorithms we use to protect data today go away.
Cryptography is the study of techniques for keeping a secret in the presence of adversaries. It reduces to three key concepts: confidentiality (a message is only intelligible to authorized parties), integrity (a message cannot be modified without detection), and authentication (all parties are who they say they are). Today, most cryptography is done using a computer, because most cryptography is lots of simple math done repetitively.
Historically, cryptography and computers have been bedfellows. Alan Turing, who described the classical computer formally in 1936, was also the man responsible for breaking Nazi's Enigma code. Turing's classical computer stores zeros and ones, has finite precision, produces the same output from the same inputs, and uses the voltage in a transistor to represent its state. The computer you are using to read this article extends from Turing and von Neumann's ideas.
A contemporary of Turing, Richard Feynman, proposed something entirely different: a machine that stores zero, one, and a superposition of both at the same time, can have infinite precision, and corresponds to the spin of particles instead of voltage. It turns out that many problems that model nature and mathematics are far cleaner when you can represent them using a model of computing that looks like the problem itself. The issue, was that unlike Turing's machine, there was no clear way to physically build such a machine.
In 1994, Peter Shor, a scientist at Bell Labs, was wondering what he might be able to do if Feynman's machine existed in real life. He found something surprising. Such a machine could solve the two mathematical problems at the heart of classical cryptography: the prime factorization problem and the discrete logarithm problem. See that lock in the top-left of your browser? Shor proved that whoever got a sufficiently powerful quantum computer first would be the person who gets to make that lock mean nothing.
It took more than 70 years to figure out how to build each of these five tools well on a classical computer. A quantum computer running Shor's Algorithm breaks asymmetric encryption and key agreement.
Post-quantum cryptography for the next thirty years.
Issachar is an open-source post-quantum cryptographic library built for ministries, missionaries, and organizations whose secrets must remain confidential for decades. Every algorithm is fixed at NIST Level 5. No parameter is left to the caller.
Issachar · Those who had understanding of the times. 1 Chr. 12:33
The horizon is closer than it was.
Recent hardware breakthroughs have shifted expert consensus on when a cryptographically relevant quantum computer arrives from a distant theoretical concern to a plausible, near-term possibility.
For most of the 1990s and 2000s, the engineering gap between Shor's theoretical result and a machine capable of running it was enormous. Quantum systems are fragile: any interaction with their environment collapses the quantum state that makes the computation useful. Quantum error correction, detecting and correcting errors in a way that preserves the computation, dominated the field. For decades it remained an open question whether it was physically achievable at scale.
In December 2024, Google published results from its Willow processor that shifted that window. Willow demonstrated that quantum error rates decrease exponentially as the number of physical qubits grows: the precise scaling behavior that error correction theory predicted was necessary but that no hardware had ever produced. A benchmark computation that would require a classical supercomputer approximately 1025 years completed in under five minutes. Willow's 105 physical qubits are still far short of the millions required to run Shor's algorithm against 2048-bit RSA. But the hard problem, error correction scaling, now has an existence proof.
Years a classical supercomputer would need to complete a computation Willow finished in under five minutes. A demonstration of computational advantage, not yet cryptographic capability.
Approximate physical qubits needed per logical qubit under current error rates. Cracking 2048-bit RSA requires ~4,000 logical qubits — roughly four million physical qubits at today's ratios.
Median estimate for a cryptographically relevant quantum computer among researchers surveyed in 2025, down substantially from 20+ years in prior-decade surveys. The range runs from five years to never.
Microsoft announced in early 2025 that it had produced the first topological qubits, a physically distinct approach that, if stable, would require far fewer physical qubits per logical qubit than superconducting designs. The claim is contested; independent replication is ongoing. IBM, meanwhile, has continued scaling its superconducting roadmap toward fault-tolerant systems, with a public milestone schedule that extends through the end of the decade. Multiple well-resourced organizations with distinct physical architectures are now producing results that, in aggregate, suggest the engineering distance between theoretical capability and practical hardware is narrowing faster than most 2015-era projections anticipated.
The national security implications have not been missed. The United States National Security Agency issued its Commercial National Security Algorithm Suite 2.0 in 2022, a migration mandate for all National Security Systems, with hard deadlines beginning in 2025. The Cybersecurity and Infrastructure Security Agency has issued guidance that organizations should treat the migration as a multi-year project that must begin immediately. China's government has funded quantum computing research at scale for over a decade. Its specific hardware progress is not publicly verifiable, but it is not plausible that no progress has been made.
None of this means a cryptographically relevant quantum computer exists today or will exist next year. What it means is that the engineering obstacles that once made quantum computation seem like a distant theoretical concern have been resolving, one by one, on a faster schedule than was predicted. The population of scenarios in which classical cryptography fails within a 20-year window has grown materially since Shor published his result.
Harvest now, decrypt later.
The attack is already underway. The decryption is scheduled for a future that is closer than most organizations plan for.
State-level adversaries do not need a quantum computer today to compromise traffic that is encrypted today. They record ciphertext now and decrypt it later, once a capable quantum computer exists. This is not a hypothetical future attack. Intelligence agencies with long institutional memories and the resources to build archival programs have every incentive to do exactly this. Communications protected only by classical cryptography are at risk from the moment of transmission.
Traffic that appears low-stakes today can become a liability years from now. A personnel list, a funding transfer, a location record: Each is innocuous in isolation. Across a decade of archived communications, the picture that emerges is not.
Secrets must remain confidential across the span of time in which plausible quantum computation becomes available. The uncertainty in that range is not a reason to defer. It is the risk itself.
ML-KEM and ML-DSA became NIST standards in 2024 after approximately ten years of public scrutiny. RSA and elliptic-curve cryptography have accumulated decades of intensive analysis. The difference in track record matters.
Every algorithm in Issachar is fixed at NIST Level 5. No security-level parameter is exposed to callers. Misconfiguration by level selection is not possible.
A secret that must remain confidential for 30 years cannot be re-encrypted retroactively once the threat materializes. The decision to protect it must be made at the time of transmission. Long-lived secrets include identity keys, archived communications, and credentials for personnel whose work spans decades.
The populations most exposed are not abstract. Christian ministries operating in countries that actively persecute religious minorities face governments with sophisticated signals intelligence programs, well-funded quantum computing research, and the specific motivation to identify believers, disrupt networks, and intercept financial transfers. The people whose security depends on the cryptography are pastors, translators, and aid workers in places where identification carries serious personal risk. Classical cryptography, even well-implemented, does not address the quantum threat they face.
But Jesus did not entrust himself to them, because he knew men, and because he did not need anyone to testify concerning man, for he himself knew what was in man.
John 2:24–25 (OSV)The adversary does not need us to hand over our secrets willingly. Patience and infrastructure are enough.
The rest of the article is a technical dive into our cryptographic algorithm choices and their rationale. This is meant for technical audiences and applied cryptographers. Viewer discretion is advised.
Three KEMs, two signatures, one security level.
Each algorithm occupies a distinct role determined by its hardness assumption, key size, and speed profile.
Post-quantum algorithms carry more cryptanalytic uncertainty than classical ones. ML-KEM and ML-DSA were standardized in 2024 after approximately ten years of serious public scrutiny. RSA and elliptic-curve cryptography have accumulated decades of intensive analysis. The difference in track record matters: confidence in the concrete security of a post-quantum algorithm at given parameter sizes cannot yet match confidence in classical algorithms at equivalent nominal sizes. Cryptanalytic advances against lattice problems remain possible. The post-quantum landscape has not yet stabilized.
Issachar addresses this uncertainty in two ways: fixing every algorithm at Level 5 (the extra margin buys insurance against developments that are currently unknown), and pairing algorithms across independent hardness assumptions wherever possible.
NIST standard (FIPS 203). Module Learning With Errors. Fast key generation, encapsulation, and decapsulation. Correct for ephemeral session keys. Wrong as the sole static key given its short cryptanalytic history.
Plain unstructured LWE: no ring symmetry, no algebraic foothold. Slower key generation. Correct when a single maximally-conservative algorithm is preferable to one with more algebraic structure.
Code-based hardness: independent of any lattice problem, 50+ years of cryptanalytic pressure. ~1.3 MB public key, 208-byte ciphertext. The correct choice for long-lived static server identity keys.
Digital signatures follow the same two-assumption philosophy. ML-DSA-87 (FIPS 204) produces ~4.6 KB signatures and is the correct default for certificates, authentication tokens, and code signing. Its hardness rests on Module-LWE, the same family as ML-KEM. SPHINCS+-SHA2-256f reduces entirely to the security of SHA-256. It has no algebraic structure to attack. Its signatures are ~49 KB, acceptable for long-lived root CA certificates and firmware images, and worth the size when the application requires independence from lattice assumptions.
Deploying ML-KEM and ML-DSA together creates correlated failure: A break in Module-LWE compromises both simultaneously. Deploying ML-KEM with SPHINCS+ requires an adversary to break both Module-LWE and the preimage resistance of SHA-256. These are independent problems. The combination is strictly stronger than either pairing alone.
The hash layer uses cSHAKE256 and KMAC256. Grover's algorithm reduces the effective security of any hash function by half against quantum preimage attacks: A 256-bit hash yields approximately 128 bits of post-quantum preimage resistance, which falls short of the Level 5 target. cSHAKE256 produces 512-bit output by default, yielding approximately 256 bits of post-quantum preimage resistance. Every construction mode accepts a customization string that produces independent output spaces: A key pair can serve multiple protocols without cross-context confusion. Domain separation is structural, not optional.
Symmetric encryption provides two ciphers for different workloads. AEGIS-256X2 runs two AEGIS-256 instances in parallel, exploiting AES hardware instructions, and runs approximately 3 to 5 times faster than ChaCha20-Poly1305 for bulk data on supported hardware. ChaCha20-Poly1305 has no hardware dependency and runs in constant time in software. Use it for many small independent messages, or for targets without AES acceleration.
One sponge, one audit surface.
The handshake layer uses the Strobe framework. Its simplicity is the point.
Once keys are established, they have to be used. That requires a protocol: a structured exchange that authenticates both parties, mixes in all the shared secrets, and ensures that any tampering in transit causes the channel to fail to open rather than silently producing garbage. Issachar uses the Strobe duplex sponge framework, built on the same Keccak-f[1600] permutation that underlies SHA-3.
The reason to choose Strobe over a more conventional construction is auditability. In a standard protocol stack, transcript binding, key derivation, and message encryption are three separate operations composed together. Each composition point is a place where a subtle error produces a protocol that looks correct but is not. Strobe collapses all three into a single sponge state. There is one state machine, one sequential absorption of inputs, one place to audit. You read the handshake from top to bottom and see exactly what is absorbed and in what order.
Key mixing is equally straightforward. When a handshake involves both a classical Diffie-Hellman shared secret and a post-quantum KEM shared secret, absorbing them into the sponge state is a natural operation: Feed one in, feed the other in, derive output. There is no separate KDF invocation or concatenation scheme to get wrong. An adversary who compromises one input must still break the other, because the sponge output is indistinguishable from random as long as either input has sufficient entropy.
The server has a known static key. The client authenticates the server. The server does not authenticate the client.
Both parties have known static keys. Both authenticate each other before any data flows.
Each pattern has two variants. The hybrid variant pairs a Classic McEliece static key with an X25519 ephemeral key: An adversary must break both classical and post-quantum components to compromise the session. The PQC variant pairs Classic McEliece with an ML-KEM-1024 ephemeral key for applications that require a purely post-quantum channel with no classical component.
After the handshake completes, Issachar switches from the Strobe sponge to ChaCha20-Poly1305 for the data channel. The reason is nonce mechanics. ChaCha20-Poly1305 uses a 96-bit nonce. Ratcheting it forward is a single counter increment, which makes advancing the nonce after every message extremely cheap. Changing it to an arbitrary value is equally cheap: Each message can carry its nonce explicitly, so packets can arrive in any sequence and still decrypt correctly. This matters for applications running over UDP, where delivery order is not guaranteed. The sponge's sequential absorption model is not designed for that. ChaCha20-Poly1305 is.
A narrow library, a narrow claim.
Issachar addresses specific primitives at a specific security level for a specific threat model. It does not replace a full cryptographic stack.
When combining a classical and a post-quantum shared secret, concatenating them directly is incorrect. If either component is weak or malformed, concatenation exposes structural information about the other. A KDF over both secrets together produces output that is indistinguishable from random even under partial compromise of either input. Issachar documents this as a hard invariant and implements it throughout the transport layer.
All secret key types zero their memory before it is released. This limits the window in which key material is recoverable from cold-boot attacks, core dumps, and memory inspection tools. The library is built to run on targets with an allocator but without the full standard library. The one exception is a streaming hash API gated on the standard library, for large inputs.
The API exposes no security-level selection. Every algorithm is fixed at Level 5. A developer cannot accidentally select Level 3 because it is the default. Caller-configurable security levels introduce a class of error that is silent and consequential; removing that decision from the application layer entirely is the correct trade-off for a library whose users are application authors without dedicated cryptographic engineering expertise.
Issachar is the correct choice when the people whose safety depends on the encryption cannot afford for the cryptography to be wrong 30 years from now.
Applications that need general-purpose cryptography without a long-lived-secret threat model should use RustCrypto with Level 3 algorithms. Applications where throughput dominates should use Level 3 alternatives.
The library is open-source at github.com/cherithanalytics/issachar. We hope it serves as a blessing to Christian ministries working in hard places to protect their workers.