# Before fighting banks, I was working for them, trying to patch a broken system

*From Fighting with C++ to Flowing with Rust: Revisiting Whitebox Cryptography*

I posted a tweet today that unlocked a flood of memories, some fond, some frustrating, and all deeply technical.

> *Fun fact: before fighting banks, I was building cloud-based payment solutions for them.*

It’s ironic, really. Today, my focus is on Bitcoin and freedom tech,fixing the money to fix the world. But back in 2013-2014, before Ethereum even existed, I was deep in the trenches of the legacy financial system, trying to solve a problem that seems trivial now but was monumental then: **Software-based Contactless Payments.**

### The "Wild West" of NFC (2013)

To understand why this was hard, you have to remember the landscape of 2013. Apple Pay didn't exist. Android Pay didn't exist.

If you wanted to do contactless (NFC) payments, you needed a **Secure Element (SE)**, a dedicated hardware chip to store cryptographic keys. The problem? The hardware sector was hopelessly fragmented.

* **The Mobile Network Operators (Sim cards)** wanted to own the SE.
* **The Phone Vendors (Samsung, HTC, etc.)** wanted to own the SE.
* **The SD Card manufacturers** wanted a slice of the pie.

It was a political deadlock. The "pie" was being fought over so aggressively that adoption stalled. No one could agree on who held the keys.

### Enter Cloud-Based Payments (And a Security Nightmare)

We saw an opportunity: **bypass the hardware entirely.** We decided to build the first 100% software-based contactless solution. This was before Mastercard and Visa even standardized Cloud Based Payments (MCBP and VTS). We were blazing a trail.

But this created a terrifying security context.

In traditional security, you worry about someone hacking the network. In software-based payments on Android, **the user’s own phone is the hostile environment.**

If an attacker has root access to the phone, they have "God Mode." They can:

* Read your application's memory.
* Hook into function calls.
* Debug every single step of your execution.
* Extract your AES keys the moment they are loaded into RAM.

How do you hide a secret key from an attacker who has total control over the room where the key is being used?

### The Magic of Whitebox Cryptography

This is where **Whitebox Cryptography** comes in. It’s a fascinating, albeit imperfect, field of study.

In a standard "Black Box" scenario, the attacker sees input and output, but the internal execution is hidden. In a "White Box" scenario, the execution is fully transparent.

To survive this, we had to be clever. We couldn't just leave an AES key sitting in a variable. We had to **smash the key into the algorithm itself.**

1. **Look-up Tables:** We converted the AES logic into massive networks of look-up tables.
2. **Embedded Keys:** The key wasn't data anymore; it was part of the code logic (hardcoded into the tables).
3. **Random Encodings:** We wrapped inputs and outputs in random mathematical bijections so that even if you saw the data moving through memory, it looked like noise.

Back in 2013, implementing this in C/C++ was a **nightmare**. It took weeks of grueling effort. We used custom Rainbow symmetric encryption schemes, Chow et al. based AES, and layers of obfuscation (source-to-source, binary level). It was heavy, complex, and incredibly difficult to debug.

### The Modern Rematch: Rust + AI

Fast forward to now. I wanted to see how much the world has changed. I decided to implement a modern Whitebox AES scheme (based on the Baek–Cheon–Hong 2016 paper) using **Rust**.

And to make it interesting, I used AI as my pair programmer (spoiler: this dude almost did everything and had to do very little intervention during the whole process).

The difference was staggering. What took me weeks of headache in 2013 took me **a few hours** this afternoon (while doing other things, and mostly overseeing the AI agent and providing guidance on the direction).

I managed to build a workspace that includes:

* A clean AES-128 core.
* A generator that creates the massive table structures.
* A runtime evaluator to execute the obfuscated cipher.
* A CLI tool to run it all.

I call it **`whitebox-aes-rs`**.

### Why this is cool (but not production ready)

This project implements a "revisited" scheme using sparse, unsplit 256-bit encodings. It increases the state size to two AES blocks to make algebraic attacks harder.

**Is it unhackable? No.**
In the end, whitebox crypto is just obfuscation on steroids. With enough time and side-channel analysis (DCA), a determined attacker can break it. But the goal isn't invincibility; it's to make the cost of the attack higher than the value of the stolen data.

### The Code

I’ve open-sourced this experiment. It’s not audited, and please, **do not use this to protect real value.** It is for educational purposes.

Here is a taste of how clean the API is in Rust:

use wbaes_gen::{Generator, GeneratorConfig};
use wbaes_runtime::WbCipher256;

// 1. Generate a Whitebox instance from a key
let key = Aes128Key::from([0u8; 16]);
let mut gen = Generator::new(secret_seed);
let instance = gen.generate_instance(&key);

// 2. The 'cipher' now contains the key "baked in"
let cipher = WbCipher256::new(instance);

// 3. Encrypt without ever exposing the original key in memory
let mut block = [0u8; 32];
cipher.encrypt_block(&mut block);

### Final Thoughts

Building this brought back the rush of those early hacking days. We were so proud of the technical complexity we achieved. We thought we were fixing payments.

But looking back, we were just patching a broken system. We were building complex obfuscation mazes to protect fiat rails that were already archaic.

We don't need to fight the banks by building better software for them anymore. We have an alternative.
**Bitcoin.**

Fix the money, fix the world.

## Resources

- [Github repo of this article - Baek–Cheon–Hong’s “White-Box AES Implementation Revisited” scheme, written in Rust.](https://github.com/AbdelStark/whitebox-aes-rs)
- [S. Chow et al., “White-Box Cryptography and an AES Implementation,” SAC 2002.](https://dl.acm.org/doi/10.5555/646558.694920)
- [J. A. Muir, “A Tutorial on White-box AES,” 2013.](https://eprint.iacr.org/2013/104.pdf)
- [C. H. Baek, J. H. Cheon, H. Hong, “White-Box AES Implementation Revisited,” JCN 2016 (ePrint 2014/688).](https://eprint.iacr.org/2014/688.pdf)