Blogs on Oscar Reparaz

Roughtime Server

Tue, 19 May 2026 00:00:00 +0000

May 2026.

a roughtime server. just set up a public roughtime server running on OVH cloud (located in Frankfurt). The server supports protocol version IETF-Roughtime (draft-11) and Google-Roughtime. I pre-paid it for 2+ years and deleted my ssh keys, so it’s destined to run unattended on autopilot until it dies. The VPS has 91 MB of RAM, with 46 MB currently free. And that’s a lot!

You’re welcome to try it out.

A big-key public key encryption scheme

Tue, 23 Dec 2025 01:00:00 +0100

Update: The core idea below already appears in Public-Key Encryption in the Bounded-Retrieval Model, by Joël Alwen, Yevgeniy Dodis, Moni Naor, Gil Segev, Shabsi Walfish, and Daniel Wichs, published in Advances in Cryptology – EUROCRYPT 2010, pp. 113–134 (ePrint preprint, 2009). They take the core idea here and do it properly; the security issue is pretty subtle.

In my version, stealing 1% of the identity keys lets an attacker decrypt about 1% of future messages. More subtly, an attacker could compute on the whole key collection and exfiltrate a short result: ordinary IBE security alone does not rule out a much smaller substitute that still decrypts messages. Erasing MSK does not settle that. Their construction combines several randomly selected key components and proves security against bounded leakage computed before the target ciphertext is known.

light: secure messaging

Sun, 21 Dec 2025 01:00:00 +0100

Here’s a secure messaging system that you can’t hack remotely. You can use this to talk to your friends in a way that even mercenary spyware can’t access your messages. This is guaranteed by hardware-level primitives. Let’s call it light.

Our threat model is remote-only attacks, with ability of performing zero-click remote-code execution (mercenary spyware).

The basic idea #

light is an endpoint architecture: three independent nodes connected by unidirectional links. On top of this endpoint architecture, we implement public-key cryptography to encrypt+authenticate messages between peers. The nuance here is how each “endpoint” is constructed.

What $10 of GPU time buys you in 2025

Sat, 01 Nov 2025 01:00:00 +0100

We are in 2025. Compute is cheap. With \$2 you can rent a beefy GPU by the minute and nerd out all evening. This entertainment is cheaper than going to the movies (and depending who you ask, more fun). Let’s see how many discrete logarithms we can break on a \$10 budget…

The problem #

We want to solve discrete logarithm problem in an interval. Our group is an elliptic curve over a 256-bit prime field. The interval size is about 70 bits. This is a problem that has interesting applications (for example, when key generation didn’t use full entropy), but let’s talk about that another time.

punchsig: cryptographic signatures, data diodes and trusted input

Sun, 25 May 2025 02:00:00 +0200

Look at this beauty. This box is a small USB dongle I built over the weekend with a bunch of junk electronics I had lying around. The dongle cryptographically signs short text inputs directly from your USB keyboard.

What is in this box? The dongle acts as an interposer: keyboard plugs into one side, computer into the other. It forwards keystrokes transparently, and can cryptographically sign text you type. To the computer, it just looks like a regular USB keyboard. Internally, the dongle has a “secure processor” which holds the signing keys and generates the ed25519 signature.

ANSSI x509 cert parser

Fri, 21 Mar 2025 01:00:00 +0100

This is a fantastic piece of software:

Arnaud Ebalard. x509-parser: a RTE-free X.509 parser. https://github.com/ANSSI-FR/x509-parser

This implements a X.509 parser, with profuse ACSL annotations so that the whole parser is verifiable with frama-c

This guarantees the parser is free from run-time errors: invalid memory accesses, signed integer overflows, undefined behavior)
It is suitable for embedded devices (no malloc, no floats, no dependencies)
The current ACSL annotations cannot prove the code adheres to some specification (correctness) but nevertheless it’s a great piece of engineering
It is a good resource to learn frama-c and ACSL in a non-trivial project.

This is an excerpt from the paper:

Mitigating deep fakes and phishing in meetings

Wed, 10 Apr 2024 02:00:00 +0200

Here comes a quick project idea. It’s meant to provide deep-fake + phishing resistance while at the same time not introduce “big bang changes” to how you operate. This allows you to retrofit a system like this into an existing legacy system.

The setting is this:

you run security sensitive meetings with a bunch of participants. say you run those using a laptop over (say) google meet / zoom / whatever.
you are remote/distributed
you are concerned about a participant getting pwned and getting replaced by a deep fake
you can’t change 100% how you operate. you are stuck with google meet / zoom / whatever

The problem:

Omron blood pressure monitor: reading the internal EEPROM

Thu, 28 Dec 2023 01:00:00 +0100

This note explains how to read the internal EEPROM of an Omron Upper Arm Blood Pressure Monitor 3 Series (model BP710N) to achieve interoperability. You’ll be able to read your blood pressure measurements with your own microcontroller.

Hardware #

This is the hardware we’re dealing with. It sells for about $40 on Amazon in the U.S. as of 2019. There are more expensive models from the same manufacturer that have Bluetooth connectivity. Here we are dealing with the simplest model: no Bluetooth, no WiFi, no USB.

A cryptographic desk clock: agreement protocols

Sat, 03 Sep 2022 02:00:00 +0200

Check out the different parts:

Part I: protocol for a cryptographic desk clock
Part II: time reference
Part II: agreement protocols (this page)
… sometime in the future … client implementation

Say you have 3 imperfect clock measurements. They do not tell the exact same time. Maybe they are drifting away, or to put things worse maybe one is totally broken. Here we look at this basic problem: given several clock measurements, how do you establish time? We’ll see three fundamental works in fault-tolerant agreement protocols.

A cryptographic desk clock: time reference

Fri, 05 Aug 2022 02:00:00 +0200

Check out the different parts:

Part I: protocol for a cryptographic desk clock
Part II: time reference (this page)
Part II: agreement protocols
… sometime in the future … client implementation

Here we will talk about the roughtime time server, and touch a bit on the architecture and security properties. The time reference itself (the time server) is this beauty mess of wires, currently living behind a couch. It has a small cryptographic processor, a GPS and a raspberry pi. This reference propagates the House Standard Time via WiFi.

A cryptographic desk clock: time transfer protocol

Mon, 01 Aug 2022 02:00:00 +0200

Check out the different parts:

Part I: protocol for a cryptographic desk clock (this page)
Part II: time reference
Part II: agreement protocols
… sometime in the future … client implementation

Slightly annoying fact: clocks are normally synced with a protocol (NTP - Network Time Protocol) that provides zero cryptographic guarantees. On the surface this is totally fine, but when we start composing security-sensitive protocols (think certificate expiration checks, audit logs or time-bound credentials), we need to turn a blind eye…

nonce-sanitizer: using authenticated encryption without fear

Thu, 28 Jul 2022 02:00:00 +0200

This post describes nonce-sanitizer: a very simple tool that prevents the major screw-up everyone is scared to make: 😱 repeated nonces under the same key 😱. In short, nonce-sanitizer provides seat belts as a thin wrapper around the AEAD code that adds a hard asserd that nonces don’t repeat.

But that’s such a n00b’s mistake! If you think “I’m a good programmer, I won’t ever make that mistake”, think harder. Even the crypto grandmasters make this mistake. It can happen to anyone anytime —even during an unrelated refactor. Do you have tests that would catch this bug? Do they run automatically every time you touch code?

Checklist to evaluate MPC deployments

Mon, 25 Jul 2022 02:00:00 +0200

This is a quick checklist I use when evaluating multi-party computation designs, deployments or ideas; both in industry and academia. I hope you find it useful. Two qualifiers:

While this was written mainly thinking about MPC, most of the following applies also to any fancy cryptographic technique.
Different scenarios call for different criteria. So do not take this checklist literally, but rather as an aid in your assessment process.

Assumptions #

Have you documented all implicit and explicit assumptions? Good results are just implications: if some hypothesis hold, then you can do some fancy stuff. This doesn’t necessarily mean the initial assumptions hold in your particular application. Examples of common assumptions that may not hold in your case:

Secure boot does not compose well

Tue, 01 Jan 2019 01:00:00 +0100

Composable security properties of a system are great: they allow you to define a security property locally on a subsystem and then this property will hold in whatever environment this subsystem is placed. This greatly simplifies the analysis, as you can deal with it chunk by chunk instead of having to tackle the whole system all at once.

Unfortunately, secure boot is not an easily composable property. This is a pretty straightforward result familiar to anyone that has spent an evening thinking about it. Let’s dive into it.

DPA on the third round of a Feistel

Mon, 19 Sep 2016 22:48:23 +0200

Straight DPA attacks target the outer rounds of a cipher: either the first one (if you know the input) or the last one (if you know the output). In a Feistel construction, you can easily DPA the second round. Things are messier if you want to target inner rounds.

Here we describe a simple, cute DPA attack on the third round output of a Feistel. There are much more advanced attacks that target fourth and even deeper rounds of a Feistel; this attack is on the other hand very simple (just assumes DPA works, no fancy leakage assumptions) and very fun. The full details are in our paper:

dude, is my code constant time?

Sat, 10 Sep 2016 22:48:23 +0200

Non-constant time crypto code is dangerous. Exactly 20 years ago Kocher presented the first timing attack on a cryptographic implementation. Since then, a long list of implementations have been broken by timing attacks.

Naturally, there are countermeasures in place, even in popular open source crypto libraries. However, those countermeasures are rarely publicly tested for effectiveness. Some timing countermeasures are just baked into the code, without a test harness that could provide some degree of confidence that the countermeasure is sound. In many cases, however, shit happens and things can go wrong (for example, your compiler may get in your way).

Compilers and constant-time code

Tue, 05 Jul 2016 22:48:23 +0200

Compilers normally do scary things to security-sensitive code. Consider for example the problem of wiping keys from memory once we’re done working with them. This is hard to do in C. The naive way to zeroize the key buffer is to call memset(). However, since the overwriting value is not used anymore, any performance optimization from the compiler will very likely remove the call to memset() intended to wipe keys; effectively working against our intention.¹