Big-key public key encryption. Here we design a public-key encryption system with “short” public keys (32 bytes) and very long private keys. The basic idea is to use an identity-based encryption scheme (like Boneh–Franklin) under the hood. The following explanation assumes you have a standard IBE with IBE.Setup(), IBE.Extract(), IBE.Encrypt() and IBE.Decrypt() operations.

Setup phase

1. Master Key Generation (Alice)
   • Alice runs IBE.Setup() → generates (MPK, MSK)
   • MPK becomes Alice’s public key (published/distributed to everyone)
   • MSK is kept temporarily for key extraction only
2. Identity Pre-Agreement (Alice & Bob)
   • They agree on a large set of identities, e.g.:
     • “alice-001”, “alice-002”, …, “alice-100000”
     • Could be: sequential, random strings, UUIDs, etc.
     • Each identity represents one decryption capability
   • Both parties store this list of valid identities
3. Big Private Key Generation (Alice)
   • For each agreed identity ID_i, Alice runs: SK_i = IBE.Extract(MSK, ID_i)
   • The “big private key” is the collection: BigSK = {SK_001, SK_002, ..., SK_100000}
   • CRITICAL: Alice then securely wipes MSK from memory/storage
   • MSK is never stored long-term, only used during setup

Encryption (Bob → Alice)

To send message M to Alice:

1. Bob picks an identity at random from the pre-agreed list
   • E.g., randomly select "alice-047851"

2. Bob encrypts using IBE: C = IBE.Encrypt(MPK, "alice-047851", M)

3. Bob sends to Alice: (C, "alice-047851")

   The identity must be included so Alice knows which key component to use

Decryption (Alice)

When Alice receives (C, ID):

1. Alice looks up the corresponding private key component from her big key
   • E.g., if ID = "alice-047851", retrieve SK_047851

2. Alice decrypts using IBE: M = IBE.Decrypt(SK_047851, C)

3. (Optional) Alice can delete SK_047851 after use for forward secrecy

Drawbacks

• It’s not “all or nothing”. An attacker that exfiltrates a portion of the private key gets a non-zero chance of decrypting ciphertexts to Alice (probability proportional to what they managed to exfiltrate).

Prototype implementation

Can be found here: https://github.com/oreparaz/bigkey-pke

Some notes:

• This implementation uses vuvuzela crypto (https://github.com/vuvuzela/crypto/blob/master/ibe/ibe.go) which uses Barreto-Naehrig curves. These are weaker than expected: see https://moderncrypto.org/mail-archive/curves/2016/000740.html
• We could use other libraries (maybe over BLS curves), like https://github.com/encryption4all/ibe/

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.

A conventional secure messenger does everything in one machine: parse untrusted network input, run crypto, handle keys, render + store plaintext, accept keyboard input.

light doesn’t do this. Instead, light carefully decomposes this monolithic networking + cryptographic stack into 3 different hardware-isolated nodes, connected via unidirectional links (data diodes).

System architecture

Each endpoint is partitioned into three discrete nodes:

• a TX computer (“the source”): takes plaintext you want to send, encrypts/authenticates it, outputs ciphertext and sends it to the GW. This computer isn’t connected to the internet. Even though it can send messages to GW, it cannot receive any bit of information from GW.

• a RX computer (“the sink”): receives messages from GW, decrypts and displays plaintext on a dedicated display. RX can only receive messages to GW, it cannot send any messages to GW.

• a GW computer (an untrusted “proxy”): this computer is connected to the internet and is connected to RX and from TX. Its task is to talk to other peers’ GWs and send/receive encrypted messages. This GW can use any transport layer: Signal messaging, XMPP, or other more sophisticated systems to provide better anonymity (tor, etc).

                              INTERNET
                                 │
                                 │ (bidirectional)
                                 │
                            ┌────▼────┐
                            │    GW   │ (untrusted proxy)
                            │         │
                            └─┬───────┘───────┬
                              │               ▲
                              │               │
                   encrypted  │               │ encrypted
                   (to RX)    │               │ (from TX)
                              ▼               │
                       ┌──────────┐   ┌──────────┐
                       │    RX    │   │    TX    │
                       │ (sink)   │   │ (source) │
                       └────┬─────┘   └─────▲────┘
                            │               │
                            │               │ plaintext
                            │               │ (input)
                            ▼               │
                      ┌──────────┐    ┌──────────┐
                      │  Screen  │    │ Keyboard │
                      │          │    │          │
                      └──────────┘    └──────────┘
                                            ▲
                                            │
                             ┌─────────────┐│
                             │    Human    ││
                             │  Operator   │┘
                             └─────────────┘

There’s an additional unidirectional link from TX to RX. This is used to send direct keystrokes and have a smooth UI.

Note that the set of 3 computers work together, and this is abstracted away to the user. The user experience is identical to that of a regular computer (one keyboard, one display).

System security properties

The trick is that the links are unidirectional. Observe that:

• TX never sees untrusted input. This means this computer will always execute the original code, and it’s impossible to remotely exploit it. Egress messages will always be encrypted to the intended recipient.

• RX does not have an egress path to the internet. This means that if this computer gets compromised, it’s impossible to exfiltrate keys or plaintext from this computer. The only “output” from this computer is a screen.

An attack: human-in-the-loop social engineering

Note that there is an exfiltration path to the internet: via the human operating the node. A compromised RX node can’t send bits to the GW, but it can send bits to the user’s brain (by lying on the screen). For example, a compromised RX could display “Sync error. Please type the following ‘session recovery code’ into your TX terminal to reconnect: [hex-encoded private key]”.

There are two ways to mitigate this:

1. Prevent that from happening with operator discipline. Train them in possible ways to trick them.
2. Even if it happens, make exfiltration astronomically slow by using big-key cryptography

Big-key cryptography means using very long private keys. Instead of 32-byte keys, use (say) a 10MB private key. Exfiltrating a 10MB key with a human in the loop is so expensive and slow that exfiltration isn’t practical.

Cryptographic constructions

The baseline construction is just public-key authenticated encryption (for example, using ECIES). This works well. Your peer’s public key can be hardcoded in the firmware of your TX (predistributed). Or alternatively you can introduce new peers by punching / typing the public key on the keyboard (which is connected to your TX). Note that TX has a unidirectional link to RX, so you can see your own messages you sent.

The full protocol goes like this:

• Alice TX generates $s:= (s_1, s_2)$ at random, uses it to key a symmetric big-key cipher and encrypt message $m$.
• Alice TX sends $c := (\text{pk-enc}(\text{pk-bob}, s_1), \text{big-pk-enc}(\text{pk-bob}, s_2))$ where pk-enc is regular ECIES and big-pk-enc is a big-key public key encryption scheme.
• Bob RX receives and decrypts $s$. Uses $s$ to decrypt $m$.
• When Alice wants to send subsequent messages, she sets $s \leftarrow h(s)$ and uses $s$ to encrypt a new message.

(Gateways omitted in the description above.)

A wrinkle is that you can’t do a full Diffie-Hellman exchange, since there is no bidirectional channel by design. This prevents us from getting the traditional “perfect forward secrecy” properties. We can get slighter weaker post-compromise security by hashing the key material on each message round. Like this, a compromise of endpoint at time N can’t reveal anything about N-1.

(You can still provide some security for future messages if you send on each message material to be added to the shared secret. That only works if the adversary doesn’t get a copy of every message. This assumption is pretty strong.)

Big-key public key encryption. For a concrete scheme, see the accompanying post.

Slow/high domains

In addition to the segregation into RX/TX/GW explained above, there’s a hardware-enforced bandwidth limited channel between keyboard and TX, and between RX and display. The goal here is to restrict to a few bits per second the information that can flow in those links.

We do this to provide exfiltration resistance. We do not speed-limit the unidirectional links TX -> GW, TX -> RX nor GW -> RX. These channels can carry a considerable bandwidth (even though they are unidirectional) since big-key cryptography is expensive (can result in large ciphertexts too).

Unidirectional links consideration

You can’t use ARQ or selective retransmission. We resort to the simplest forward error correcting code: just send the same thing a bunch of times, and hope for the best.

A more elegant solution could be using fountain codes. Keep sending constantly the most recent messages, in case the data link goes temporarily down.

Hardware

I’m prototyping each node with 3 raspberry pis linked with unidirectional serial links. I’m using two UARTs in the raspberry: the hardware one and a soft uart via the kernel module https://github.com/oreparaz/soft_uart.

You can also implement all 3 nodes within a single FPGA. This is left for future work.

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.

The canonical algorithm to solve this is Pollard’s Kangaroo algorithm (extended to distributed search by van Oorschot and Wiener). This takes about $(2+o(1))\sqrt{N}$ group operations. This is an asymptotic measure; but here we want to get concrete and see the concrete cost of breaking (say) a 70-bit discrete log challenge in 2025 USD.

The code

We take a GPU implementation for Pollard’s Kangaroo, with minimal modifications to make it work on different GPU architectures.

The platform

We have the following GPUs available for rent:

The machines are rented from vast.ai, a marketplace for GPU work. GPU owners can rent out GPU time and set a floor bid price. I don’t know much about vast.ai but the experience overall was great: top up $5 and connect 5 minutes later to random machines with big GPUs (some with a residential IP address, yay)

Results

• How many 70-bit logarithms you can get with a $10 budget?
  • Titan Xp: about 4500
  • RTX PRO 6000: about 710. This is a bit surprising, but note that this is 10x more expensive than the Titan Xp.
  • H200: TODO
• How many 64-bit logarithms you can get with $10 budget?
  • Titan Xp: about 13428

Conclusions

• For mid-size problems (around 64-bit problems), older and cheaper GPUs are great. They are pretty efficient and can be optimal for $ / computation (not $ / speed)
• For smaller problems you’re probably better off with just a CPU.
  • A 50-bit problem takes just around 11.5s on an Intel E5-2680 v4 @ 2.40GHz. On a Titan Xp it takes about 17s (203 per hour, or about 41000 for \$10)

eye candy

Example problem for 70-bit ECDLP on an interval:

Start : 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F3297110CEFE6DF0F00AF193D4
Stop  : 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F32971110EFE6DF0F00AF193D3
[1] Priv: 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F3297111067279BA00590DBE69
    Pub: 0364FBFDFF900733243009E571BC503762EC7A809B132D50F2558B2C431E6E4AE0

>>> bin(0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F32971110EFE6DF0F00AF193D3 - 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F3297110CEFE6DF0F00AF193D4 + 1)
'0b10000000000000000000000000000000000000000000000000000000000000000000000'

RTX PRO 6000 drawing 300 Watts:

Titan Xp drawing about 250 Watts:

Log for the Titan Xp:

NVIDIA Titan Xp - 50-bit ECDLP Benchmark Results
Date: Fri Nov  7 06:07:01 PM CET 2025
========================================

Run 1: 21s
Run 2: 17s
Run 3: 17s
Run 4: 18s
Run 5: 17s
Run 6: 18s
Run 7: 17s
Run 8: 17s
Run 9: 18s
Run 10: 17s

All tests completed!
Statistics:
===========
Total runs: 10
Total time: 177s (2m 57s)

Mean time: 17.70s
Median time: 17.0s
Min time: 17s (Runs 2, 3, 5, 7, 8, 10)
Max time: 21s (Run 1)

Sorted times: 17, 17, 17, 17, 17, 17, 18, 18, 18, 21

10 GPU-Hour Throughput Estimate:
=================================
10 GPU-hours = 36,000 seconds
Average time per challenge: 17.70s
Estimated challenges in 10 GPU-hours: ~2,033 challenges

Per hour rate: ~203 challenges/hour
Per day rate (24h): ~4,881 challenges/day

Hardware:
=========
GPU: NVIDIA Titan Xp (Pascal, Compute 6.1)
CPU: 4 threads
CUDA: 8.0
Configuration: GPU Grid(60x256), DP size=9
GPU Throughput: ~565-690 MK/s (typical: ~575 MK/s)


NVIDIA Titan Xp - 64-bit ECDLP Benchmark Results
========================================

Run 1: 40s
Run 2: 51s
Run 3: 43s
Run 4: 74s
Run 5: 79s
Run 6: 46s
Run 7: 65s
Run 8: 43s
Run 9: 66s
Run 10: 40s

All tests completed!

Statistics:
===========
Total runs: 10
Total time: 547s (9m 7s)

Mean time: 54.70s
Median time: 48.5s
Min time: 40s (Runs 1, 10)
Max time: 79s (Run 5)

Sorted times: 40, 40, 43, 43, 46, 51, 65, 66, 74, 79

10 GPU-Hour Throughput Estimate:
=================================
10 GPU-hours = 36,000 seconds
Average time per challenge: 54.70s
Estimated challenges in 10 GPU-hours: ~658 challenges

Per hour rate: ~66 challenges/hour
Per day rate (24h): ~1,584 challenges/day

Hardware:
=========
GPU: NVIDIA Titan Xp (Pascal, Compute 6.1)
CPU: 4 threads
CUDA: 8.0
Configuration: GPU Grid(60x256), DP size=9
GPU Throughput: ~565-690 MK/s (typical: ~575 MK/s)

Log for the RTX PRO 6000:

Statistics:
================================================
Total runs:    10
All solved:    10/10 (100% success rate)
Total time:    758 seconds (12m 38s)

Minimum time:  49 seconds
Maximum time:  126 seconds
Mean time:     75.8 seconds
Median time:   75 seconds

Sorted times: 49, 51, 57, 72, 72, 78, 81, 86, 86, 126

Performance Metrics:
================================================
Average GPU throughput: ~3.9 GK/s
Range searched per run: 2^70 (1,180,591,620,717,411,303,424 keys)
Keys per second (avg):  1.56e+19 (2^64.09)

CPU-only is faster for 50-bit problems, slower for 64-bit problems

  Key Observations:

  1. Huge variance in CPU times: The probabilistic nature of Pollard's Kangaroo shows extreme variance for CPU-only mode:
    - Fastest: 104s
    - Slowest so far: 625s
    - That's a 6x difference between best and worst case!
  2. CPU vs GPU comparison (preliminary):
    - CPU average so far: ~393s (based on first 4 tests)
    - GPU average (from earlier): 54.7s
    - GPU is ~7.2x FASTER than CPU for 64-bit problems ✅
  3. This confirms the break-even point:
    - 50-bit: CPU is 1.54x faster (11.5s vs 17.7s)
    - 64-bit: GPU is 7.2x faster (55s vs ~393s)
    - The crossover happens somewhere between 50-64 bits

Discussion / TODO

• code: there are no modifications to the code for different GPUs. this is probably very suboptimal. experiment with varying parameters
• this is probabilistic. factor success probability
• make an automated discovery of what’s the most economic platform to solve this with the live json bidding from vast.ai
• algorithmic: There are improvements by Galbraith, Pollard and Ruprai that bring the runtime down to $(1.661 + o(1))\sqrt{N}$ https://eprint.iacr.org/2010/617.pdf
• how to rent out your GPUs https://cloud.vast.ai/host/setup

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.

the twist

So far, all pretty standard. The twist here is that the dongle’s secure processor is isolated by design – it’s airgapped in one direction. The dongle’s secure processor can send data to the computer, but not the other way around. This means the only input the security processor ever sees comes directly from the keyboard – which we assume to be trusted. Malware on the computer can’t talk to it at all. The unidirectional airgap is enforced by means of a “data diode”.

In the demo video you’ll see the message “abc” being signed. You type the message between F5 (start) and F6 (end). The signature gets appended directly after your message, prefixed with psig-. This makes it easy to type directly into emails, chats, or whatever.

Example message:

Hi, hello world from punchsig! psig-1d70ddcfd35e35b78a5a4cbbf7844a7c405c1dac725c7bac48bd7093555cf7130e2a04d563aa0ace0b330c440601524d4c434ad3298ec02e862ef0750eee4c00

security

How the sausage is made. Inside, this thing is made of two processors:

• The red side of things is connected to the keyboard, reads keystrokes, performs signing and forwards them to the blue board over a unidirectional serial link.
• The blue board just receives keystrokes over the serial link and forwards them to a PC. It emulates a USB HID keyboard.

This works differently from a YubiKey. With a YubiKey, the message to be signed comes from the computer — so malware could tamper with it before it’s signed. The user might notice the final message isn’t what they intended, but malware can still batch two signing requests: the real one and a sneaky extra on the side. While YubiKeys can require a user tap for confirmation, it’s easy for malware to fake an error and trick the user into tapping twice.

We go a bit further than the conventional wisdom of “keys are in hardware, they are inextractable”. Hardware dongles don’t live in a vacuum: they must get the input to sign from somewhere. In the majority of the cases, this means getting the input from a host computer. If this host computer is compromised, then malware can sign arbitrary messages. That’s bad. Even if malware can’t access key material, it can sign whatever they want. By forcing the

Are screens enough? One way of dealing with this is putting a screen on the signer. This provides “secure output”. The user is expected to verify what is on the screen vs a trusted reference. There are multiple sharp edges with this: a) how does the user know what a “trusted reference is? b) how is the user expected to be diligent and verify 128 bits (and not be lazy and verify “the few first and few last” bits)?

future

The current implementation of punchsig is a prototype I built in a couple of hours – it does have rough edges and is not suitable for production. Directions for improvement:

• Implement proper key generation. Implement some kind of lightweight “console mode” to print public keys, generate new keys, etc
• Secure boot
• Firmware builds today are reproducibly by means of nix, but they lack documentation
• Implement forward-secure signatures. This would be nice to protect signatures against future compromise. Some scheme based on certs or Krawczyk’s trick would be relatively easy to implement.
• Implement an attestation CA for locally assembled punchsig
• Protect against replays. Today the user can type by themselves a timestamp. It would be great if this is better handled. One option is adding an RTC (but this adds components + a coin cell battery). A GPS module is another alternative.
• Improve reliability of the USB PIO stack. Not all keyboards enumerate yet.

hardware

The two boards are based on Raspberry Pi Pico, connected like this.

code

Firmware is pretty straighforward and largely taken from sample code. There is great code for the raspberry pi pico that implements USB HID host and client. There’s a very simple framing protocol that forwards the HID reports from one board to the other.

Source available at https://github.com/oreparaz/punchsig.

verification

This is the javascript verification page I’ve been using for testing: https://www.reparaz.net/punchsig-verify. Some messages to try:

• Yo, does this thing work? psig-f1424b7587150bb83ac8a895bb4f3424a6228b747083369638d5bfd7f24bd752f1fcbc3a140d431295ecdb163d224c608a0a7d633684a5cc23d1c1791821e30c

• 1, 2, 3, tango! psig-b6291b8c9724429822816e486cda12a690ba861ef7567769d4d24a9f42270941d40e9e4282ac0517bfce033c992a136603f1751ba8c77396a52e3e427fd6b206

• ahem, aham, ahum psig-4ca4a688595e70b1907442c2541a2e11a51257344815acfaf7acde2eb437b06244dfb9b44939520a44a1436c77fc0f3800e4144d9e6a10d29ecd975cf2b4aa06

Parameters:

• All use the ed25519 testing public key 34bc5d83dd91bfa5df1ecada9630e3646fdb497afb4353d7d9f6ba2bb9ac41c0.
• All use the global context punchsig v2025-05-18 context. This is prepended to the message.

build

Some pictures to inspire (or scare) you: the “case” is just a sandwich of styrofoam (terrible thermal properties (but the microcontrollers don’t get hot anyways), provide great physical durability).

There are just two boards that are embedded in the styrofoam:

Connected unidirectionally with 3 wires:

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:

References:

• Arnaud Ebalard, Patricia Mouy, and Ryad Benadjila. Journey to a RTE-free X.509 parser. pretty didactical paper: https://www.sstic.org/media/SSTIC2019/SSTIC-actes/journey-to-a-rte-free-x509-parser/SSTIC2019-Article-journey-to-a-rte-free-x509-parser-ebalard_mouy_benadjila_3cUxSCv.pdf
• Presentation slides: https://www.sstic.org/media/SSTIC2019/SSTIC-actes/journey-to-a-rte-free-x509-parser/SSTIC2019-Slides-journey-to-a-rte-free-x509-parser-ebalard_mouy_benadjila.pdf
• Presentation at SSTIC 2019, with video (in french) https://www.sstic.org/2019/presentation/journey-to-a-rte-free-x509-parser/
• Code: https://github.com/ANSSI-FR/x509-parser

Related:

• Paper: https://iacr.org/submit/files/slides/2023/rwc/rwc2023/46/slides.pdf

Other projects from ANSSI:

• libdrbg (no frama-c verification) https://github.com/ANSSI-FR/libdrbg
• libecc (well engineered) https://github.com/libecc/libecc

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.

PCB

This is a picture of the main board. We can identify some components:

• the main Toshiba processor (IC1 in the picture) is in a LQFP64 package. Markings on the chip: 1904 HAL, T5DE 1UG, 916549. I couldn’t find any datasheet.
• the small IC on the right (IC5) is an 4-kbit I2C EEPROM (markings on the chip: 4G08 82753). This is a 3.3 V EEPROM and behaves like a 24C04.

The I2C bus for the EEPROM is conveniently exposed as two through-holes vias. This is annotated in the picture. It is very easy to solder this bus to your favorite microcontroller. Your extra microcontroller can drive the EEPROM (I2C is a multi-master bus).

High-level behavior

After the unit completes measuring your blood pressure (which takes about a minute), the microcontroller stores the whole measurement into the EEPROM. This is done without any user interaction. The EEPROM memory is large enough to store the last 14 measurements.

EEPROM memory map

This section provides the information necessary to achieve interoperability:

• The EEPROM is 512 bytes long and holds 14 files.
• Each file is 14 bytes long and stores a single measurement.
• The first file starts at offset 0xAC, the second one starts at 0xBA, and so on till the last file that starts at 0x112.
• Each file stores:
  • 1 byte for the systolic pressure, stored as (measured_systolic_mmHg - 25). For example, a systolic pressure of 125 mmHg will be stored as 0x64. (This encoding thus can represent values from 25 mmHg to 280 mmHG.)
  • 1 byte for the diastolic pressure in mmHg units. For example, a diastolic pressure of 80 mmHg will be stored as 0x50.
  • 1 byte for the pulse measurement in BPM “units” (min^-1). For example, a pulse of 53 bpm will be stored as 0x35.
  • 5 bytes that appear to be nearly constant. In my unit these are 0E 20 04 3F 10.
  • 6 more bytes that I don’t understand what they do. The two last look pretty random / uniformly distributed and could be a CRC, although I didn’t dig deeper.
• There are other interesting addresses:
  • Address 0x60 stores the “last measurement file index”. It is a pointer to the measurement that was last written to EEPROM. The mapping “pointer value → file offset” is pretty regular with an exception for the pointer value 0x00:

     mem[addr=0x60] -> file offset
     -----------------------------
     0x01 -> 0xAC (0xAC + 14*0)
     0x02 -> 0xBA (0xAC + 14*1)
     0x03 -> 0xC8 (0xAC + 14*2)
     0x04 -> 0xD6 (0xAC + 14*3)
          ... regular ...
     0x0C -> 0x146 (0xAC + 14*11)
     0x0D -> 0x154 (0xAC + 14*12)
     0x00 -> 0x162 (0xAC + 14*13) // last one, NB: discontinuity!
  

  • Address 0x04 and 0x05 store the total measurement count in little endian. (This is duplicated in addresses 0x06-0x07.) This counter advances even if the measurement is bad. Bad measurements aren’t written to a file.

How to figure this out for yourself. The easiest is to dump the EEPROM contents before and after a measurement and study how the contents change. You can read this EEPROM with any 24C04 driver. I had success with https://github.com/nopnop2002/esp-idf-24c . The Toshiba microcontroller talks to the EEPROM at 320 kbit/s (but of course you can talk to it at a slower bitrate). For example, after a measurement the following EEPROM contents changed:

• the pointer to last measurement (stored at 0x60) advanced from 0x09 to 0x0A
• the file starting at address 0x12A (corresponding to 0x0A) changed
• the first 3 bytes of the file starting at 0x12A are 6f 45 36 which mean:
  • 0x6f: systolic pressure of 0x6f+25 = 136 mmHg
  • 0x45: diastolic pressure of 0x45 = 69 mmHg
  • 0x36: pulse of 54 bpm
• the contents at 0x04 advanced by one (total number of measurements).

Other references. The unit I have has the following markings: MODEL: BP710N, REF HEM-7121-Z. As of 2024 it looks like Omron is selling an updated model BP7100. I don’t know how the BP7100 looks like inside. Chances are that it is very similar.

Warning. You are on your own. Any modification will likely void your warranty. THE INSTRUCTIONS ARE PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE INSTRUCTIONS.

• 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.

Agreement

Establishing a notion of agreement in discrete variables in easy. For example, we can vote to decide where a group should go have dinner (= quorum-based technique). Or we can say we trust certain message when at least a certain threshold of parties trust it (and express this via cryptographic signatures). This works nicely. We can build very robust systems with this approach, a la triple-modular redundancy. Commercial planes land autonomously hundreds of people safely thanks to this.

Establishing agreement in continuous variables is a bit harder. After all, what are outliers? Five-sigma deviation from the mean? Why not \(42 \sigma\)? And how do you take into account the measurement confidence? Or the sensor accuracy?

Never go to sea with two chronometers; take one or three

Marzullo 1983

Keith Marzullo proposed a synchronization algorithm based on interval intersection. Marzullo algorithm provides accurate time synchronization, but does not really deal with faulty clocks. This is the basic idea:

NTP uses Marzullo’s algorithm as inspiration.

Lamport 1987

Leslie Lamport wrote in 1987 the absolutely delightful Synchronizing Time Servers.

The main advantage is that Lamport’s technique can simultaneously deal with faulty clocks and provide similar time to nodes that are relatively close:

Lamport noticed there was something off with Marzullo’s approach. Lamport expresses with astonishing clarity that two nodes that receive a slightly different view of the same clocks may end up with very different end result. This is represented in this picture:

In the context of distributed systems, this is important. You’d expect “close” nodes to have a “similar” view of the time. Technically, this is because the agreement function is not ``Lipschitz continuous’’

The solution Lamport provides is essentially averaging midpoints when the outliers are thrown away. In precise terms:

Drawback: Lamport could not give an “optimal” solution for this. (It is telling the honesty of Lamport, hardly seen in other authors.)

Schmid and Schossmaier 1999

Fast forward, 20 something years later, Schmid and Schossmaier solved Lamport’s concern in their paper How to Reconcile Fault-Tolerant Interval Intersection with the Lipschitz Condition.

They define a very simple agreement function that is Lipschitz continuous, and that takes into account all available information:

This is a comparison of Schmid and Schossmaier vs Lamport function showing Lipschitz continuity in action:

• 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.

Server architecture

Time to build! We partition the time server into two clearly distinct blocks:

• trusted domain: comprised of a GPS module plus a small RTOS-based microcontroller. Here we implement the following functionality: parsing GPS module NMEA data, key storage, generate cryptographic signatures

• untrusted domain: a raspberry pi running a golang binary implementing the following functionality: talk to network peers over UDP, construct requests to the trusted domain for signing bundling multiple requests (Merkle tree construction)

  

Why? The whole point of partitioning this way is to minimize attack surface and compact all the security-critical functionality in a small block. This partition is in a sense optimal: the trusted domain does the minimum amount of work needed, minimizing the trusted codebase. All networking code is offloaded to the raspberry (none of which is security critical), all security-sensitive is in the trusted domain. No secrets live in the raspberry. The worst possible impact of a compromised untrusted domain is availability.

The interface between those two blocks looks essentially like this (less important fields omitted):

typedef struct signing_request_t {
  uint8_t merkle_root[32]; // (merkle-)hash of all client nonces
};

typedef struct signing_response_t {
  uint64_t midpoint; // time at the moment of signing
  uint8_t signature[64]; // essentially, signature over merkle_root + midpoint
};

Note that data in signing_request can be 100% attacker controlled — this is fine and actually a scenario we accept. This means the raspi can be 100% popped (the “only” consequence being reduced availability). Time is not chosen by the untrusted domain, the time reference (the GNSS) is directly fed into the trusted domain. The communication between those two domains is a simple serial line, with no framer (yolo), and fixed size packets (difficult, but not impossible, to screw up). The raspi cannot reflash the microcontroller; a human has to plug a programmer to the microcontroller.

• 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…

Not today! let’s build a simple cryptographic desk clock to set the House Standard Time in proper cryptographic fashion. Here is the limited edition, mission-critical clock sitting in my home office:

Protocol

The protocol we’ll be using for clock synchronization is roughtime. This is a pretty new protocol introduced in by Adam Langley (Google). It’s pretty barebones, and simple enough you can write a client in an evening — so much fun.

roughtime is essentially a challenge-response protocol. The client sends a random 32-byte challenge to the server, which replies with a signed message containing the client challenge and the current time. (There’s some machinery to make this efficient, like packing requests in a Merkle tree, but this isn’t important now.)

Since you’re probably familiar with NTP, here are the key differences:

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?

Working principle

nonce-sanitizer implements an AEAD interface. The input/output behavior is identical to the AEAD mode selected. (Currently, ChaCha20Poly1305 and AES-GCM.) In addition, it will check in the background if the nonce passed is sane, and bail if it isn’t. For this, nonce-sanitizer keeps the passed nonces in an internal state. The current definition of sane is: the same combination (key, nonce) hasn’t been passed before.¹

Functionality-wise, this tool internally looks something like this:

 func encryptAEAD_NonceSanitizer(key, nonce, plaintext) -> ciphertext {
    if isRepeatedNonce(key, nonce, plaintext) {
       bail();
    }
    ciphertext = encryptAEAD(key, nonce, plaintext)
 }

Developer ergonomics

To use nonce-sanitizer, you just replace the calls to AEAD encrypt with the implementation provided by nonce-sanitizer. Everything else should just work. This is 100% backwards compatible —the encryption behavior remains identical. There’s no need to bump any protocol version.

• In the happy path, if your nonces behave, one you set this up, you can forget about it. So this is kind of additive security precaution
• In the sad case (naughty nonces), nonce-sanitizer will bail and prevent the confidentiality loss.

There’s no need to configure anything. Performance-wise, nonce-sanitizer takes a small hit. Check if this is significant in your application.

Golang implementation

A PoC in golang is available at https://github.com/oreparaz/go-nonce-sanitizer. This implementation wraps golang.org/x/crypto/chacha20poly1305.

How to use it. The interface transparently wraps the AEAD mode, so you can use it as the AEAD mode. This is the single-line code modification needed to add nonce-sanitizer to age:

diff --git a/internal/stream/stream.go b/internal/stream/stream.go
index 7cf02c4..bc8a321 100644
--- a/internal/stream/stream.go
+++ b/internal/stream/stream.go
@@ -11,7 +11,7 @@ import (
        "fmt"
        "io"

-       "golang.org/x/crypto/chacha20poly1305"
+       "github.com/oreparaz/go-nonce-sanitizer/chacha20poly1305"
        "golang.org/x/crypto/poly1305"
 )

Raw performance. On a GCP ec2-micro instance:

• for long packets (8 kB), the overhead is small (less than 10% loss of throughput)
• for IP packets (1350 bytes), the overhead is about 33% less throughput
• for very short packets (64 bytes), the overhead is around 3x slowdown

Raw data: output of go test -bench=.:

goos: linux
goarch: amd64
pkg: github.com/oreparaz/go-nonce-sanitizer/chacha20poly1305
cpu: Intel(R) Xeon(R) CPU @ 2.20GHz
Benchmark/Seal-WithoutNonceSanitizer-64-2     293.65 MB/s       0 B/op     0 allocs/op
Benchmark/Seal-WithNonceSanitizer-64-2        109.59 MB/s      49 B/op     2 allocs/op
Benchmark/Seal-WithoutNonceSanitizer-1350-2  1147.98 MB/s       0 B/op     0 allocs/op
Benchmark/Seal-WithNonceSanitizer-1350-2      857.35 MB/s      50 B/op     2 allocs/op
Benchmark/Seal-WithoutNonceSanitizer-8192-2  1407.33 MB/s       0 B/op     0 allocs/op
Benchmark/Seal-WithNonceSanitizer-8192-2     1323.52 MB/s      55 B/op     2 allocs/op
PASS
ok      github.com/oreparaz/go-nonce-sanitizer/chacha20poly1305      8.727s

Performance of age. In a file encryption application like age, the overhead is imperceptible to the human eye. With instrumentation, encryption of a 650 MB file takes 2.0 seconds. Without instrumentation, it takes 1.9 seconds.

# with instrumentation
$ time ./age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p < /tmp/junk > /tmp/junk.age

real	0m2.082s
user	0m0.645s
sys	0m1.001s

# without instrumentation
$ time ./age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p < /tmp/junk > /tmp/junk.age

real	0m1.969s
user	0m0.605s
sys	0m0.944s

FAQ

When should I use it? Is it good for me? If you are picking nonces, nonce-sanitizer is for you. If your library picks nonces for you, you’re fine.²

I’m using libsodium, do I have to worry? You can use a well-established library like libsodium or tink and still misuse nonces. So refer to the previous point: if you’re picking nonces, yes, you can use nonce-sanitizer.

Why should I not use nonce-sanitizer? Perhaps if you’re struggling for performance, or are very tight on RAM. But really, so many people have tripped here before, so think twice.

Will this eat all my RAM?. The internal state that stores nonces grows as more nonces are passed. This grows until a threshold is hit, and from there on old nonces are discarded. So the RAM usage is capped and won’t grow unbounded. This is a tunable parameter.

Is it going to ruin performance? There are too many different applications of AEAD to make general statements about the impact of this instrumentation. In general, nonce-sanitizer has small impact in client-side code (where an increased memory usage is tolerable), or applications that run in human time (and aren’t affected by slight increase in latency). Busy servers are trickier, but probably acceptable for debug builds/deployments.

I’m using random nonces, I don’t need this? You can still screw it up, see https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1592990 (https://www.chromium.org/chromium-os/u2f-ecdsa-vulnerability/). Would you notice in that case?

Tell me about misuse-resistant modes. You should use them! But sometimes it’s not easy to retrofit those.

Why haven’t I heard about this before? That’s a good question. We can only speculate. This isn’t rocket science, but probably keeping track of all nonces was too expensive. But today memory in phones and computers is cheap.

Inspiration. This tool takes inspiration from memory sanitizers for non-memory safe languages. Memory sanitizers shadow every byte of memory from your program to hopefully detect memory misuse before they become a real problem. Thanks to tools like AddressSanitizer or Valgrind we can write C and not stress too much about it. Tools help us sleep well at night. (Note that nonce-sanitizer applies both to non-memory safe and memory safe languages – memory safety doesn’t have anything to do with misusing nonces.)

Limitations

The tool keeps some state in RAM. The tool won’t detect all nonce collisions since this state is pruned from time to time.

Extensions

I’d love to see nonce-sanitizer in other languages, or integrated into existing libraries. I’m not planning to work on this but ping me if you want some pointers to work on this.

Optimizations / internals

The following design decisions might be useful if you want to reimplement this:

• Should I store the cryptographic key itself? You can make all the data structures secret-free by storing a hash of the key if you need it. Unsure if this is worth it if the key lives in the same memory space

• Should I include plaintexts also in the map? The only reason for this is to not have false alerts where the same (key, nonce, plaintext) is passed. This isn’t a violation of AEAD usage —you’re performing exactly the same computation

• What data structure should we use for storing nonces? It just should be very fast. In golang we resort to a hash map. This PoC implementation can be for sure optimized; PRs are welcome.
• What prunning strategy should we use? Right now we store the last 1000 nonces, and prune the cache from time to time, so that memory usage doesn’t grow unbounded. You can use a circular buffer to have consistent performance, tbd what the sweet thresholds are.
  • You could probably use distinguished points to (probabilistically) detect collisions without enormous amounts of memory. (Keeping track only of those nonces with a certain prefix.) Feels like a combined method would be a good choice: keep the last N nonces and keep the last N “distinguished” nonces.
• Should we compress IVs? too fancy for a V1.0
• Should we check for repeated nonces upon receiving? Not duplicating nonces is a sender responsability (as the sender will bear the consequences of the confidentiality loss), but it seems cheap enough to also do it on the receiving side. This might help spot buggy implementation on the remote peer.