AndiR16

Cleartext is on Kindle Countdown until 10 August, US and UK stores. A brief book post, then back to cryptography. It is a techno-thriller about a machine that breaks RSA-4096. I am a cryptologist, so the bar I cared about was whether the technical details would survive someone checking them. I published a companion essay tracing seven of those details back to their sources; forty-six in all, every one checkable. If you would rather audit the work than buy on a recommendation, read that first. And if something in it is wrong, I would genuinely rather hear it than not. amazon.com/dp/B0H74MPVWX

The United States did not just discover post-quantum cryptography this week. The goal has been federal policy since National Security Memorandum 10 in 2022, with the stated aim of "mitigating as much of the quantum risk as is feasible by 2035." Congress added statutory weight with the Quantum Computing Cybersecurity Preparedness Act that December. OMB then told agencies to inventory their cryptography and name a migration lead in M-23-02, also in 2022. NIST finalized the first three PQC standards in August 2024: ML-KEM, ML-DSA, and SLH-DSA. The intent, the law, and the technical standards were already in place. What the June 22 executive order changes is the date. Federal HVAs and high-impact systems must move to PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. Covered contractors get a 2030 line through the coming FAR rule and NIST FIPS requirements. A NIST pilot is due by the end of 2027. The order also tells agencies to identify a PQC migration lead and review their inventories, which strongly echoes what M-23-02 asked in 2022. That suggests the earlier inventory work either did not fully take, or was not actionable enough to drive migration. The new move is to put a near-term deadline on work that was supposed to be underway already. One detail is worth sitting with. Key establishment gets the earlier deadline, signatures get an extra year. That ordering is a threat-model statement. Key establishment protects confidentiality, which is exactly what harvest-now-decrypt-later attacks: an adversary records encrypted traffic today and waits for a quantum computer to read it later. Signatures protect authenticity. They matter, especially for code, certificates, and long-lived trust chains, but they are not retroactively broken in the same way recorded confidential traffic is. The confidentiality clock is already running, so confidentiality goes first. What I am less sure about is whether a date fixes the hard part. The binding constraint on PQC migration was never only the math. NIST has settled enough of the standards question for migration to begin. The constraint is discovery. Most organizations do not know where their cryptography lives. It sits in protocols, certificates, firmware, vendored libraries, cloud services, appliances, and code nobody has opened in a decade. The 2022 inventories were meant to surface exactly this. A deadline can force real cryptographic agility, or it can force a one-time spreadsheet that is stale the day after it is filed. I would like to hear from people who have run a cryptographic inventory in a large environment. What was the part that did not fit on the spreadsheet?

Here are the resources that carried me through the CISSP. Not a complete list. Just what actually helped me. Your mileage will vary. 📚 Core study path The Official @ISC2 CISSP Study Guide This was the spine. Not exciting, but necessary. LearnZapp Daily questions, weak-area checks, and full trials. This did most of the reps for me. @destcert The book, the mindmap videos, and the mindmaps themselves. Probably the clearest map I found for seeing how the eight domains connect. @pzerger CISSP material Especially useful for high-yield review and final consolidation. 🧠 Final stretch / exam mindset “How to Think Like a Manager for the CISSP Exam” by @pzerger If one thing changed how I read questions, it was this. “How to Pass the CISSP Exam Like a Pro” by @destcert Very useful close to exam day for strategy, framing, and not fighting the exam. 🛠️ My own layer I ran the whole thing with Claude Code / @claudeai / @AnthropicAI. Not as autocomplete. As a mentor, administrator, track keeper, dashboard builder, flashcard engine, and accountability system. It helped me keep the boring parts visible: hours, weak domains, missed concepts, streaks, review loops, and what to study next. That mattered more than I expected. Again: this is not “the” CISSP path. It is just what worked for me. What did I miss? Which CISSP resource helped you the most? #CISSP #CyberSecurity #InfoSec #Certification #StudyTips

I passed the CISSP exam last week. I knew it would take work. What I did not fully expect was how much it would expose. The pass is nice, of course. But the thing I want to remember is the work behind it. 25 days straight at the end. Just over 60 hours logged in that final stretch. Most days around 4 hours, wrapped around work, family, and normal life. And a lot of that time was not simple review. It was gap closing. Some weak spots were expected. Some were not. A few things I thought I understood well did not survive hard practice questions, and I had to go back and relearn them properly. That part was humbling. The work itself was not glamorous. No perfect motivation. No clean schedule. Just the next block, then the next, then the next. A few weeks out, the diagnostics did not look like a pass. The distance from there to exam day closed one gap at a time. Even small habits mattered. What I take from the CISSP is not only the certificate. It gave me a wider map of the field. Risk, architecture, identity, operations, legal, governance, human factors. The pieces I work with every day, and the pieces I do not always give enough attention to. I have spent years going deep in narrow lanes. This forced me to go wide. And I am grateful for that. So yes, I passed. But the real win is that I found gaps, closed many of them, and now see the field a little differently than I did one month ago. Onward. @ISC2 #CISSP #ISC2 #CyberSecurity #InfoSec

1/8 Studying anything hard is the same loop: read it, work problems, notice what you missed, retry the misses tomorrow. After enough of it the question is not whether the loop works. It is whether the hour has to be spent re-reading what you already know.

If you are studying something difficult and not using AI as a learning companion, I think you are leaving a lot on the table. Not as a shortcut. As a way to ask better questions, test your understanding, build examples, generate exercises, review your notes, and turn confusion into a concrete next step. My Claude Code workflow for studying has become one of the most useful learning systems I have ever used. It does not replace the work. It makes the work sharper.

I feel like I currently live in two worlds at once. In my day job, I work in cybersecurity, and I keep AI on the edge of my workflow by choice. In my private life, research, writing, and side projects, I am deep in it. AI is part of how I think, build, explore, draft, test ideas, and move faster. And it splits me in two. On one side, I love what I am doing. AI enhances it. It helps me go deeper, connect dots faster, and turn vague ideas into something concrete. For research, writing, and learning, it often feels like having a second brain next to me. On the other side, it is strangely refreshing to keep some distance from it in my day job. There is value in doing the work yourself. There is value in being slower, more deliberate, more skeptical. Especially coming from cybersecurity and cryptography, I still deeply believe in being in the driver seat. But then the conflict comes back. I get bothered by tasks where I know AI could help. Repetitive writing. Summaries. Structuring thoughts. Drafting documentation. Searching through complexity. The kind of work where I can almost feel the wasted time because I know another mode of working exists. At the same time, not all AI output is satisfying. Speed is not the same as quality. Assistance is not the same as understanding. And using AI everywhere can slowly blur the line between amplification and dependence. That is the tension I am sitting with. I do not want to reject AI. I also do not want to outsource my judgment, my craft, or my responsibility. I want to use it well. Deliberately. With taste. With control. With security in mind. But I am still figuring out what that actually means in practice. Do you separate AI-heavy work from AI-light work? Do you feel the same conflict? Or have you already found a healthy way to integrate it without feeling like you are giving something up?

One thing I have learned from working in cybersecurity. Security works best when the right thing is the easy thing. If secure defaults require five extra approvals, three wiki pages, and someone remembering a policy from last year, people will work around them. But if the secure path is built into the workflow, documented clearly, automated where possible, and easier than the insecure shortcut, people usually take it. A lot of security is not about making people care harder. It is about designing systems where doing the right thing feels natural, and doing the wrong thing becomes inconvenient.

I need to get this off my chest: the way some people talk about post-quantum migration genuinely grinds my gears. Not because they are worried about quantum computers. They should be. Not because they ask about hybrid algorithms. That is a valid question. What grinds my gears is the confidence. People jump straight to "which algorithm should we roll out?" before they can answer the much more boring question: "where are we even using cryptography?" I keep seeing the same pattern. Hybrid this, PQC-ready that, apply it across the board, put it on the roadmap, add it to the slide deck. It all sounds serious until you ask where the crypto actually lives. Then suddenly the answer is somewhere between a config file, an old diagram, a vendor promise, and "someone probably knows." That is the bit that has been stuck in my head for weeks. "We can have a look at the config file." That is not a migration strategy. That is archaeology. And when you mention a cryptographic bill of materials, people treat it like paperwork. "We do not need that. We have the config." No. You have fragments. You have assumptions. You have whatever survived the last reorg, migration, outsourcing wave, and urgent production fix. The code you wrote is only part of the story. The uncomfortable part is the crypto buried in vendor libraries, firmware, appliances, SaaS dependencies, backup systems, old archives, and code-signing chains nobody has touched in years. And somehow, this is all supposed to be solved by "just slapping on PQC." That phrase drives me insane. Slap it on where? On the thing nobody has inventoried? In the system nobody owns end-to-end? Across dependencies nobody can fully explain? Post-quantum migration is not a paint job. It is not algorithm shopping. It is not a checkbox that says "PQC ready" because those words appeared in a vendor PDF. I am not anti-PQC. I am very much pro-PQC. Harvest now, decrypt later is real. The migration needs to happen. The timelines are not generous. But I am anti-pretending. If you cannot answer "where do we use what," you are not migrating. You are guessing in a more expensive font.

A week ago I wrote about PQC fear-selling. This week @solana published "Quantum Readiness." Same anti-pattern from opposite ends. Vendors substitute urgency for discovery. L1 announcements substitute reassurance for discovery. Both skip the same step: the actual threat model. The engineering signal in the Solana post is real. @anza_xyz and @jump_firedancer chose Falcon independently, and that is the kind of convergence you want to see when an L1 commits to a primitive. The framing around it is where it gets soft. Six specific places: the "ahead in preparation" claim against Ethereum, public-key exposure for dormant accounts, "quick" migration that skips the mechanism, Winternitz Vault scope, Falcon implementation hazards, and performance reassurance without migration-level numbers. Full piece, now live on @hackernoon: hackernoon.com/solanas-quant…

11/11 A week ago I wrote about PQC fear-selling. This is the inverse failure mode from the same root: fear-sellers substitute urgency; L1 announcements substitute reassurance. Full piece: encryptorium.medium.com/sola…

1/11 Solana (@solana / @SolanaFndn) published "Quantum Readiness" this week. @anza_xyz and @jump_firedancer chose Falcon independently. That is a credible engineering signal. The framing around the engineering is the part worth reading carefully.

Practitioner counter to PQC fear marketing. Three things to do this week, none of which require buying a migration platform first: 1. Pick one service you own end-to-end and do cryptographic discovery. A CBOM in CycloneDX 1.6 is the right artifact. A deliberately incomplete first pass is the correct starting point. 2. Write your organization's crypto-agility story in one page: which algorithms are hard-coded, which are negotiated, how long a swap takes today, and what the single worst dependency is. 3. Read NIST IR 8547, the latest CNSA 2.0 advisory, and the NCSC UK timelines side by side. Compare their dates to the dates on the last vendor slide you saw. If the vendor deck's dates are more aggressive than the public guidance and not tied to your own data lifetime, exposure, or regulatory context, that is not insight. That is the sales motion. Full piece, now live on @hackernoon: hackernoon.com/post-quantum-…

On April 9, a paper proposed quantum-safe Bitcoin spends with no soft fork. QSB is the escape hatch. It protects legacy coins already inside a QSB-locked output, not coins still in ECDSA wallets. Full breakdown: youtube.com/watch?v=HTycKVQX… #PostQuantumCryptography #Bitcoin

Google says breaking Bitcoin's ECDSA signatures takes 500,000 physical qubits. That is ~20x fewer than prior estimates. But the paper is not a timeline forecast. It is a cost estimate. Full breakdown, 16 min: youtube.com/watch?v=wj3Y0V_h… #PostQuantumCryptography #Bitcoin

STARKs are built on hash-based commitments and coding-theoretic machinery like FRI, which avoids the main Shor-vulnerable assumptions behind pairing- and discrete-log-based proof systems. But some implementations add a final SNARK wrapper for cheaper on-chain verification. RISC Zero’s docs describe compressing a STARK proof into a Groth16 proof, and explicitly mark that path as not quantum-safe. “We use STARKs” is not enough to make a system post-quantum. You have to trace the full verification pipeline.

Third @hackernoon article landed. 😊 This one is different: research notes from an unfinished paper, shared to invite criticism, counterexamples, and discussion. My working claim is that post-quantum ZK is not mainly a parameter problem. It is an architecture problem. The real question is which layer of the proving stack carries the quantum-vulnerable assumption, and whether that layer can actually be migrated in a deployed system. I walk through Groth16, Boojum, and STARKs, and ask what collapses, what degrades, and what may be modular enough to migrate. Hash-based does not automatically mean quantum-safe. Modularity may be the difference between migration and a full rewrite. hackernoon.com/post-quantum-…

Second @hackernoon piece is live. I broke down Avihu Levy’s QSB construction: quantum-safe Bitcoin spending using existing script rules, with no soft fork. The trick is grinding inputs until RIPEMD-160 yields a value that parses as a valid DER-encoded ECDSA signature, giving ~2^118 second-preimage resistance under Shor. The construction works. But it costs roughly $75–150 in off-chain GPU compute per transaction, does not help Taproot, and does not scale to full-network use. A last-resort escape hatch, not a fix. The clearest takeaway: The best in-script workaround still points to the need for protocol-level changes like BIP-360. hackernoon.com/qsb-could-sav…

My first @hackernoon article is live, and I won’t pretend I’m not grinning. I broke down Google Quantum AI’s new paper: fewer than 500,000 qubits to break Bitcoin’s secp256k1, a 20× cut from prior estimates. A resource estimate is not a timeline. Migration is the bottleneck. hackernoon.com/googles-quant…