Posts

Working on a pure-Rust ML-KEM implementation for Orion forced me to confront the peculiarities of what the FIPS-203 standard allows in terms of storing private decapsulation keys. According to the standard, you may store: The seed d||z, which is used to derive both the private decapsulation key and its public counterpart. The serialized form of the private decapsulation key, which includes the public key, a hash thereof, and the FO-transform secret z. As pointed out by Sophie Schmieg in the excellent paper “Unbindable Kemmy Schmidt: ML-KEM is neither MAL-BIND-K-CT nor MAL-BIND-K-PK” and in her blog post “Unbindable Kemmy Schmidt”, option 2 has several disadvantages when it comes to binding the shared secret k to the ciphertext (MAL-BIND-K-CT) and to the encapsulation key (MAL-BIND-K-PK). While both of these models require an attacker to have access to the private decapsulation key—at which point it’s arguably “game over” anyway—it still seems worthwhile to design an ML-KEM API that minimizes hidden assumptions and potential pitfalls. ...

While working on my master’s thesis, I investigated some recently proposed constructions that turn AEADs into key-committing or fully-committing ones. Key commitment has recently gotten a lot more attention and I, therefore, expect this post to be outdated quite soon, as new research emerges. This post serves as a quick collection of personal notes and pointers, that maybe could help someone looking to add key commitment to their AEAD schemes today. There exist constructions proposed in earlier work, but the ones covered herein are the ones I focused on primarily. ...

Public keys represent a point on the curve, given a pair of ($x$,$y$) coordinates. In uncompressed form, a public key when encoded as bytes ([1], sec 2.3.4) it would be with the identifier 0x04 prepended to both coordinates: pk := 0x04 || x || y. However, it’s not required to store the $y$-coordinate in order the use the public key. The compressed form of a public key leaves out $y$ and adds a sign instead, indicating whether $y$ was even or odd. ...

Link to Turtl’s announcement. Lately, I’ve spent some parts of my evenings poking at Turtl’s core library. Turtl is a note-taking application, focused on security and listed as one of three recommended alternatives, on privacytools.io, to Evernote, Google Keep, or Microsoft OneNote. I’ve collected the findings in a short audit report which can be found here: audit report link. The work was unpaid, focused primarily on crypto, and done mostly whenever I found the time for it, so it is in no way exhaustive of the entire library. ...

This is a follow-up post to “Rolling your own crypto gone wrong: A look at a .NET Branca implementation”. In short, it went over several critical issues of a NuGet that offers authentication token formats, specifically Branca. The NuGet has since fixed the issues in its 1.3.0 release. The issues are tracked under CVE-2020-36255. If you want to read the original issues on GitHub, describing the attack, you’ll have to find them on the Wayback Machine here, as they seem to have been deleted from the issue tracker after a CVE was assigned and before NVD finished analyzing it. ...

Introduction Some time back, I was looking at token authentication formats to authenticate some API calls. I didn’t even attempt to look at JWT & Co. for multiple reasons. I landed between PASETO and Branca. I chose Branca for its simplicity. I needed authenticated API calls with a shared symmetric key. Both Branca and PASETO implemented this using XChaCha20-Poly1305, but PASETO also supports asymmetric authentication, which I didn’t need. I was quite pleased by looking at how straight-forward Branca made it: ...

Introduction The following are observations from when I started testing my own pure-Rust crypto library, including its dependencies, for constant-time execution. Starting with a short introduction to dudect and how it can be used to test code for timing-based side-channel vulnerabilities. Then discussing the process of discovering a short-circuit that resulted in variable-time execution, in dalek-cryptography’s subtle library and how this seems to relate to Rust codegen option opt-level. DISCLAIMER: The tests and analysis presented in this post were not done by a professional - take everything with a grain of salt. ...

What is it? orion is another attempt at cryptography implemented in pure Rust. Its main focus is usability. This is in part achieved by providing thorough documentation of the library. High-level abstractions are also provided, which are an attempt at guiding users towards safe usage of the lower-level functionality of the library. Additionally, types used throughout the library, especially in the high-level interfaces, are designed to increase misuse-resistance. orion itself forbids the use of so-called “unsafe” code, meaning that all memory-safety guarantees provided by Rust are enforced at compile-time (see rust-lang docs). Using no unsafe code also has its drawbacks, such as if you need near-complete constant-time execution. This will in most cases require the use of assembly and therefore unsafe Rust code too. ...

About In the paper “Backdoored Hash Functions: Immunizing HMAC and HKDF” by Marc Fischlin, Christian Janson and Sogol Mazaheri (Ref 1), there are two proposed solutions. The first is to make HMAC resistant to a backdoored compression function of the hashing primitive, using a random cascade construction that replaces the compression function. The second is to make HKDF backdoor-resistant using random salts in the compression function of the hashing primitive. A method first introduced by Shai Halevi and Hugo Krawczyk (Ref 2). In this post, I will focus on the implementation of making HKDF backdoor-resistant and talk about some drawbacks I think will prevent it from being adopted into existing protocols. ...

Background I’ve been working on one project called orion, where I’ve implemented the HMAC algorithm. That project is written in Rust and depends on the std library, which means that I’m unable to run that code on embedded devices. After a couple of times where I had been reviewing my own code, I started to notice some patterns in the HMAC implementation that seemed to be repetitive. So I set out to implement HMAC again, without the repetitive patterns and something that could be run on embedded devices. This implementation is called rigel and is based on HMAC-SHA512, but the tweaks can be applied to HMAC with any SHA variant. ...