Real World Crypto 2026

Last week, I had the pleasure of presenting at Real World Crypto 2026 in Taipei, Taiwan. It was a great RWC in a great place. In this postm I summarize my talk, experience, and takeaways. Plus, at the end, you will find photos of Taipei from my hike to 9-5 peak.

The talk#

I presented our work on security by obscurity in secure hardware (see the slides). Compared to cryptographic theory, which features open design, review, competitions, and sometimes even security proofs, the secure hardware space is very secretive. There is almost no documentation. Much interesting information is gated behind non-disclosure agreements, which dissuade the sort of open work we do as academics and security researchers. Finally, even getting access to newer samples is hard, as they are a controlled object.

The secure hardware space is thus a pretty hostile environment to be in and do research on. Yes, your findings may have a very large and very real-world impact, as these devices are widely deployed. However, you may not be able to fully confirm your findings (the vendor will neither confirm nor deny) or figure out the root cause. Finding the true impact of a vulnerability across the ecosystem is similarly impossible. Only luck and coincidence helped in the case of the ROCA vulnerability. In the case of Minerva we were able to find some likely impacted devices by using information present in Common Criteria security targets and certification reports (which was the start of the sec-certs project).

This secrecy in the space goes against a basic cryptographic practice, Kerckhoffs’ principle, of only requiring the secrecy of the key and not of the cryptosystem design. In the original words: “It should not require secrecy, and it should not be a problem if it falls into enemy hands;”. The goal of my talk was to point this out, start a discussion, and show that hiding behind obscurity is no basis for a secure hardware ecosystem (…Strange women lying in ponds distributing swords is no basis for a system of government…).

The conference#

RWC is always inspiring. Even though other conferences, like CHES, for example, may be topically closer to the kind of research I do, RWC talks are pretty much always great.

For some reason, I decided that I would try to summarize all of the conference talks I attended, though clearly “the conference” \( \ne \) “the sum of the talks”. The concentration of world-class cryptographers at the venue was through the roof.

  • A Practical Wrapper Protocol for Metadata-Hiding in Messaging: Presented a (seemingly) way better alternative to Signal’s Sealed Sender protocol. 🙏The speaker was unfortunate to be the first and thus had to endure more than a fair share of slide issues, which persisted throughout the event.
  • Advanced Browsing Protection for Facebook Messenger: Presented a PIR-based solution used by Facebook for warning users about malicious links they received in an E2EE chat thread. The set of requirements (efficient, private, not leaking the blocklist, domain and sub-path based filtering) leads to an interesting problem. Funnily enough, the solution (at least temporarily) utilizes TEEs, which another talk at the conference completely breaks. How spicy 🔥!
  • Improving the Trustworthiness of JavaScript on the Web: Presented a way of increasing the trustworthiness of JavaScript delivered by servers on the web. The main thesis was that threat models that have a malicious server (such as E2EE chat) do not make sense when applied to client-side JavaScript, as the malicious server is effectively in control of code executed on every client. There was also the argument that app stores do not have this problem, as they provide some level of verification of the app (scan for malware, log app versions, provide the same app to everyone). I find this argument rather weak, and to me, the two scenarios are quite similar. I believe if an app developer really wanted to backdoor their app (e.g., to steal long-term keys in E2EE chat), they would be able to do it on any of the major app stores. There is no way that app stores are capable of verifying the absence of back/bug-doors in apps. We really are just trusting Signal to not backdoor their app to leak our keys, change my mind .
  • Signal Lost (Integrity): The Signal App is More than the Sum of its Protocols: And on the topic of Signal, it turns out it was possible for a malicious Signal server to inject messages into conversations of the Android client for quite some time. Cryptography is hard. Deploying it is harder. It also seems like breaking Signal, getting their code/cryptography into Signal, or proving Signal correct is like the Holy Grail of cryptographers .
  • Martin Hellman and Whitfield Diffie received the Levchin prize this time. I could not believe they did not have it before.
  • David Basin, Cas Cremers, Jannik Dreier, Ralf Sasse received the second Levchin prize. Congrats! 🎉
  • Finding Bugs and Features Using Cryptographically-Informed Functional Testing: Looked at what you can do when you combine fuzzing and testing with properties of KEMs and other cryptographic primitives. Reminded me a bit of what ECTester and Cryptofuzz do.
  • Formosa Crypto: End-to-end formally verified crypto software: Presented the whole Formosa crypto stack, encompassing Jasmin, EasyCrypt, and all kinds of security (and correctness) proof you can do with them.
  • mlkem-native: a unified, fast and verified ML-KEM library: Presented an optimized ML-KEM library, already widely deployed.
  • Formally Verifying Circuits for Zero Knowledge Proofs: Presented an interesting problem of formal verification for (zero-knowledge) proof arithmetic circuits. In a sense, zero-knowledge proof systems face an even harder deployment challenge than other cryptosystems. In deploying cryptography, one usually needs to worry about correctness and security on three levels: the specification, the implementation (C/Rust, other high-level languages), and the execution (native/assembly code). However, in these proof system applications, these three levels are essentially present twice, once for the proof system itself and once for the circuits. There has been a lot of effort spent on verifying the old-school stack, not so much for the circuit stack.
  • Compositional Formal Verification of SNARKs with ArkLib: Presented a different view on verification of SNARKs in Lean.
  • Real-Time FHE Applications and the Era of Encrypted AI: The invited talk was mostly advertising for an FHE startup.
  • TEE.fail: Breaking Trusted Execution Environments via Memory Bus Interposition: Presented a real-world memory bus interposition attack on TEEs. This is the talk that I mentioned before that breaks TEEs. There was even a live demo of the key extraction against an Intel TDX quoting enclave. The attack produces an interesting oracle for the attacker, they are able to compare (deterministically encrypted) ciphertexts of 128-bit memory blocks on every read or write. There has been some research on mitigating leakage in this model; see, for example ZebraFix.
  • Migrating a Silicon Root of Trust to Post-Quantum Crypto: Presented a really nice story of adding ML-KEM and ML-DSA to OpenTitan. I love seeing open-source development at this level, including hardware. Go OpenTitan!
  • Chypnosis: Undervolting-based Static Side-channel Attacks: Presented a very cool side-channel attack using undervolting. I did not know of LLSI (laser login state imaging) before.
  • Kerckhoff’s Principle in Practice: Addressing Security by Obscurity in Secure Hardware: See above.
  • Encryption in the microarchitectural world: Presented a new microarchitectural weird machine architecture (that is a sequence of words I never imagined typing). I overheard one attendee asking: “What is this good for?” and another replying: “Ah, malware, I guess?”.
  • Real-World Steganography Against Content-Based Censorship in Modern Chat Applications: Sorry, didn’t attend.
  • Deploying Research: On Building and Shipping an Anonymous Whistleblowing System: Sorry, didn’t attend.
  • SecureDrop Next Generation: Lessons from a Decade of Deployment: Sorry, didn’t attend.
  • At-Compromise Security: The Case for Alert Blindness: Sorry, didn’t attend.
  • Defending the Open Internet: TLS, Passkeys, and the Privacy Stakes of Digital Identity: Very important talk on digital identity and its current challenges: “Can we do zero-knowledge proofs, and post-quantum, and certifications and hardware?” None of the current and proposed digital identity solutions has all of the properties one would want from them. Despite that, there is a strong push to deploy them now.
  • Zero Knowledge (About) Encryption: On the Security of Cloud-based Password Managers: Presented an analysis of several cloud-based password managers in the malicious server model. Turns out having user-friendly features like account recovery, partial-vault fetching, and sharing is non-trivial to do securely. Add in backwards compatibility, and you get a hodge-podge of protocols that is quite tricky to argue about and probably full of vulnerabilities.
  • Improving Account Security for Victims of Account Compromise through Client-Side Access Logging: Sorry, didn’t attend.
  • Keeping up with the KEMbiners: Sorry, didn’t attend.
  • Efficient Threshold ML-DSA: Sorry, didn’t attend.
  • XHMQV: Better Efficiency and Stronger Security for Signal’s Initial Handshake based on HMQV: Presented an interesting way to speed up Signal’s handshake. I did not expect there would be this kind of improvement.
  • A Call to Action: Transitioning Signal’s Private Group System to Quantum-Safe: Showcased the challenges of group management in E2EE group chats and how difficult it is to make it post-quantum secure.
  • End-to-End Encrypted Collaborative Documents: Interesting collaboration between cryptographers and journalists focusing on E2EE collaborative documents. I found the requirements arising from discussions with journalists to be very strong and limiting. Especially the deployment ones, which asked for “No new accounts; No new trust assumptions; No self-hosting”. Even in these tricky conditions, the authors were able to show that if you have E2EE group messaging, you can combine it with a reconciliation mechanism and get E2EE collaborative documents. The talk also presented interesting avenues of future work: Why is there no Signal-like (widely used, encrypted, private) solution for collaborative documents?
  • Random-Access AEAD for Fast Lightweight Online Encryption: Sorry, didn’t attend.
  • What is cryptography hiding from itself?: Focused on the ChatControl regulation and presented it in an eye-opening light. Forcing content-inspection on E2EE services introduces questionable client-side scanning of private communication, with false positives, potential for scope creep, and other terrible outcomes. Really insightful talk.
  • “Security vs. Interoperability’‘: Real Tension or False Dichotomy?: Examined the interesting case of antitrust regulation requiring interoperability and vendors pushing back using arguments based on security. The talk focused on three examples: WhatsApp being required to be interoperable with other Messengers, Apple being required to allow other payment providers and ways of installing apps, and finally NFC-based payments on mobile phones being available only to manufacturer-native apps.
  • CRA and Cryptography: The Story Thus Far: Presented a look into the huge system of standards arising from the EU’s Cyber Resilience Act. Unfortunately, these suffer from the usual issues: They are often created behind closed doors by people without appropriate experience, and they are not freely available. It is insane to me how these very important documents are drafted, discussed, and finally created. The EU has many of the world’s best cryptographers and security researchers; how is it that they are not intensely involved with the standardization effort? This plays out quite similarly to the EUDI/ARF situation, where leading cryptographers have to comment as outsiders, instead of being involved from the start. Also, why have we not abandoned the stupid systems of pay-to-read (inter)national standards?
  • When Proofs Aren’t Enough: Putting Cryptosystems in Context: Presented a framework for analyzing cryptosystems in their real-world context and reasoning about their socio-technical properties.
  • Building Cryptographic Intellectual Infrastructure Where It Means Most: Lessons from Teaching Applied Cryptography in Post-Crisis Lebanon: Nadim presented his experiences teaching applied cryptography in post-crisis Lebanon. It is amazing to see what he was able to teach the students in one semester. At the end of the talk he received a standing ovation from many in the conference room.
  • Counter Galois Onion (CGO): Fast Non-Malleable Onion Encryption for Tor: Presented a new onion encryption scheme for Tor that improves its security with respect to tagging attacks.
  • Let’s Aggregate? Towards making private telemetry as ubiquitous as TLS: Presented a framework for private telemetry aggregation called Heli. Interesting goal of becoming the “Let’s Encrypt” of telemetry.
  • How Private Can Private Advertising Really Be?: Presented a way of modelling advertising and privacy leaks inherent in it (through targeting, engagement, and metrics). Interesting work showing the challenges of making the system useful for advertisers and vendors, while keeping it private (and what that even means).
  • Sprinkle Differential Privacy on a Bit of Everything: Shows how differential privacy is a tricky notion and may not lead to true privacy in deployed systems.
  • Security of Bluetooth: A Cryptographic View on Analyzing a Leviathan: Shows how almost every Bluetooth protocol is broken in one way or another. Also, “Kamala Harris is Bluetooth-phobic” apparently. I appreciated the memes in this talk.
  • The Landscape of Offline Finding Protocols: Privacy, Safety, Problems: Discussed the tricky tensions between privacy, anti-theft, and safety in offline finding protocols (AirTag, Find My, Tile, etc.).
  • A bird’s-eye view of cryptographic practice: Presented a comprehensive study of geostationary satellite communications, finding scary things like unencrypted cellular communications, unencrypted military comms, unprotected in-flight Wi-Fi, and critical infrastructure comms. Huge props for the effort in decoding all of these protocols and analyzing the huge amount of traffic. A satellite link is not an internal/private network unless you use (strong) encryption to make it so.
  • (Dis)patches from the Web PKI: Fina, Static CT, MTC, and PLANTS: Sorry, didn’t attend.
  • Private Key Leaks in the Wild: Insights from Certificate Transparency: Sorry, didn’t attend.
  • Self-Auditable Key Transparency at Scale: Sorry, didn’t attend.
  • DTLS-SRTP: The Protocol Everyone is Using But Nobody is Checking: Interesting look at a protocol that has been overlooked in the past. There is certainly more to study and go deeper.
  • The widespread popularity of insecure proprietary network encryption in the Android ecosystem: Very cool work analyzing usage of encryption on Google Play and other app stores. As expected, there are a lot of incredibly poor encryption implementations. Some derive the key from the current time, some just include it in a static resource of the app itself (an image at that res/drawable/yw_1222.jpg). Many are not much better that ROT13 (though I was happy to not see it in the list).
  • Lessons Learned from Cryptography Shortcuts on the Example of TLS Session Tickets: Shown how fragile TLS session tickets are and how easy it is to get them wrong.

The place#

Taipei was very enjoyable. I really liked the reliable and comfortable (and cheap!) public transport. For how huge and complex many of its areas are (the main train station with its multitude of floors, tens of exits, and several malls), the navigation was mostly a breeze. As one of the conference chairs said, “We may not have the best food, we may not have the cheapest food, but we have the best cheap food ever.” I would certainly agree.

As I had a flight at night the day after the conference ended, I just had one day to spare. I decided to go for a hike to Thumb mountain and 9-5 peak. This was a fun hike, mostly on a very steep staircase. Though at some point, I decided to turn off the main path and go for a slightly more overgrown path (that also joined the main path at the ridge). That is when the real fun started.

At some point, I reached a section with a bit of a scramble with a few ropes for assistance and a (quite wobbly) ladder. I knew this was the last stretch before the ridge, which would be paved and easy, and so I ventured on.

thumb1
thumb1
thumb2
thumb2

The views were worth it.

taipei
taipei

Also, what is the beta? Side pulls, high step/smear, reach, and you are there.

taipei101
taipei101