Andreas Renz

AI can make you feel like you know more than you actually do. I have to watch for this every day. I use AI extensively to study cryptography, post-quantum cryptography, and other new subjects. It also helped me pass the CISSP this year. My setup combined a local dashboard with an AI tutor. I fed it screenshots of practice questions and mock exams. It tracked my study hours, progress, and coverage of each domain, with daily check-ins to keep me accountable. It used my weak areas to guide the next questions. It suggested chapters from the study guide, videos, and blog posts, then questioned me on that material. We worked through the domains step by step. That was powerful support. But the biggest danger was reading an explanation too shallowly and thinking, “Oh yeah, I understand that.” Following an explanation doesn’t necessarily mean you’ve absorbed it well enough to explain or apply it yourself. So I kept asking it to question me again on the core ideas it had just presented. Having to answer gave me a way to check what I had actually understood. That took discipline, and it still does in my daily learning. An AI tutor can organize your study, identify weak areas, and guide you through the material. You still have to do the learning. How do you check that something has actually stuck when you study with AI?

I’ve started exploring a new direction within my work on post-quantum cryptography: private digital identity. What draws me to it is a concrete question: how can we prove something about ourselves while revealing as little as possible? Proving that you meet an age requirement, for example, should not require sharing your full identity. Another question is whether separate uses of a credential can be linked. I want to understand how these privacy properties can be preserved as the underlying cryptography moves towards post-quantum alternatives. Which approaches look promising? What trade-offs emerge in proof size, performance, and integration into actual wallets and verification systems? That combination of cryptographic questions and practical implementation is what interests me. I’m currently building my foundation in digital identity and anonymous credentials, reading the literature and examining existing systems before narrowing down a research question. If you work on digital identity, privacy-preserving credentials, or post-quantum cryptography, I’d be glad to exchange ideas. Which papers, projects, or open problems would you suggest looking at? #PostQuantumCryptography #DigitalIdentity #PrivacyEnhancingTechnologies #AppliedCryptography

Had a lot of fun creating these. What started as a few cryptography ideas for shirts became an interesting exercise: which concepts can you compress into a few words without losing what makes them true? Some were obvious. Others took much more thought than expected. The Encryptorium shop is now live: shop.encryptorium.com/

I recently published a technical report on a question I have been increasingly interested in: What actually happens to deployed zero-knowledge proof systems in a post-quantum world? “Post-quantum ZK” is often treated as a binary property, but modern proof systems are layered constructions. A system may rely on quantum-vulnerable assumptions in its polynomial commitment, protocol logic, or non-interactive compilation, while other parts of the architecture remain unaffected. In Post-Quantum Risk in Deployed Zero-Knowledge Architectures: A Layered Analysis, I try to make that distinction more explicit. The report introduces a four-layer framework for locating quantum risk within ZK architectures and distinguishes between: - structural breaks - components that may be replaceable through migration - quantitative security degradation I also introduce the idea of “collect now, forge later”, the proof-system analog of harvest-now-decrypt-later, and apply the framework to systems including pairing-based SNARKs, Halo 2, Plonky2/3, STARKs, Binius, and lattice-based directions. The final part looks at real deployment considerations through Zcash Sapling, zkSync Era, and StarkNet. One of my main takeaways from working on this is that a deployed ZK system's post-quantum security isn't determined by the proof system alone. Architecture, governance, and the ability to migrate cryptographic components matter just as much. The full technical report, PDF, DOI, and source are available on Encryptorium: encryptorium.com/research/po… #Cryptography #PostQuantumCryptography #ZeroKnowledge #ZKP #Cybersecurity #PQC

Post-quantum migration discussions often begin with a question: Which post-quantum algorithm should we choose? I think that is one question too early. Before selecting ML-KEM, ML-DSA, SLH-DSA, or a hybrid construction, an organization first needs to know where cryptography actually lives: in protocols, libraries, certificates, HSMs, signing pipelines, firmware, third-party dependencies, and long-lived data. That is one of the clearest lessons I took from building the Book of PQC. All 41 chapters are now published. The book moves from mathematical foundations and from-scratch implementations through cryptanalysis, CBOMs, crypto agility, TLS and PKI migration, post-quantum zero-knowledge systems, and blockchains. The practical conclusion is simple: PQC migration is not only an algorithm problem. It is an inventory, dependency, and lifecycle problem. The entire book is freely available here: book.encryptorium.com/ For those already working on migration: what has proven hardest to inventory? #PostQuantumCryptography #Cryptography #Cybersecurity

I keep hearing the same problem in Web3 bug bounties, on @bountyhunt3rz and elsewhere: A whitehat finds a critical vulnerability, submits the exploit or full PoC, and only then discovers whether the project agrees that it is in scope, critical, unique and worth the advertised payout. Platforms such as @immunefi have introduced vaults, mediation, and arbitration, which certainly helps. But why must the researcher still reveal the valuable secret before the payment question is settled? Why not use a zero-knowledge proof of exploit? A researcher could prove that, against a committed contract version and authenticated chain state, they know private calldata that causes a specified harmful outcome, such as an unauthorized transfer, mint, ownership change, or invariant violation, without revealing the exploit itself. The project verifies the proof. A pre-funded bounty is locked or released. The exploit is delivered privately, ideally encrypted to the project and cryptographically tied to the same witness used in the proof. I initially wondered whether this already existed. It does. Green et al. described this exact workflow essentially in 2023: submit a ZK proof of exploit, verify it, place the reward in escrow, and only then disclose the exploit. CHEESECLOTH demonstrated ZK proofs for real-world vulnerabilities such as Heartbleed. The original @zkpoex won an ETHDenver @RiscZero bounty in 2023. @ziemannzk and @alessandrocav41 subsequently built a Solidity-focused zkpoex framework, now published at SAC 2026. Google even used a ZK proof in 2026 to substantiate a sensitive quantum cryptanalysis result without revealing the underlying attack path. So the cryptographic primitive is not the missing piece. The real problems appear to be: A proof only proves the chosen predicate. It does not automatically prove that a finding qualifies for a $1 million bounty. Scope, severity, duplicates, known issues, prerequisites, and payout rules remain semantic questions. Someone must define meaningful impact predicates. A badly specified predicate can produce a cryptographically valid but practically meaningless proof. Many real exploits are multi-transaction, multi-block, cross-chain, oracle-dependent, off-chain, or fundamentally economic. The zkVM, EVM implementation, guest program, state binding, and verifier all become part of the trusted computing base. @trailofbits’ recent work on Google’s disclosure is the perfect warning: the ZK proof verified, but bugs in the guest program allowed it to prove the wrong thing. Projects would have to opt in, pre-fund capital, and accept automatic consequences. Without pre-agreed bounty terms, “pay me before I tell you” can understandably feel more like extortion than coordinated disclosure. Even publicly proving that a live protocol is exploitable may attract attackers before a patch is ready. @MitchellAmador has already made perhaps the strongest counterargument: a ZK proof of exploit does not eliminate the trust problem. It can merely reverse the power imbalance while leaving difficult edge cases unresolved. That seems right if ZKPoEx is proposed as a replacement for triage and dispute resolution. But does it rule out a narrower hybrid model? For well-defined smart contract impacts: The project precommits accepted predicates, state-binding rules, and minimum payouts. The researcher privately submits a ZK proof plus an encrypted exploit tied to the same witness. Successful verification atomically releases a pre-funded minimum bounty. Human triage or arbitration handles severity top-ups and unusual cases. ZK would not replace Immunefi’s triage or arbitration. It would reduce the initial trust gap and provide cryptographic evidence that the researcher possessed a working exploit at the time of submission. Why isn't this already an optional submission route? Is the main blocker formalizing impact, technical complexity, project incentives, legal risk, or something bounty hunters themselves wouldn't want? Curious what @0xriptide, @zkoranges, @HackenProof and @sherlockdefi think. What am I missing?

“Don’t panic. Don’t rush. But you can’t ignore this stuff.” One point @danboneh made in conversation with @AnnaRRose on Episode 400 of @zeroknowledgefm really resonated with me: the post-quantum transition creates serious risks of its own. The danger is not only moving too slowly and remaining exposed to a future quantum adversary. If aggressive deadlines push us toward immature implementations, insufficiently tested migrations, or operational compromises, we could make systems vulnerable today to attackers who do not have a quantum computer at all. Boneh gives a striking example: moving signing keys out of HSMs because suitable post-quantum hardware support is not yet available. That may reduce a future quantum risk while increasing an immediate classical one. But this is not an argument for waiting. It is an argument for beginning early enough that we do not have to rush: inventory where cryptography is used, push vendors for support, test hybrid approaches, validate implementations, and migrate in controlled stages. Deadlines should create urgency across the ecosystem. They should not force operators to abandon security controls that already work. We need to start the post-quantum transition now, precisely so we have enough time to do it right. Start now. Move deliberately. Do not solve tomorrow’s quantum threat by creating today’s classical vulnerability.

Currently deep in another round of work on the Book of PQC. Revisiting chapters, tightening explanations, improving exercises, fixing things I thought were already finished. And I’m really enjoying it. There’s something satisfying about going deeper into the same subject instead of constantly chasing the next project.

How have I only just discovered @FoundersPodcast? I absolutely love this. The stories, the obsession, the ambition, the lessons from people who built extraordinary things. I genuinely want to work my way through the entire back catalog now. What an incredible podcast.

I've been working on a line of cryptography shirts, and I'm genuinely proud of how they're coming together. These are just six of them. For now, they're still designs on a screen, but the samples are on their way. I'm ridiculously excited to finally hold them, wear them, and see if they feel as good in real life as they do in my head. Turns out making cryptography you can actually wear is a lot of fun.

Cleartext is one dollar right now. It is a Kindle Countdown deal, so the price climbs back as the week runs out. I am proud of having published it, and I would like more people to read it. amazon.com/dp/B0H74MPVWX

Some mornings I wake up and feel two things at once: Grateful for how far I’ve come. Hungry because I know I’m nowhere near done. I think that tension is a good place to live.

I spent this morning building an argument, and the specification killed it. The claim I was going to make: hash-based signatures do not solve the long-lifetime problem for firmware. They trade a quantum problem for a state-management problem, and a device that runs for thirty years with no update path is the worst possible place to put a requirement that a key must never be used twice. Then I opened SP 800-208. NIST names that exact case as the intended application. Stateful hash-based signatures are "primarily intended" for implementations that need a signature scheme now, will have a long lifetime, and cannot practically transition later. The document says firmware updates for constrained devices. It says those devices will be in use for decades. I had put the state burden on the wrong side of the wire. The thirty-year device only verifies. It holds no state at all. Everything I was worried about lives in the signing infrastructure, which is a rack somewhere that the vendor controls. Second attempt. Fine, then the signer is the fragile part. Section 9.1 describes a crash between issuing a state update and that update reaching non-volatile memory, after the signature has already been exported. Restart, and the key can be used again. Section 8.1 killed that one too. A conforming module shall store the incremented leaf index in non-volatile storage before exporting a signature. The crash is not a residual hazard a careful operator has to survive. It is the thing the conformance requirement exists to prevent. What is actually hard is the part I would not have reached by reasoning about it. The module cannot export the private key, so there is no ordinary backup. NIST's own November 2024 presentation on revising the document lists the problem plainly: sign firmware updates for the whole system lifetime, recover from device failure, move between vendors over time, and thirty years is a long time because vendors can go out of business. If you run out of provisioned modules while the system is still in use, major problem. The failure mode I had missed was availability. You can lose the ability to sign for a fleet whose firmware-verification trust path cannot be changed. Two arguments died to a document I had already downloaded. Neither would have died to any amount of thinking about it.

Coinkite's backgrounder contains the whole incident in one sentence: review verified that the intended TRNG code was present in the firmware binary, but not which rng_get() the wallet seed-generation path actually reached. Presence was proved. Reachability was not. The preprocessor guard has the same shape, and the familiar explanation of it is true but incomplete. Coldcard defining MICROPY_HW_ENABLE_RNG as 0 was sufficient to suppress libngu's #error. It was not necessary. On MicroPython's standard STM32 path, random.c includes py/runtime.h before it tests the macro, and that chain reaches the port configuration, which pulls in the board header and then mpconfigboard_common.h, and that header defaults the macro to (0) for any board that has not set it. Remove Coldcard's line and the guard still does not fire. It was dead code on tat build path. That is not a universal claim. MP_CONFIGFILE can replace mpconfigport.h, so a configuration that omits the common header could still trip the #error. On the affected path it could not.