{"slug": "privacy-in-the-post-quantum-era", "title": "Privacy in the Post-Quantum Era", "summary": "Governments and tech companies are racing to deploy post-quantum cryptography to protect data in transit from future quantum attacks, but experts warn that the real privacy crisis lies in data at rest. Fully homomorphic encryption is proposed as the solution to keep data encrypted even during processing, preventing breaches like the 2023 23andMe incident that exposed sensitive genetic data.", "body_md": "BLOG\n\n/JUN 29, 2026/# Privacy in the Post-Quantum Era\n\nPrivacy is the half of the post-quantum shift no one is fixing, and fully homomorphic encryption is the answer.\n\nKEYWORDS:\n\n+8\n\nAfter the AI wave, the horizon everyone is pointing at is quantum computers. Governments and large tech companies are pouring money in, and the working assumption is that a useful machine is a matter of when, not if. That is a problem for cryptography, because one specific kind of it breaks.\n\nThe kind that breaks is public-key cryptography. Shor's algorithm, published in 1994, comes in two flavors\n\n[[1]](#ref-1). One attacks factoring, which kills RSA. The other attacks discrete logarithms, which kills the entire Diffie-Hellman family, including elliptic-curve Diffie-Hellman (ECDH), along with the signature schemes built on the same problem like DSA and ECDSA. So both halves of a secure connection are exposed: the key exchange that sets up the session and the signatures that prove who is on the other end. It is not seconds and it is not magic, since it needs a cryptographically relevant quantum computer that does not exist yet. But the math is settled, so the day such a machine exists, those schemes are finished. Symmetric encryption like AES mostly survives, because the best known quantum attack only halves its strength, which you fix by doubling the key.The serious people saw this coming, and the migration to\n\n[#post-quantum-cryptography](/keywords/post-quantum-cryptography/)is already underway, on both fronts. Key exchange moves to ML-KEM and signatures move to ML-DSA. NIST finalized the first three post-quantum standards, FIPS 203, 204, and 205, on August 13, 2024[[2]](#ref-2). Cloudflare reports that more than 65% of human-generated traffic on its network is already protected with post-quantum encryption, and it is targeting 2029 for full post-quantum security across its products[[3]](#ref-3). The urgency is real even before any quantum computer exists, because of harvest-now-decrypt-later: an adversary records your encrypted traffic today and stores it, betting on a machine that can open it later[[3]](#ref-3). The data being copied in 2026 only has to stay valuable until the key shows up.So the wire is getting fixed. And here is the thing almost nobody is talking about: fixing the wire does not fix the problem.\n\nThe channel is not the problem\n\n[#post-quantum-cryptography](/keywords/post-quantum-cryptography/)secures two things: the confidentiality of the channel and the authenticity of the endpoints. Both matter. But a perfectly quantum-safe connection still ends the same way every connection does today. Your data arrives at a server and sits there in plaintext, where the operator can read it, query it, profile it, and eventually lose it. A post-quantum handshake does nothing about the breach at the other end of the wire.\n\nThat gap has a name we are bad at saying out loud:\n\n[#privacy](/keywords/privacy/)It is a little grim that in 2026, when people hear privacy they think of someone with something to hide. The instinct treats wanting privacy as a confession. But privacy is closer to eating and drinking, a baseline of being a person. You close the bathroom door without planning a crime. The pattern that actually hurts you is not a villain at the company. It is that your data has to be visible to something to be useful, and visible data leaks. Three examples on the same axis.\n\n**Location.** To get a weather forecast, an app wants your exact coordinates, refreshed constantly. Even if you trust the company, the service can link your requests over time into a movement profile that shows where you sleep and who you visit. You wanted a temperature. You handed over a map of your life.\n\n**Health.** Say you want a DNA test to check for a cancer-linked variant. Reasonable. What you do not want is to hand your genome to a database and trust it to stay put. In 2023, the genetics company 23andMe suffered a breach that exposed sensitive genetic and ancestry data tied to roughly 6.9 million people, and curated subsets of it were put up for sale on a hacking forum\n\n[[4]](#ref-4). Your genome is the one password you can never rotate.\n\n**Browsing.** Install a Safe Browsing style extension that warns you about malicious sites. To do its job it checks each site you visit against a provider, and the naive way to build that is to send every URL you load. That hands your entire browsing history to a third party as the price of a security feature. The protection itself becomes the leak.\n\nThe thread through all three: the service must see your data, or your question, in plaintext to answer it.\n\nPartial answers\n\nWe are not starting from zero here. Several techniques already chip away at this, and none of them need post-quantum cryptography at all.\n\n[#tokenization](/keywords/tokenization/)swaps a sensitive field, say a card number, for a meaningless token, and keeps the real value in a separate vault. Payment systems lean on it heavily. It is simple and it works, but it only protects the fields you tokenize, and the vault still holds the real thing.\n\nThe de-identification family takes another angle.\n\n[#k-anonymity](/keywords/k-anonymity/)makes each record indistinguishable from at least k-1 others, so you can talk about 2-anonymous or 5-anonymous data as a tunable level of exposure, and refinements like l-diversity and t-closeness patch its weak spots[[5]](#ref-5).[#differential-privacy](/keywords/differential-privacy/)goes further, adding calibrated noise so that any single person's presence in a dataset barely changes the output, with a knob that quantifies exactly how much leaks[[6]](#ref-6). These are excellent for publishing aggregates and statistics.Each of these solves a real slice of the problem and is good within its slice. But none of them lets a server compute on data it truly cannot read. The one I personally love, and the one I am convinced matters more as we go, is fully homomorphic encryption.\n\nComputing on data you cannot see\n\n[#fully-homomorphic-encryption](/keywords/fully-homomorphic-encryption/)(FHE) lets you run computations directly on ciphertext, so the result, once decrypted, is exactly what you would have gotten by computing on the plaintext, except the machine doing the work never saw the plaintext. Craig Gentry showed the first construction in 2009\n\n[[7]](#ref-7), and the schemes that followed are built on lattice problems, specifically\n\n[#ring-lwe](/keywords/ring-lwe/), the same family the post-quantum standards rely on. That is the quiet payoff: FHE is not a separate thing bolted onto the quantum story. It is lattice cryptography, so it is quantum-safe by construction, and it lives natively in the post-quantum world.\n\nThe property that makes this work is homomorphism. If is the encryption function, an FHE scheme gives you operations on ciphertext that mirror addition and multiplication on the plaintext:\n\nLoading math...\n\nAddition and multiplication are enough to build any circuit, so in principle you can evaluate any function on encrypted inputs and get\n\n`$\\text{Enc}(f(x))$`\n\nout, with the server never learning . The catch is that each ciphertext carries a small amount of noise, and every operation grows it, multiplication far more than addition. Let the noise pass a threshold and the result no longer decrypts. Gentry's breakthrough was bootstrapping, a way to refresh a noisy ciphertext back to a clean one by homomorphically evaluating the decryption circuit itself. In practice you avoid that cost by keeping the circuit shallow, so the number of chained multiplications, the multiplicative depth, is the quantity you design around.Loading diagram...\n\nThe everyday way to picture it is a jeweler's glovebox. A raw gem goes into a locked, sealed box. A worker reaches in through built-in gloves and shapes it, but the box never opens and the worker never holds the gem directly. The finished piece comes out, and only the person with the key ever touches it. FHE is that glovebox for computation. The server is the worker with the gloves, your data is the gem, and it stays sealed the whole time.\n\nOne of the cleanest things to do inside the glovebox is a lookup, which has its own name:\n\n[#private-information-retrieval](/keywords/private-information-retrieval/)(PIR). PIR lets you fetch the i-th record from a database without the server learning which record you fetched, a guarantee formalized by Chor, Goldreich, Kushilevitz, and Sudan in 1995[[8]](#ref-8). The early versions needed several non-colluding copies of the database; Kushilevitz and Ostrovsky later showed a single server is enough under computational assumptions[[9]](#ref-9), and FHE is what makes that single-server version buildable. PIR answers the location and browsing examples directly: ask for the forecast tile without revealing which tile, check the site reputation without revealing which site.OpaqueDB\n\nThis is the project I have been building on top of that idea: Opaquedb. In one line, it answers SQL queries over data without learning what you asked for.\n\nThe shape is simple from the outside. A client encrypts the value it is searching for under its own key. The server evaluates the match over encrypted data and returns an encrypted result that only the client can decrypt. The operator runs the query but never sees the query value or the secret key. Under the hood it is a computational PIR system built on Microsoft SEAL using the BFV scheme. The matching builds on a technique from a paper I co-authored on Intrusion detection over encrypted network data: matches are done as bit-sliced equality packed across SIMD slots, so the whole query travels as a single ciphertext and the cost stays close to one linear scan.\n\nA coordinator fans the encrypted query out to every shard, sums the encrypted partials they return, and hands one encrypted result back to the client, which is the only party that can decrypt it.\n\nLoading diagram...\n\nA table is plain SQL, with one searchable key and any number of searchable indexes:\n\nsql\n\n```\nCREATE TABLE weather (\n  id          INT  KEY,\n  city        TEXT INDEX,\n  country     TEXT INDEX,\n  temperature INT,\n  humidity    INT,\n  conditions  TEXT INDEX\n);\n```\n\nA private lookup looks like an ordinary query, except the operator never learns the value in the\n\n`WHERE`\n\n. You can match the key or any index, and a no-match comes back as an encrypted empty result, so the server cannot even tell whether you hit anything:text\n\n``` bash\n$ opaquedb query 'SELECT city, temperature FROM weather WHERE country = \"JP\"'\n city  | temperature\n-------+-------------\n Tokyo | 27\n```\n\nThe matcher also handles inequality, a set of values in one round trip, and an exact private count, all at the same cost and all hiding the value:\n\ntext\n\n``` bash\n$ opaquedb query 'SELECT temperature FROM weather WHERE city IN (\"Tokyo\", \"Cairo\", \"London\")'\n$ opaquedb query 'SELECT city FROM weather WHERE conditions <> \"Sunny\" LIMIT 3'\n$ opaquedb query 'SELECT COUNT(*) FROM weather WHERE conditions = \"Sunny\"'\n```\n\nTwo design choices are worth calling out. First, privacy rests on\n\n[#ring-lwe](/keywords/ring-lwe/), a lattice assumption with no known quantum attack, which is the whole reason it belongs in this post. Second, and this is the part I am most pleased with, it holds against a semi-honest operator with no non-collusion assumption between servers. Classic multi-server PIR assumes the database copies do not talk to each other, a hard thing to promise in the real world. In OpaqueDB the whole cluster is one trust domain, and sharding exists only to spread the linear scan across machines, not to spread trust.By default the operator still sees the stored data; only the query is hidden. That is a choice, not a wall. The hypothesis holds either way, and some people will want the data encrypted at rest too. Reaching that mode is a short step from where things already are. I just did not start there.\n\nWhat you can build on it\n\nThese map almost one to one onto the leaks above:\n\n- •\n**Private weather.** Index forecasts by the geohash of each cell, have the client compute its geohash locally, and query it privately. A shorter geohash prefix covers more area and reveals less, so the prefix length is a privacy knob. - •\n**Private messaging.** End-to-end encryption hides message bodies but not who fetches which conversation and when, and that social graph is often as sensitive as the content. Store messages under a per-conversation token only participants can derive, and fetch them with a private lookup so the operator cannot link two people. - •\n**Threat intelligence and reputation.** Looking up a file hash or a domain leaks intent: a company querying a specific ransomware sample hints it is under attack. A private lookup returns the verdict without revealing the indicator, which is also exactly how you build the Safe Browsing style extension from earlier without leaking the user's history.\n\nWhat this costs, and where it is going\n\nBe clear-eyed about performance. This will never feel like a normal database. Computing under encryption is fundamentally heavier than computing in the clear, and every query is a full linear scan over the data. Sharding spreads that scan across machines but does not reduce the total work. You are buying privacy with performance, and the bill is real, so this is for the cases where the question is genuinely more sensitive than the answer, not for your general-purpose store.\n\nThe honest status is early. I started this recently and it has a long way to go. The core works and the basic structure is in place, but the hard parts are still rough:\n\n- •It is not a full SQL engine yet. The encrypted matcher handles equality and its close relatives on one searchable column. Ranges,\n`LIKE`\n\n, and cross-column conditions are not evaluated under encryption yet. - •It hides what, not who. Authentication is still access control, so anonymity is a layer you add above the database, not something it gives you.\n\nThe near-term roadmap is to widen the encrypted operators past equality, ship the encrypted-at-rest mode, publish the full threat model so people can shoot holes in it, and put a proper client SDK over the wire contract. None of this is done, and it will get better with time. This series is where I will track that, rough edges and all.\n\nIf you keep one idea from this, keep this one. The post-quantum migration is busy locking the channel and proving who is on the other end. Worth doing. But the data still lands in plaintext on someone's server, and that is the half that decides whether the next internet is one where a stranger's database holds your genome, your location, and your history in the clear. Fully homomorphic encryption is the way out, and it happens to be quantum-safe already.\n\n# References\n\n[1]\"Algorithms for Quantum Computation: Discrete Logarithms and Factoring\". Shor, Peter W. In Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), 1994.\n\n[2]\"FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA): Post-Quantum Cryptography Standards\". National Institute of Standards and Technology. NIST, 2024.\n\n[3]\"Cloudflare Targets 2029 for Full Post-Quantum Security\". Cloudflare. 2026.\n\n[4]\"23andMe Data Leak\". Wikipedia. 2023. Breach disclosed October 2023; approximately 6.9 million users affected.\n\n[5]\"k-Anonymity: A Model for Protecting Privacy\". Sweeney, Latanya. In International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, vol. 10, pp. 557–570, 2002.\n\n[6]\"Calibrating Noise to Sensitivity in Private Data Analysis\". Dwork, Cynthia and McSherry, Frank and Nissim, Kobbi and Smith, Adam. In Theory of Cryptography Conference (TCC), 2006.\n\n[7]\"Fully Homomorphic Encryption Using Ideal Lattices\". Gentry, Craig. In Proceedings of the 41st Annual ACM Symposium on Theory of Computing (STOC), 2009.\n\n[8]\"Private Information Retrieval\". Chor, Benny and Goldreich, Oded and Kushilevitz, Eyal and Sudan, Madhu. In Proceedings of the 36th Annual Symposium on Foundations of Computer Science (FOCS), 1995.\n\n[9]\"Replication Is Not Needed: Single Database, Computationally-Private Information Retrieval\". Kushilevitz, Eyal and Ostrovsky, Rafail. In Proceedings of the 38th Annual Symposium on Foundations of Computer Science (FOCS), 1997.\n\n#### Related Nodes\n\nproject\n\n2026Opaquedb\n\nA post-quantum private database that runs SQL over encrypted data without learning what you asked for.\n\n+9\n\nresearch\n\n2020Intrusion detection over encrypted network data\n\nA protocol for privately evaluating detection models on system data using lattice-based cryptography to protect both data and model privacy.\n\n+8", "url": "https://wpnews.pro/news/privacy-in-the-post-quantum-era", "canonical_source": "https://halit.alptekin.im/posts/privacy-in-the-post-quantum-era", "published_at": "2026-06-29 00:00:00+00:00", "updated_at": "2026-06-29 20:53:49.686649+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy", "ai-research"], "entities": ["Cloudflare", "NIST", "23andMe", "RSA", "Diffie-Hellman", "ECDH", "DSA", "ECDSA"], "alternates": {"html": "https://wpnews.pro/news/privacy-in-the-post-quantum-era", "markdown": "https://wpnews.pro/news/privacy-in-the-post-quantum-era.md", "text": "https://wpnews.pro/news/privacy-in-the-post-quantum-era.txt", "jsonld": "https://wpnews.pro/news/privacy-in-the-post-quantum-era.jsonld"}}