Trust But Verify? Nah. Breaking rPGP's Integrity Checks

OpenPGP is the cockroach of the cryptographic world. It predates modern authenticated encryption (AEAD) by decades, surviving through a patchwork of backward compatibility and 'good enough' fixes. One of those fixes was the Modification Detection Code (MDC)—a desperate attempt to stop attackers from tampering with encrypted messages. Before MDC, OpenPGP used malleable encryption (like CAST5 or AES in CFB mode), meaning if I flipped a bit in your ciphertext, I could predictably flip a bit in your plaintext. Scary stuff.

Enter rPGP, a pure Rust implementation of OpenPGP. Rust is the golden child of security, promising memory safety and concurrency without data races. But here's the kicker: Rust protects you from buffer overflows, not from logic errors. GHSA-C7PH-F7JM-XV4W is exactly that—a logic bug where the library decided that checking the integrity of a message was strictly optional.

Researchers from ETH Zurich discovered that rPGP would sometimes happily decrypt and return a message even if the MDC was missing, malformed, or invalid. This turns a modern secure messenger (like Delta Chat, which uses rPGP) into a 1990s-era pager that blindly trusts whatever garbage comes over the wire.

To understand why this breaks everything, you have to understand the Symmetrically Encrypted Integrity Protected (SEIP) packet (Tag 18). In the OpenPGP standard (RFC 4880), SEIP wraps the actual data and appends a SHA-1 hash (the MDC) at the end. The decryption process is supposed to look like this:

1. Decrypt the data stream.
2. Parse the MDC packet at the end.
3. Hash the plaintext and compare it to the MDC.
4. CRITICAL: If they don't match, burn the plaintext and throw an error.

rPGP failed at step 4. In specific edge cases, the parser would encounter an issue or simply reach the end of the stream and return the decrypted data before confirming the MDC was valid. This effectively downgraded the encryption from 'Authenticated' to 'Malleable'.

When encryption is malleable (specifically in CFB mode, which OpenPGP uses), an attacker can manipulate the ciphertext to introduce errors in the plaintext. While they can't decrypt the message themselves, they can corrupt it. Without an integrity check, the application receives this corrupted data as if it were legitimate. This is the foundation of the 'In-Band Signaling' attack described by the researchers.

The vulnerability lies in the separation between decrypting the stream and verifying the stream. In a robust implementation, these two actions must be atomic—you do not yield data until you verify it. The rPGP implementation, prior to version 0.11.0, allowed a disconnect.

Below is a conceptual simplification of the flaw. The iterator processing the packet stream would yield the content of the SEIP packet effectively 'lazily'. If the stream ended abruptly or the MDC packet was malformed, the error might be logged or raised, but the consumer of the library might have already processed the partial/corrupted plaintext.

// CONCEPTUAL VULNERABLE LOGIC
// The library might yield decrypted chunks before final validation
fn decrypt_packet(packet: EncryptedPacket) -> Result<Vec<u8>, Error> {
    let mut plaintext = Vec::new();
    // ... decryption loop ...
    
    // The flaw: If the MDC is missing or the loop breaks early,
    // the function might return what it has instead of a hard error.
    if mdc_check_failed {
        // In some paths, this was ignored or treated as a soft warning
        // allowing the caller to access 'plaintext'.
    }
    
    Ok(plaintext)
}

The fix in v0.11.0 enforces a strict check. The library now ensures that the MDC packet is present and valid before considering the decryption successful. It moves the implementation closer to a 'Release-Unverified' prohibition, ensuring that if the integrity check fails, the data is treated as radioactive waste.

How do you weaponize a missing checksum? You use the application against itself. The ETH Zurich researchers demonstrated an In-Band Signaling (IBS) attack against Delta Chat. Since rPGP didn't stop modified ciphertexts, an attacker (Alice) could intercept a message to Bob and inject a 'signal'.

Here is the attack flow:

1. ** interception**: The attacker captures an encrypted email.
2. Manipulation: The attacker bit-flips the ciphertext. In AES-CFB, flipping a bit in block N scrambles block N (garbage) but flips the specific bit in block N+1.
3. Injection: The attacker constructs a modification that turns a harmless message into one containing a hidden command or tag (e.g., an HTML image tag loading a remote URL).
4. Bypass: rPGP decrypts the message. The MDC check fails (or is skipped), but the library returns the modified plaintext anyway.
5. Exfiltration: The email client renders the HTML. The invisible image tag loads from the attacker's server, confirming the victim read the message and potentially leaking IP addresses or other metadata.

This bypasses the fundamental promise of cryptography: "If you touch the message, I will know, and I will reject it."

The immediate fix is simple: Upgrade rPGP to version 0.11.0. This version introduces strict MDC verification logic that refuses to yield plaintext if the integrity check fails.

However, the long-term fix is to stop using 1990s cryptography. The OpenPGP community has finally released RFC 9580 (Crypto Refresh), which officially deprecates the older SEIP mechanism in favor of true AEAD (Authenticated Encryption with Associated Data) modes like OCB, EAX, or GCM. AEAD designs integrate authentication into the encryption process itself, rather than tacking a hash onto the end like a post-it note.

> [!TIP] > For Developers: If you are using rPGP or any OpenPGP library, audit your usage. Do not assume the library handles errors safely by default. Explicitly check for verification success types in your code.

For users of Delta Chat, verify you are running version 1.44 or later. If you are building on top of pgp crate, check your Cargo.lock immediately.