Forem: Martin Kambla

Delivering E2EE media without blowing up Postgres

Martin Kambla — Tue, 05 May 2026 03:54:24 +0000

When I launched my messenger, the media upload path looked like this:

client → encrypt → POST /media/upload → INSERT INTO media (ciphertext BYTEA)

Functionality was there, 2MB, 25MB (sometimes times out) and at 100MB you get blowups. Here's a brief "lessons-learned" about the road of Postgres BYTEA at scal, and the architectuer I ended up with shipping 200MB encrypte video without the server ever seeing plaintext.

Why BYTEA was good at first?

I've always preferred Postgres to any other DB system. I'm sure others have their benefits in different scenrios but I usually when dealing with serious applications I use Postgres.

And for messaging, the attraction was specific. If the ciphertext lives next to the row pointing at it, there's one write, one transaction, one thing to fail. No dangling references between the DB and a blob store if one side of the write fails. Simple.

What breaks?

Then I tried to ship a 50 MB video.

WAL explosion. Every write to a BYTEA column goes through the Write-Ahead Log. A 50 MB attachment is 50 MB of WAL. Multiply by the replication lag on my read replica and I was seeing replication fall 60+ seconds behind on a single upload.

Backup time. pg_dump with BYTEA attachments turns into a slow march. At 100 GB of media my nightly dump was taking over an hour. And every byte of that was stuff the database didn't need to be parsing — it's opaque ciphertext.

Memory pressure. The server was reading the full ciphertext into JVM heap to stream it back to the client on download. One concurrent 100 MB download = 100 MB of heap. Three concurrent downloads on a 1 GB instance and you're in swap.

Connection hold time. An upload that takes 90 seconds holds a DB connection for 90 seconds. With a default pool of 20 connections, ten concurrent uploaders and everything else blocks.

TOAST limitations. Postgres stores large column values in a separate "TOAST" table with its own indexing and compression. TOAST has a hard 1 GB limit per value. I wasn't near that, but I was building a path that led there.

The pattern was clear: Postgres is a great metadata store, a bad blob store. I needed to split them.

The architecture I moved to

client
  │
  │  1. POST /media/reserve   → server issues upload URL + media_id
  │                              + AES-GCM random key to encrypt with
  │                              (key is stored by the client, not the server)
  │
  │  2. encrypt(file, key)    → ciphertext bytes
  │
  │  3. PUT {presigned S3 URL} → DO Spaces / S3
  │
  │  4. POST /media/finalize  → server marks media_id as ready,
  │                              records size + sha256(ciphertext) only
  │
  │  5. send message with media_id + encrypted key (wrapped for recipient)

The key property: the server never sees plaintext, and never sees the media key. The server knows a ciphertext blob exists at spaces://quldra-media/{media_id}. It knows the blob's size and hash. That's it.

On the recipient side, the message carries the media key wrapped for the recipient's device key. The recipient unwraps it, downloads the ciphertext directly from DO Spaces via a short-lived presigned URL, and decrypts locally.

What I had to fix in the client?

Timeout discipline

Default HTTP client timeouts are a lie for large uploads. The Ktor client defaults worked fine for API calls and quietly retried uploads that crossed 120 seconds, which turned into silent data loss — the client thought it had retried, the server had no idea anything had happened.

I split the timeout regime:

val mediaUploadClient = HttpClient(CIO) {
    install(HttpTimeout) {
        requestTimeoutMillis = 10 * 60 * 1000  // 10 minutes
        connectTimeoutMillis = 30_000
        socketTimeoutMillis = 10 * 60 * 1000
    }
    // CRITICAL: retry disabled on /media/upload
    // The upload is not idempotent from the client's perspective —
    // a retry means re-encrypting with a potentially different random nonce,
    // which creates an orphan blob in Spaces.
    install(HttpRequestRetry) {
        retryOnExceptionIf { _, _ -> false }
    }
}

Streaming encryption

You can't hold 200 MB of plaintext in memory on a mid-range Android device. Encryption has to stream:

fun streamEncryptToFile(
    input: Source,
    output: Sink,
    key: ByteArray,
    nonce: ByteArray
) {
    val cipher = ChaCha20Poly1305()
    cipher.init(true, AEADParameters(KeyParameter(key), 128, nonce))

    val buffer = ByteArray(64 * 1024)
    while (true) {
        val n = input.read(buffer)
        if (n <= 0) break
        val chunk = ByteArray(cipher.getOutputSize(n))
        val written = cipher.processBytes(buffer, 0, n, chunk, 0)
        output.write(chunk, 0, written)
    }
    val tag = ByteArray(cipher.getOutputSize(0))
    val tagWritten = cipher.doFinal(tag, 0)
    output.write(tag, 0, tagWritten)
}

64 KB chunks are the sweet spot on Android. Smaller and the per-chunk syscall overhead dominates; larger and you start allocating in a way that pressures GC.

Progress reporting

Users expect a progress bar for a 200 MB upload. Presigned S3 PUTs don't give you one by default — the network layer doesn't know anything about your application-level progress. I wrapped the Source that streams the ciphertext file:

class ProgressTrackingSource(
    private val delegate: Source,
    private val totalBytes: Long,
    private val onProgress: (bytesRead: Long, total: Long) -> Unit
) : Source {
    private var bytesRead = 0L
    override fun read(buffer: ByteArray): Int {
        val n = delegate.read(buffer)
        if (n > 0) {
            bytesRead += n
            onProgress(bytesRead, totalBytes)
        }
        return n
    }
}

And threaded the onProgress callback into a StateFlow the UI could render.

What I had to fix on the server

Presigned URLs, not streaming through the server

The wrong way:

client → POST /media/upload (200 MB body) → server → write to S3

This makes the server a bottleneck on every upload. The correct way:

client → POST /media/reserve (metadata only) → server
server → presign a PUT URL against S3 → return to client
client → PUT to S3 directly (server not involved)
client → POST /media/finalize (metadata only) → server

Server-side, presigning with the AWS SDK is two lines:

val presigner = S3Presigner.create()
val presignedUrl = presigner.presignPutObject {
    it.signatureDuration(Duration.ofMinutes(15))
        .putObjectRequest { req ->
            req.bucket("quldra-media").key(mediaId)
        }
}

The server does no I/O during the upload. No connection held. No heap pressure. It issues a URL, then hears back 90 seconds later when the finalize request comes in.

Verifying what landed

The finalize step is where the server confirms the upload actually happened:

post("/media/finalize") {
    val req = call.receive<FinalizeRequest>()

    val head = s3.headObject {
        it.bucket("quldra-media").key(req.mediaId)
    }

    require(head.contentLength() == req.expectedSize) {
        "uploaded size mismatch"
    }
    // We can't verify sha256 without reading the object — we trust the client
    // for the hash value it reports. The hash is only used for dedup + UX,
    // not security (the ciphertext is already AEAD-authenticated).

    mediaRepo.markReady(req.mediaId, req.expectedSize, req.sha256)
    call.respond(HttpStatusCode.OK)
}

The HEAD request is cheap and confirms the blob exists with the expected size. The client's reported hash goes into the DB for deduplication and UI purposes. The ciphertext itself is already AEAD-authenticated — if someone tampers with the blob in storage, the recipient's decryption will fail with a tag mismatch, so I don't need the server to guarantee integrity.

What it looks like now

After the migration:

Database size dropped from 180 GB to 11 GB overnight. Backups are fast again.
WAL rate dropped by a factor of ~60.
Memory per concurrent upload on the server: effectively zero.
Maximum upload size went from "25 MB before things get flaky" to 200 MB reliably.
Replication lag on the read replica went from 60s+ during upload spikes to under 1s sustained.

The simplicity argument for BYTEA was real — and wrong at this scale. One extra system to operate (DO Spaces) is the right trade for keeping the database focused on what it's good at.

The piece I'd do differently

I'd have set a size threshold from day one: under 1 MB goes into Postgres, over 1 MB goes to object storage, metadata identical in both cases. That way the architecture supports both paths and you pick per-blob based on actual size, not "we decided in advance." It's more code but it's also the path I'd eventually want anyway.

This is post 3 of a short series on the tech behind Quldra, a post-quantum single-device messenger built in Kotlin Multiplatform. Previous posts covered My road to ML-KEM-768 over X25519 for my messaging app and Device distinct messaging: why I killed multi-device and how fingerprint hashing enforces it..

Device distinct messaging: why I killed multi-device and how fingerprint hashing enforces it.

Martin Kambla — Fri, 01 May 2026 21:18:18 +0000

Most messaging apps let you log in on your phone, laptop, iDevice, and browser, with all of your messages synced. It's framed as convenience. It's also an attack surface.

When I was designing my messenger, I made a deliberately unpopular call: one device per account, enforced at the server. This post is about how I implement that, why the enforcement matters more than the policy, and what the recovery story looks like when a user's device dies.

Why one device?

The pitch for multi-device is: "I want my chats on every screen I own." The cost:

Key distribution problem. Every new device needs the session keys. Either you re-derive them from a central secret, losing per-device forward secrecy, or you distribute keys between devices, which creates an extra sync protocol to audit.
Compromise blast radius. A stolen laptop with your Signal desktop logged in is a full compromise of your chat history. In a single-device model, physical access to the one device is the attack, not access to any of N devices.
Account-recovery social engineering. "Hi, this is Bob, I got a new iPad, can you add it to my account?" is the oldest trick in the book. If the account can only ever have one device, the answer is always: "No. Do recovery."

For an end-to-end encrypted app where I can't see the content, multi-device means I'm maintaining a protocol whose failure modes I can't observe. Single-device means the server's job is simple: track which install is the canonical one, and refuse anyone else.

The fingerprint hash

Every install of the app generates a random 32-byte install ID on first launch and persists it in secure storage: Keychain on iOS, EncryptedSharedPreferences on Android. The server never sees this raw ID. What it sees is a hash:

fun computeFingerprintHash(installId: ByteArray, platform: String): String {
    val digest = MessageDigest.getInstance("SHA-256")
    digest.update(installId)
    digest.update(0x00)
    digest.update(platform.toByteArray())
    return digest.digest().toHexString()
}

On registration, the client sends this hash. The server writes it into the installs table:

CREATE TABLE installs (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL REFERENCES users(id),
    active_fingerprint_hash TEXT NOT NULL,
    recovery_count INT NOT NULL DEFAULT 0,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    UNIQUE (user_id)
);

Note the UNIQUE (user_id) constraint. One row per user. No multi-device possible at the schema level. If you wanted to add it later, you'd have to change the table shape, which is the point.

The 8-second poll

Every authenticated request the client makes includes its fingerprint hash in the auth envelope. The server checks it against the stored active_fingerprint_hash. If they match, the request goes through. If they don't:

route("/users/me") {
    get {
        val auth = call.principal<QuldraPrincipal>()!!
        val install = installRepo.findByUserId(auth.userId)
            ?: throw NotFoundException()

        if (install.activeFingerprintHash != auth.fingerprintHash) {
            call.respond(HttpStatusCode.OK, mapOf(
                "error" to "device_deactivated",
                "recoveredAt" to install.recoveredAt?.toString()
            ))
            return@get
        }

        call.respond(HttpStatusCode.OK, install.toDto())
    }
}

The client has a background poll loop that hits /users/me every 8 seconds:

private fun startDeviceCheckLoop(scope: CoroutineScope) {
    scope.launch {
        while (isActive) {
            delay(8_000)
            val result = apiClient.getMe()
            if (result.error == "device_deactivated") {
                handleDeactivation(result.recoveredAt)
                break
            }
        }
    }
}

Why 8 seconds? Because:

Short enough that a deactivated device doesn't stay alive long. If someone steals your phone and does recovery on their new one, your old device knows within 8 seconds and locks itself.
Long enough not to hammer the server. At 8-second intervals, a single active user makes 10,800 requests per day. That's acceptable for now, but it is still a cost worth watching.
Feels instant to the user triggering the recovery. They tap "I've got a new phone," hit their recovery path, and 8 seconds later the old device visibly dies. That feedback loop matters for the mental model.

Recovery = clean slate

When a user recovers onto a new device:

The new device generates a fresh install ID and computes a new fingerprint hash.
It hits the recovery endpoint with the user's recovery code.
The server updates active_fingerprint_hash to the new hash, increments recovery_count, and sets recovered_at = NOW().
The old device's next poll returns device_deactivated, and the client hard-resets.

The clean-slate part matters: messages sent before recovered_at are not synchronized to the new device. This is a deliberate E2E choice. The new device doesn't have the old room secrets. They're gone. Even if the server served the ciphertext, the new device couldn't decrypt it. Showing "undecryptable message" rows would be a worse UX than just pretending they aren't there.

The conversation starts fresh from the recovery timestamp, which fits the security model: whoever stole the old device can still see the old messages on it until it dies on poll, but everything from the recovery moment onward is only visible on the new device.

What this costs you as a builder

Single-device enforcement isn't free:

You have to explain it. Users coming from WhatsApp or Telegram expect multi-device. The onboarding flow has to sell "you get one device and here's why" without sounding defensive. I learned to frame it as a feature, "your account is protected by physical possession," rather than a limitation.
Desktop/web is harder. You can't have a persistent web session that survives the phone dying. I ended up building a separate ephemeral web chat that uses temporary keys and doesn't count as "the device." It's a different product surface with its own trust story.
Testing is awkward. Every manual QA pass burns through install IDs because each recovery is a real recovery. I wrote a server-side dev endpoint that resets fingerprint state for a test user. Gated behind APP_ENV=dev, obviously.

What could be different?

I think there's always room to improve, and it's a constant battle to settle on a solution. That's where LLMs help the most, in my opinion. Still, it would be useful to hear what people in the field think could be better here.

If you have thoughts, let me know personally or in the comments.

This is post 2 of a short series on the tech behind Quldra, a post-quantum single-device messenger built in Kotlin Multiplatform. Previous post was on My road to ML-KEM-768 over X25519 for my messaging app.

My road to ML-KEM-768 over X25519 for my messaging app

Martin Kambla — Tue, 28 Apr 2026 19:18:04 +0000

Eight months ago I started working on a messaging app as an hobby to see how difficult it is. One thing led to another and then I was obsessed with the idea of having it Post-quantum ready. It is well known that Signal works in that regard but from my perspective it isn't full E2EE. Boiling it down to small stuff - why I chose ML-KEM-768 instead of X25519.

The "harvest now, decrypt later" problem

X25519 is an elliptic curve Diffie-Hellman on Curve25519. Its security rests on the discrete log problem being hard. It is, today, on classical hardware.

A sufficiently large quantum computer running Shor's algorithm breaks it. Nobody has one yet but the bells are ringing. An adversary who can capture and store your encrypted traffic today can decrypt it the day they do. This is not a theoretical problem for a messaging app - messages sent today are expected to stay private for years, sometimes decades.

Post-quantum key exchange is the hedge. And as of August 2024, NIST has a standard for it: FIPS 203, which specifies ML-KEM (Module Lattice-based Key encapsulation Mechanism), the renamed CRYSTALS-Kyber.

Why 768, not 512 or 1024?

ML-KEM ships in three parameter sets:

Parameter set	Claimed security category	Rough classical equivalent
ML-KEM-512	1	AES-128
ML-KEM-768	3	AES-192
ML-KEM-1024	5	AES-256

768 is the sweet spot most deployed post-quantum systems have converged on. Cloudflare, Chromes hybrid X25519Kyber768, Signal's PQXDH all use the 768 tier. It's the default "safe modern choice" - strong enough that nobody serious argues 512 is sufficient, and light enough that 1024's extra bytes aren't worth the hit unless you're protecting state secrets. In any of the cases you can still leave room for it to be more secure if need be.

The numbers that actually matter

Here's the honest size comparison:

	X25519	ML-KEM-768
Public key	32 bytes	1,184 bytes
Ciphertext / encapsulation	32 bytes	1,088 bytes
Shared secret	32 bytes	32 bytes
Keygen (ms, M1)	~0.02	~0.05
Encap (ms, M1)	~0.04	~0.06
Decap (ms, M1)	~0.04	~0.07

The speed penalty is basically noise on a modern device. The size penalty is real - every session key exchange ships ~2 KB more on the wire than it used to. For a messaging app where most messages are smaller than that, it's a meaningful bump in bandwidth for the first message in the conversation.

I decided I could eat it. A 2KB one-time handshake cost per conversation is fine. A protocol that breaks in ten years is not.

The actual flow

I'm not using ML-KEM to encrypt messages directly - it's a KEM, not a cipher. It gives you a shared secret, and you feed that shared secret into something that can actually encrypt bulk data. In my case, ChaCha20-Poly1305.

sender                                   recipient
  |                                          |
  |  fetch recipient's ML-KEM public key     |
  |----------------------------------------->|
  |                                          |
  |  (encapsulate)                           |
  |    ciphertext, sharedSecret = Encap(pk)  |
  |                                          |
  |  HKDF(sharedSecret, salt=nonce)          |
  |     → 32-byte room key                   |
  |                                          |
  |  ChaCha20-Poly1305(key, nonce, plaintext)|
  |                                          |
  |  send {ciphertext, nonce, AEAD payload}  |
  |----------------------------------------->|
  |                                          |
  |                       sharedSecret = Decap(sk, ciphertext)
  |                       HKDF(...) → same 32-byte key
  |                       ChaCha20-Poly1305 decrypt → plaintext

The Kem output is 32 bytes of raw shared secret. Feeding it straight into ChaCha20 as a key would work but is brittle . you'd be binding the key to the KEM output directly, with no domain separation, no per-message salt, HKDF with a per-message nonce as salt gives you:

Domain separation (same KEM shared secret can produce different keys for different purposes.
A key that rotates every message, even when the underlying KEM secret is reused for a session.
A clean audit story - the cipher sees a fresh 32-byte key each time.

Here's what that looks like in Kotlin, using Bouncy Castle's ML-KEM provider:

fun encryptMessage(
    recipientPublicKey: MLKEMPublicKey,
    plaintext: ByteArray,
    associatedData: ByteArray
): EncryptedEnvelope {
    // 1. Encapsulate to get a ciphertext + shared secret
    val encap = MLKEMEncapsulator(recipientPublicKey).encapsulate()

    // 2. Derive a per-message key via HKDF
    val nonce = SecureRandom().nextBytes(12)
    val messageKey = hkdfSha256(
        ikm = encap.sharedSecret,
        salt = nonce,
        info = "quldra/v3/msg".toByteArray(),
        length = 32
    )

    // 3. Encrypt with ChaCha20-Poly1305
    val cipher = ChaCha20Poly1305()
    cipher.init(true, AEADParameters(KeyParameter(messageKey), 128, nonce, associatedData))
    val output = ByteArray(cipher.getOutputSize(plaintext.size))
    val written = cipher.processBytes(plaintext, 0, plaintext.size, output, 0)
    cipher.doFinal(output, written)

    return EncryptedEnvelope(
        kemCiphertext = encap.ciphertext,  // 1088 bytes, sent once per session
        nonce = nonce,                      // 12 bytes
        aead = output                       // plaintext.size + 16 bytes
    )
}

A few notes on the code above:

'encap_ciphertext' is the big one - 1088 bytes. In my protocol I only send it to on session establishment, not every message. Within a session I use a cached room secret derived from that initial exchange.
'info = "quldra/v3/msg" is the HKDF domain separator. The 'v3' bit matters - when i eventually rotate this (post-quantum standards will evolve), old messages stay decryptable under 'v2'/'v3' code paths and new ones use 'v4'.
Don't reuse nonces. ChaCha20-Poly1305 breaks catastrophically on nonce reuse. I use a 12-byte random nonce, which is safe for around 2^32 messages per key befiore birthday-bound becomes relevant - I rotate the key before that anyway.

The migration gotchas I hit

A few things I didn't expect when I did this swap:

BouncyCastle's ML-KEM API changed between bcprov-jdk18on 1.78 and 1.79. If you pin one, pin both. I lost an afternoon to a deserialisation mismatch.
Keys don't round-trip through toByteArray() on iOS Kotlin/Native. I had to go through the raw encoded format manually. If you're using Kotlin Multiplatform, test serialisation on both platforms early.
Don't hybridise unless you have to. Chrome and Cloudflare use hybrid X25519+ML-KEM-768 as a belt-and-braces move while the post-quantum algorithms are still young. For a new app with no legacy decryption path to maintain, pure ML-KEM-768 is simpler and I'd rather have one thing to audit than two.

Was it worth it?

Honestly — ask me in five years. The whole point of post-quantum is that you can't know today whether the hedge paid off. The question is whether the cost today is acceptable for the protection tomorrow.

For my app, a 2 KB handshake bump and a slightly larger public key registry was acceptable. For yours, it might not be. But if you're starting fresh and "messages I send today should still be private when my daughter is forty" sounds reasonable, ML-KEM-768 is the move.

I'm building Quldra, a post-quantum, single-device messaging app in Kotlin Multiplatform. This is post 1 of a short series on the tech behind it.

My road to ML-KEM-768 over X25519 for my messaging app

Martin Kambla — Tue, 28 Apr 2026 19:18:04 +0000

The "harvest now, decrypt later" problem

X25519 is an elliptic curve Diffie-Hellman on Curve25519. Its security rests on the discrete log problem being hard. It is, today, on classical hardware.

Why 768, not 512 or 1024?

ML-KEM ships in three parameter sets:

Parameter set	Claimed security category	Rough classical equivalent
ML-KEM-512	1	AES-128
ML-KEM-768	3	AES-192
ML-KEM-1024	5	AES-256

The numbers that actually matter

Here's the honest size comparison:

	X25519	ML-KEM-768
Public key	32 bytes	1,184 bytes
Ciphertext / encapsulation	32 bytes	1,088 bytes
Shared secret	32 bytes	32 bytes
Keygen (ms, M1)	~0.02	~0.05
Encap (ms, M1)	~0.04	~0.06
Decap (ms, M1)	~0.04	~0.07

I decided I could eat it. A 2KB one-time handshake cost per conversation is fine. A protocol that breaks in ten years is not.

The actual flow

sender                                   recipient
  |                                          |
  |  fetch recipient's ML-KEM public key     |
  |----------------------------------------->|
  |                                          |
  |  (encapsulate)                           |
  |    ciphertext, sharedSecret = Encap(pk)  |
  |                                          |
  |  HKDF(sharedSecret, salt=nonce)          |
  |     → 32-byte room key                   |
  |                                          |
  |  ChaCha20-Poly1305(key, nonce, plaintext)|
  |                                          |
  |  send {ciphertext, nonce, AEAD payload}  |
  |----------------------------------------->|
  |                                          |
  |                       sharedSecret = Decap(sk, ciphertext)
  |                       HKDF(...) → same 32-byte key
  |                       ChaCha20-Poly1305 decrypt → plaintext

Domain separation (same KEM shared secret can produce different keys for different purposes.
A key that rotates every message, even when the underlying KEM secret is reused for a session.
A clean audit story - the cipher sees a fresh 32-byte key each time.

Here's what that looks like in Kotlin, using Bouncy Castle's ML-KEM provider:

fun encryptMessage(
    recipientPublicKey: MLKEMPublicKey,
    plaintext: ByteArray,
    associatedData: ByteArray
): EncryptedEnvelope {
    // 1. Encapsulate to get a ciphertext + shared secret
    val encap = MLKEMEncapsulator(recipientPublicKey).encapsulate()

    // 2. Derive a per-message key via HKDF
    val nonce = SecureRandom().nextBytes(12)
    val messageKey = hkdfSha256(
        ikm = encap.sharedSecret,
        salt = nonce,
        info = "quldra/v3/msg".toByteArray(),
        length = 32
    )

    // 3. Encrypt with ChaCha20-Poly1305
    val cipher = ChaCha20Poly1305()
    cipher.init(true, AEADParameters(KeyParameter(messageKey), 128, nonce, associatedData))
    val output = ByteArray(cipher.getOutputSize(plaintext.size))
    val written = cipher.processBytes(plaintext, 0, plaintext.size, output, 0)
    cipher.doFinal(output, written)

    return EncryptedEnvelope(
        kemCiphertext = encap.ciphertext,  // 1088 bytes, sent once per session
        nonce = nonce,                      // 12 bytes
        aead = output                       // plaintext.size + 16 bytes
    )
}

A few notes on the code above:

'encap_ciphertext' is the big one - 1088 bytes. In my protocol I only send it to on session establishment, not every message. Within a session I use a cached room secret derived from that initial exchange.
'info = "quldra/v3/msg" is the HKDF domain separator. The 'v3' bit matters - when i eventually rotate this (post-quantum standards will evolve), old messages stay decryptable under 'v2'/'v3' code paths and new ones use 'v4'.
Don't reuse nonces. ChaCha20-Poly1305 breaks catastrophically on nonce reuse. I use a 12-byte random nonce, which is safe for around 2^32 messages per key befiore birthday-bound becomes relevant - I rotate the key before that anyway.

The migration gotchas I hit

A few things I didn't expect when I did this swap:

BouncyCastle's ML-KEM API changed between bcprov-jdk18on 1.78 and 1.79. If you pin one, pin both. I lost an afternoon to a deserialisation mismatch.
Keys don't round-trip through toByteArray() on iOS Kotlin/Native. I had to go through the raw encoded format manually. If you're using Kotlin Multiplatform, test serialisation on both platforms early.
Don't hybridise unless you have to. Chrome and Cloudflare use hybrid X25519+ML-KEM-768 as a belt-and-braces move while the post-quantum algorithms are still young. For a new app with no legacy decryption path to maintain, pure ML-KEM-768 is simpler and I'd rather have one thing to audit than two.

Was it worth it?

I'm building Quldra, a post-quantum, single-device messaging app in Kotlin Multiplatform. This is post 1 of a short series on the tech behind it.

The Vercel leak is a warning shot for agentic coders

Martin Kambla — Mon, 20 Apr 2026 00:04:58 +0000

If you haven't heard, Vercel confirmed they had a security incident on the 19th of April. That hit matters more than the average vendor's bad week, because a great proportion of "LLM whisperers" and vibe coders run their frontend through Vercel.

Vercel state that more than 30% of deployments on its platform are now initiated by coding agents, up 1000% in six months. They also say that projects deployed by coding agents are 20x more likely to call AI inference providers than human-deployed ones. To rephrase: agent-built apps are no longer edge cases, they're a meaningful chunk of modern web shipping.

That scales the leak well past a regular vendor incident.

What Vercel actually said

Per the bulletin, the incident originated from a small third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise. Vercel advised customers to:

Review account activity logs for suspicious behavior.
Audit and rotate any environment variables that may contain secrets — especially ones not marked as sensitive.
Enable the sensitive environment variables feature going forward.

Variables explicitly flagged as sensitive are stored so they can't be read back, and Vercel says it has no evidence those values were accessed. Everything else is fair game for rotation.

That's the actual lesson — the risk is no longer just buggy code. The risk is delegated trust across OAuth apps, agents, CI, hosting, logs, and environment-variable handling.

The shape of the problem was already visible

This isn't a surprise if you'd been reading Vercel's own data. In their earlier post on vibe coding securely, they noted that v0 blocked over 17,000 insecure deployments in July 2025 alone. The recurring themes:

Exposed API keys — Supabase, OpenAI, Gemini, Claude, xAI credentials nearly leaked by the thousand.
NEXT_PUBLIC_ misuse — LLMs confidently shoving database credentials into a prefix that ships straight to the browser by design.
Unauthenticated API routes — generated and deployed without anyone checking who can call them.

Same story, scaled up: fast AI-assisted shipping creates a larger security blast radius unless guardrails are enforced.

What should change

From my perspective, anyone shipping with agents should actually read and follow the OWASP Top 10 for LLM Applications. Not skim. Read.

A few specific shifts:

Mark and isolate sensitive parameters. Credentials, tokens, signing keys — explicitly flag them. We don't need to get overparanoid about agents touching prototype env vars, but the moment a project goes outward-facing, rotate so there isn't a trace of those secrets in development pipelines.

Treat connected third-party tools as production threats. Easier said than done, but human approval for connecting a new OAuth app to your hosting/source/CI should sit higher up than usual. The Vercel incident didn't start with Vercel — it started with a tool someone connected to Vercel.

Keep audit trails for machine actions. Agent sessions, deployments, permission grants — attributable and reviewable. If you can't answer "which agent did this, when, with whose credentials," you don't have a security posture, you have a story.

Bottom line

A lot of the new frontend AI world already routes through Vercel-style deployment patterns, and Vercel's own numbers show how fast that's growing. The fix isn't "stop agentic coding." It's to be more mindful about every connected tool in the project — sooner or later one of them will be compromised, and the question is only whether you find out from your own audit log or from a vendor's bulletin.

Project Glasswing: What Software Companies Should Actually Do in the Next 12 Months

Martin Kambla — Tue, 14 Apr 2026 04:14:56 +0000

Anthropic's Project Glasswing gave limited access to Claude Mythos Preview — a model reportedly able to identify and exploit zero-day vulnerabilities across major operating systems and browsers, including multi-stage exploit chains. Anthropic says more than 99% of the vulnerabilities it found remain unpatched.

That is the data point that matters.

The usual reaction to announcements like this is a philosophical debate about how many of those bugs were already known to someone and just unreported. That is a rabbit hole not worth digging. Assume the less flattering answer - act on that.

Software will not suddenly stop working. Codebases are not worthless. Nobody has to rewrite everything next quarter.

What changed is the economics of offense.

What actually got cheaper

A model like Mythos does not need to invent new classes of vulnerabilities to cause disruption. It only needs to reduce the skill, time, and cost required to find real bugs, weaponize them, and chain them together.

Anthropic explicitly warns that defenses whose main value is friction rather than a hard barrier will erode against model-assisted attackers, because models can grind through tedious exploit-development work at scale.

An example of what "friction" means in practice: a stripped closed-source binary that used to cost a specialist a weekend of reverse engineering to map. A heap-grooming sequence only one in ten offensive researchers could reliably land. A logic bug buried three layers deep in a state machine nobody wanted to audit by hand.

That kind of work compresses.

Mythos reportedly found memory-corruption bugs, logic bugs, cryptographic implementation weaknesses, browser exploit chains, and vulnerabilities inside closed-source binaries via reverse engineering. Five bug classes. One pipeline.

The short version:

exploit development gets faster
exploit chaining gets easier
reverse engineering gets cheaper
patch windows get more dangerous
"annoying but probably fine" exposures get less fine

What software companies should actually do

Most writing about AI risk becomes either philosophy or panic. Neither is operationally useful. Here is the triage.

1. Build an honest asset inventory

Not a compliance spreadsheet. An actual map: what is internet-facing, what runs with elevated privilege, what is written in memory-unsafe languages, what parses untrusted input, what sits before authentication, what cannot be patched quickly, what third-party components quietly expand the attack surface.

Without this, you are not doing prioritization. You are doing vibes.

2. Split the estate into rewrite, isolate, monitor

Rewrite: high-risk parsers, security-critical low-level services, old C/C++ components exposed to hostile input, brittle auth or crypto-adjacent implementations.

Isolate: legacy services you cannot replace in 12 months, components with known rough edges and clear business dependency, anything that can be boxed into stricter privilege boundaries, seccomp profiles, sandboxes, or service segmentation.

Monitor: lower-risk business logic, standard SaaS code in managed runtimes, internal tooling with constrained exposure.

The point most teams miss: the right response to Mythos is not "rewrite everything." It is "be much more honest about what deserves rewriting first."

3. Make patch latency an executive KPI

If 99% of Mythos-found vulnerabilities remain unpatched, the bottleneck is not discovery. It is organizational response speed.

The question is no longer could someone find this bug? It is could we fix, validate, and deploy the patch before someone industrializes it?

Patch velocity is now a business capability. Not just a security metric.

4. Discount "attacker effort" in your severity model

A vulnerability that used to be dismissed as "the exploit path is too tedious" is more dangerous than it looked six months ago. A chain that used to require an unusually strong offensive researcher may increasingly be available to a competent operator with a good model and enough compute.

That does not mean every bug is suddenly critical. It does mean your severity rubric should stop leaning on attacker inconvenience as a mitigation.

5. Default new security-critical code to memory-safe stacks

Not ideology. Risk concentration. You do not need to rewrite mature systems tomorrow. You should probably stop creating fresh long-term exposure in exactly the places where a language choice removes entire bug classes.

6. Add model-assisted workflows to defense now

Anthropic's own framing is that the long-run equilibrium may still favor defenders — the way fuzzers eventually did — but the transitional period favors attackers if defenders are slower to adapt.

That means AI-assisted code review, exploitability analysis, dependency triage, fuzzing and testcase generation, and regression verification after patches.

If offense becomes automated while defense stays ticket-driven and manual, the gap widens fast.

7. Stop treating architecture as separate from security

The companies that look smartest in 18 months will not be the ones that wrote the most urgent memos.

They will be the ones that quietly reduced blast radius.

Least privilege, segmentation, sandboxing, narrow interfaces, ephemeral credentials, isolated parsers, fast rollback paths. All of those become more valuable when exploit development gets cheaper.

The real question

Mythos does not mean software companies need to rewrite everything.

It means they have to stop pretending their backlog is neutral.

A lot of organizations have accumulated technical debt under the quiet assumption that the exploit-development bottleneck was mostly on the attacker side. That assumption is weakening.

What used to be "we should clean this up eventually" is increasingly "this is a compounding liability."

The next 12 months are not about panic. They are about sorting your projects into three buckets:

things you can still safely defer
things you must isolate now
things you should never have built that way again

Not "do we rewrite everything?"

But "which parts of our system can no longer rely on attacker friction to stay safe?"

That is a much better executive question.

And a much more expensive one to answer late.

The Commoditization Thesis: What Actually Happens When Software Gets Easy

Martin Kambla — Wed, 08 Apr 2026 01:03:48 +0000

The data is clear on what’s already happening.

Labor’s share of GDP fell to 53.8% in Q3 2025 — the lowest in the modern BLS series back to 1947. Capital is eating labor’s lunch, and AI is accelerating it.
Entry-level pressure is already visible: Stanford’s Digital Economy Lab found declines concentrated among 22–25 year-old workers in AI-exposed jobs such as software development, customer service, and clerical work.
The narrower BLS category of computer programmers is projected to decline 6% through 2034, even while broader software development roles still grow. That distinction matters: implementation-heavy work gets pressured first.
Meanwhile, workers with AI skills command meaningful wage premiums. PwC found an average 56% wage premium for workers with AI skills in 2024, and other labor-market reporting showed premiums up to 43% for jobs listing multiple AI skills.
Tech salary growth slowed to 1.6% in 2025, down from 3.5% in 2023.

This is not speculation. The compression is measurable.

Historical pattern — this has happened before, twice

Web development (late 90s → 2008): Developers charged premium rates to technically naive clients. WordPress, Squarespace, and frameworks killed the implementation premium. Value migrated to architecture, product strategy, integration.

Mobile apps (2008 → mid-2010s): App Store gold rush → React Native / Flutter commoditized a large chunk of standalone app building. Same outcome: implementation became cheaper, judgment became more expensive.

The arc is usually the same: scarcity premium → tool-driven commoditization → value migrates upward to domain expertise, architecture, integration, and judgment.

Historically, that took 5–8 years. AI appears to be compressing the cycle closer to 2–3 years.

What the capital side of this looks like

Piketty’s r > g framework feels increasingly visible in current data.

The S&P 500 is dramatically above its January 2023 level.
AI captured close to 50% of all global venture funding in 2025, with roughly $202.3B invested across infrastructure, foundation labs, and applications.
McKinsey has explicitly warned that when real estate and equity values rise faster than GDP, capital can get pulled toward asset inflation and repurchases rather than the kinds of investment that generate broad long-run growth.

Labor income alone is becoming a weaker wealth-building vehicle. The gap between returns on capital and returns on labor is widening, not narrowing. For someone starting from near-zero capital, that is the fundamental challenge.

The critical prediction for 2026–2030

Middle-class software developer income will likely bifurcate.

Bottom 60% of current developers: real income stagnation or decline. Implementation work commoditizes.
Top 20%: premium widens. Architecture, security, compliance, domain-specific systems, AI integration, and judgment-heavy work become more valuable.
The gap between these groups likely widens through at least 2030.

Not because software disappears.

Because undifferentiated software work gets repriced downward, while the value of high-context, high-trust, high-complexity work rises by contrast.

The uncomfortable truth

Software commoditization means the floor rises — more people can build — but the ceiling also rises. Complex integration, security, compliance, architecture, and domain-specific work become more valuable precisely because raw implementation gets cheaper.

That usually hollows out the middle.

The real risk is getting distracted by opportunities that look easier, when in practice they are just more crowded.

I scanned 8 popular npm projects for quantum-vulnerable cryptography. Here's what I found.

Martin Kambla — Wed, 01 Apr 2026 15:25:03 +0000

This week Google published a paper that changed the post-quantum timeline. Breaking ECDSA-256 — the signature scheme protecting Bitcoin, Ethereum, and most of the web — now requires roughly 1,200 logical qubits and under 500,000 physical qubits. That's a 20x reduction from previous estimates.

I wanted to answer a simple question: how exposed are the projects we all depend on?

So I built pqaudit, an open-source CLI that scans source code and npm dependencies for quantum-vulnerable cryptography — algorithms broken by Shor's algorithm (RSA, ECDSA, Ed25519, ECDH, Diffie-Hellman) and weakened by Grover's algorithm (AES-128) — and flags the NIST-approved replacement for each one.

Then I pointed it at 8 popular projects.

The results

Project	Files	Critical	High	PQC Ready
Express	142	0	0	Yes
Fastify	295	1	0	No
Next.js	22,478	17	1	No
Prisma	3,291	0	0	Yes
jsonwebtoken	65	21	0	No
Solana web3.js	104	17	0	No
Ethereum web3.js	1,194	12	3	No
Signal Desktop	2,854	12	0	No

30,423 files scanned. 6 of 8 are not quantum-ready.

Let me walk through the interesting ones.

jsonwebtoken: 21 critical findings in 65 files

This one hit hardest. node-jsonwebtoken is the most popular JWT library on npm — and it's fundamentally built on quantum-vulnerable algorithms.

[!!] RSA — RS256, RS384, RS512, PS256, PS384, PS512
     sign.js, verify.js, lib/validateAsymmetricKey.js
     Fix: ML-DSA-65 (FIPS 204)

[!!] ECDSA — ES256, ES384, ES512
     lib/validateAsymmetricKey.js
     Fix: ML-DSA-65 (FIPS 204)

Every signing algorithm the library supports — RS256, ES256, and their variants — is broken by Shor's algorithm. If your app uses JWTs for authentication (and most Node.js apps do), your auth tokens are signed with quantum-vulnerable cryptography.

There's no PQC JWT standard yet. The IETF is working on it, but it doesn't exist today. This is a systemic gap in the entire web ecosystem.

Solana web3.js: Ed25519 everywhere

Solana's entire identity and transaction model is built on Ed25519:

[!!] Ed25519 — src/account.ts, src/keypair.ts, src/transaction/legacy.ts
     Fix: ML-DSA-65 (FIPS 204) — blocked by Solana protocol

17 critical findings across 104 files. Every account, every keypair, every transaction signature depends on an algorithm that Shor's breaks. The secp256k1 program (for Ethereum compatibility) adds more.

The migration path exists — ML-DSA-65 is the NIST replacement — but it requires a protocol-level upgrade across the entire Solana network. This isn't something you can fix in your app.

Next.js: 17 critical findings (but it's not what you think)

Next.js has 17 critical findings across 22,478 files. Sounds bad, but the nuance matters — every single finding is in vendored bundles, not in Next.js source code:

crypto-browserify bundled in packages/next/src/compiled/ contains RSA, ECDSA, Ed25519, ECDH, and Diffie-Hellman polyfills
jsonwebtoken compiled into the same directory
constants-browserify exposes RSA padding and ECDSA engine constants

Next.js doesn't use quantum-vulnerable crypto itself. But it ships it to every application that depends on it, through vendored dependencies. This is a supply-chain problem.

Signal Desktop: the only one migrating

Signal Desktop had 12 critical findings (X25519 key exchange, ECDSA), but it's also the only project in this scan that has active PQC adoption. pqaudit detected ML-KEM (Kyber) usage through @signalapp/libsignal-client — Signal's implementation of the PQXDH protocol.

Signal is ahead. Everyone else is at zero.

Express and Prisma: PQC ready

Express and Prisma both passed with zero critical findings. The pattern is clear — frameworks that delegate cryptography to the runtime or database layer don't have this problem. The vulnerability lives in libraries that implement or wrap cryptographic primitives directly.

What breaks and what doesn't

Not all cryptography is quantum-vulnerable. Here's the split:

Broken by Shor's algorithm (must migrate):

RSA (any key size) — key exchange and signatures
ECDSA, Ed25519, EdDSA — signatures
ECDH, X25519, Diffie-Hellman — key exchange
DSA — signatures

Weakened by Grover's algorithm:

AES-128 — reduced to 64-bit effective security. Fix: use AES-256.

Already quantum-safe (no action needed):

AES-256, ChaCha20-Poly1305 — symmetric encryption
SHA-256, SHA-3 — hashing
ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+) — the NIST PQC standards

Why this matters now

You might think quantum computers are far away. Google's paper says otherwise. And even before a quantum computer exists, "harvest now, decrypt later" attacks mean adversaries are collecting your encrypted traffic today for future decryption.

The NSA's CNSA 2.0 mandates PQC for new national security systems by January 2027. Google has set a 2029 deadline for its own products. NIST finalized the standards (FIPS 203, 204, 205) in August 2024.

The migration window is open. The first step is visibility — knowing where quantum-vulnerable cryptography lives in your stack.

Try it

npx pqaudit .

One command, no signup, no config. It scans your source code and npm dependencies, classifies findings by severity, and tells you the NIST-approved replacement for each one.

Outputs: human-readable text, JSON, CycloneDX CBOM, or SARIF for GitHub Code Scanning.

For CI/CD:

npx pqaudit . --ci --format sarif --output pqaudit.sarif

It's MIT licensed and on GitHub. Issues and contributions welcome — especially detection rules for languages beyond JavaScript/TypeScript.

Full results

The detailed scan data for all 8 projects is published at pqcworld.com/scan-results.html.