Side-Channel Attacks: The Threat That Bypasses Encryption

When people talk about breaking encryption, they usually mean one of two things: finding a mathematical weakness in the algorithm, or brute-forcing through key space. Both are extraordinarily difficult with well-designed modern ciphers. AES-256 with a properly generated key isn't getting cracked by attacking the algorithm itself — not now, probably not ever.

Side-channel attacks take a completely different approach. They don't care about the algorithm's math. They observe what happens when that math runs on real hardware — the time it takes, the cache lines it touches, the electromagnetic radiation it emits — and use those observations to infer secret information. A perfect cipher implemented in imperfect code can be devastatingly vulnerable.

Timing Attacks: When Speed Betrays Secrets

The simplest side channel to understand is time. Many cryptographic operations take different amounts of time depending on the values they're operating on. An RSA private-key operation, for instance, involves modular exponentiation — and naive implementations process bits differently depending on whether they're 0 or 1. Measure enough operations, and patterns in timing reveal bits of the private key.

Password comparison is a more practical example. The wrong way to compare a password hash:

if stored_hash == submitted_hash:
    grant_access()

A string comparison returns false as soon as it finds the first mismatched character. An attacker who can measure response times with enough precision can guess the hash character by character, because a guess that matches the first byte takes slightly longer than one that doesn't. This isn't theoretical — timing attacks on naive password comparison implementations have been demonstrated in practice.

The fix is a constant-time comparison function — one that always examines every character regardless of where the first mismatch occurs. Most cryptographic libraries provide these. The problem is that developers who aren't thinking about side channels often roll their own comparisons without knowing this is necessary.

Cache Attacks: Spectre, Meltdown, and What They Actually Mean

The 2018 Spectre and Meltdown disclosures introduced most of the public to cache-based side-channel attacks. These vulnerabilities exploited a feature called speculative execution — a performance optimization where modern processors execute instructions ahead of time, guessing which branch a conditional will take, and then discarding the results if the guess was wrong.

The problem is that "discarding" a speculative result doesn't undo its side effects on the CPU cache. An attacker can craft code that causes the processor to speculatively access memory it shouldn't be able to read — like another process's memory, or kernel memory — and then measure cache timing to infer what was accessed. The content of the memory location leaks through the cache timing even though the speculative access was rolled back.

Spectre, specifically, affects the fundamental design assumption that different software processes are isolated from each other on shared hardware. This matters in cloud environments: virtual machines on the same physical host share hardware, and a Spectre-like attack on a shared CPU could, in principle, let one VM read memory from another. Cloud providers responded by adding mitigations, but the trade-off was performance — some workloads took measurable speed hits from the required software patches.

Spectre variants continue to be discovered. The fundamental problem — that modern CPU performance optimizations create information channels between processes — hasn't been resolved. It's been mitigated, at cost.

Power Analysis and Electromagnetic Attacks

In hardware security research, the most powerful side-channel attacks don't require network access at all. Power analysis attacks measure the electrical current a device draws during cryptographic operations. Simple Power Analysis (SPA) looks at a single power trace and tries to identify the operations being performed. Differential Power Analysis (DPA) collects many traces and uses statistical methods to extract key material.

DPA attacks on smart cards and hardware security modules have been documented extensively in academic literature going back to Paul Kocher's 1999 paper. A well-equipped attacker with physical access to a device and the right oscilloscope can extract AES keys from unprotected hardware implementations by analyzing power traces from a few hundred operations. Hardware security token manufacturers have spent enormous engineering effort on countermeasures: randomizing operations, adding noise sources, designing circuits that consume constant power regardless of the data being processed.

Electromagnetic (EM) attacks are closely related — instead of tapping a power rail, the attacker positions an EM probe near the target device. The advantage is that EM attacks sometimes don't require physical connection to the device, only proximity. Researchers have demonstrated recovery of cryptographic keys from a laptop via EM analysis at distances of a few centimeters.

Attack Type	What It Measures	Physical Access Required	Practical Threat Level
Timing	Operation duration	Network access sufficient	High (software-level)
Cache (Spectre/Flush+Reload)	Cache hit/miss patterns	Code execution on same host	High (cloud/shared hardware)
Power Analysis	Current draw	Physical (power rail tap)	High for hardware devices
Electromagnetic	EM emissions	Near-proximity	Medium (specialized attacker)
Acoustic	Sound from CPU/fans	Near-proximity or microphone	Low (demonstrated in lab)

What This Means for the Software and Apps You Use

Side-channel vulnerabilities live in the implementation layer, not the algorithm layer. This means the relevant question isn't just "does this app use AES-256?" but "has its cryptographic implementation been audited for constant-time behavior?"

Well-maintained cryptographic libraries like libsodium, BoringSSL, and OpenSSL have been extensively reviewed for timing side channels and use constant-time implementations for sensitive operations. The risk goes up when developers:

• Implement cryptographic primitives from scratch instead of using a vetted library
• Use general-purpose comparison functions (like == or strcmp) on secret values
• Write code that branches on secret data, creating timing differences that depend on key bits
• Use interpreted languages where constant-time guarantees are especially hard to provide

The forward secrecy properties of a protocol are also relevant here — if an attacker records encrypted traffic and later recovers a long-term key via a side-channel attack, forward secrecy ensures that recorded traffic can't be retroactively decrypted.

Mitigations: What Actually Works

Defenses against side-channel attacks operate at multiple levels:

Algorithm and library level: Use well-audited cryptographic libraries that explicitly guarantee constant-time behavior for secret-dependent operations. libsodium is a good default choice for application developers — it was designed from the start with these properties in mind. Never implement your own AES, RSA, or elliptic curve operations.

Hardware level: Modern processors include hardware mitigations for known Spectre variants. Operating system kernels have implemented mitigations like KPTI (Kernel Page Table Isolation) and Retpoline-based indirect branch speculation controls. These reduce but don't eliminate the attack surface, and new variants continue to emerge.

Isolation: Process isolation, sandboxing, and site isolation in browsers limit what a malicious page or process can observe about others. Browser vendors have reduced timer precision specifically to make cache timing attacks harder to execute from JavaScript.

Hardware security modules: Purpose-built cryptographic hardware (HSMs, smart cards, secure enclaves like Apple's Secure Enclave or Android's StrongBox) implement physical countermeasures against power and electromagnetic analysis. These are significantly harder to attack than general-purpose CPUs running software implementations.

The underlying lesson is that encryption and privacy aren't synonymous, and a cryptographic guarantee doesn't automatically translate into a security guarantee. The implementation matters as much as the algorithm — sometimes more.

What This Means for Encrypted Messaging

For encrypted messaging applications, side-channel concerns show up in a few concrete places. Key generation must use a cryptographically secure random number generator — predictable randomness is a side channel in itself, though usually classified separately as a random number generation failure. Key storage in hardware-backed keystores (Android Keystore, iOS Secure Enclave) takes key material off the general-purpose CPU, providing significant protection against software-layer cache attacks.

The protocols themselves — Signal Protocol, MLS — are implemented in vetted libraries that have been reviewed for constant-time behavior. The more dangerous surface is application code that handles key material carelessly: logging it, comparing it with non-constant-time functions, or passing it through memory that's later accessible to other code.

Haven stores private key material in the platform's secure keystore and uses libsodium-derived primitives through the Rust cryptographic layer. Like any implementation, it hasn't been formally verified against all possible side channels, and independent security audits should always be part of how you evaluate any security tool you depend on.