Client-Side Encryption in Java: Trust No One

I get into the same argument with security auditors about twice a year. It usually starts when they ask if our data is “encrypted at rest.” I say yes, the cloud provider handles that. They check a box on their clipboard. Everyone smiles.

But here’s the thing that keeps me up at night: “Encrypted at rest” usually just means the hard drive in the data center is encrypted. The database engine, the object storage service, and anyone with admin access to the cloud console? They see plaintext. If you actually care about privacy—or if you’re dealing with sensitive PII that you legally can’t expose—that checkbox is worthless.

The only way to be safe is client-side encryption. You encrypt the bytes in your Java application before they ever touch the network. The cloud provider stores a blob of noise. They can’t read it. The government can’t read it. Only you can read it.

I’ve spent the last few weeks refactoring a massive document upload service to move from server-side trust to client-side verification. It’s messy, the Java Cryptography Architecture (JCA) APIs are ancient, and if you hold the Cipher object wrong, it cuts you. But it’s necessary.

The GCM Standard

First rule: Don’t use AES-ECB. If I see Cipher.getInstance("AES") in a code review, I reject it immediately. That defaults to ECB mode in many JDKs, which preserves patterns in the data. It’s garbage.

We want AES-GCM (Galois/Counter Mode). It provides confidentiality and integrity. If someone tampers with your encrypted blob on the storage server, the decryption will throw an exception instead of returning garbage data. This is authenticated encryption, and it’s non-negotiable for modern apps.

Here is the basic setup. You need a 256-bit key and a unique Initialization Vector (IV) for every single file.

import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import java.security.SecureRandom;

public class CryptoBasics {
    private static final int GCM_TAG_LENGTH = 128; // bits
    private static final int IV_LENGTH = 12; // bytes, standard for GCM

    public byte[] encrypt(byte[] plaintext, SecretKey key) throws Exception {
        // 1. Generate a random IV. NEVER reuse an IV with the same key.
        byte[] iv = new byte[IV_LENGTH];
        new SecureRandom().nextBytes(iv);

        // 2. Initialize Cipher
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        GCMParameterSpec spec = new GCMParameterSpec(GCM_TAG_LENGTH, iv);
        cipher.init(Cipher.ENCRYPT_MODE, key, spec);

        // 3. Encrypt
        byte[] ciphertext = cipher.doFinal(plaintext);

        // 4. Prepend IV to ciphertext (you need it for decryption)
        byte[] output = new byte[iv.length + ciphertext.length];
        System.arraycopy(iv, 0, output, 0, iv.length);
        System.arraycopy(ciphertext, 0, output, iv.length, ciphertext.length);
        
        return output;
    }
}

Simple enough for small strings, right? But here’s where real life hits you. You aren’t encrypting strings. You’re uploading 5GB video files or massive CSV dumps to Azure Blob Storage or S3. You can’t load that into a byte[] array unless you want your heap to explode.

Streaming Encryption (The Tricky Part)

Java provides CipherOutputStream, which sounds like the solution. It wraps an output stream and encrypts data as you write to it. But combining CipherOutputStream with AES-GCM is historically… quirky. GCM needs to calculate an auth tag over the entire data stream, which gets appended at the end.

If your upload fails halfway through, you have a partial blob that looks encrypted but lacks the integrity tag. That’s actually fine—it just won’t decrypt. The bigger issue is buffering. The JCA needs to process blocks.

Here is how I handle streaming uploads to a cloud provider. I use a “Pass-Through” stream approach. We wrap the file stream in a cipher stream, and then pipe that to the cloud SDK’s upload method.

import javax.crypto.Cipher;
import javax.crypto.CipherInputStream;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import java.io.InputStream;
import java.io.OutputStream;
import java.security.SecureRandom;

public void uploadEncryptedStream(InputStream rawData, OutputStream cloudUploadStream, SecretKey key) throws Exception {
    
    // 1. Generate IV
    byte[] iv = new byte[12];
    new SecureRandom().nextBytes(iv);

    // 2. Write the IV to the start of the cloud stream FIRST
    // The decryptor needs to read this first to know how to decrypt the rest
    cloudUploadStream.write(iv);

    // 3. Configure Cipher
    Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
    GCMParameterSpec spec = new GCMParameterSpec(128, iv);
    cipher.init(Cipher.ENCRYPT_MODE, key, spec);

    // 4. Stream the encryption
    // We wrap the raw data in a CipherInputStream. 
    // As the cloud SDK reads from this stream, it pulls data, encrypts it, and sends it up.
    try (CipherInputStream cis = new CipherInputStream(rawData, cipher)) {
        // Standard Java 9+ transferTo, or use a buffer loop for older Java
        cis.transferTo(cloudUploadStream); 
    }
    
    // NOTE: CipherInputStream swallows exceptions in some older JDK versions.
    // Always check your JDK release notes. In 2026, on JDK 21+, we are mostly safe.
}

This approach is memory efficient. You are never holding the full file in RAM. You’re just a pipe.

The Envelope Pattern: Or, “Where do I put the key?”

If you hardcode a static SecretKey in your application properties, you’ve just moved the security hole from the database to your config file. Plus, if you ever need to rotate that key, you have to re-encrypt petabytes of data. Nightmare fuel.

The industry standard solution—and what SDKs like the Azure Encryption Client do under the hood—is Envelope Encryption. It works like this:

1. Master Key (KEK): You have one master key stored in a Key Vault (KMS, Azure Key Vault, etc.). It never leaves the hardware security module.
2. Data Key (DEK): For every single file you upload, you generate a brand new, random AES key in memory.
3. Encryption: You encrypt the file with the DEK.
4. Wrapping: You ask the Key Vault to encrypt your DEK using the Master Key.
5. Storage: You save the encrypted file and the encrypted DEK (metadata) together in the storage blob.

This sounds complicated, but it decouples your data from your master key. To rotate keys, you just re-encrypt the DEKs, not the massive files. Here is a rough sketch of how that logic flows in Java:

import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import java.util.Base64;
import java.util.HashMap;
import java.util.Map;

public class EnvelopeEncryption {

    public void uploadWithEnvelope(InputStream data, String blobName) throws Exception {
        // 1. Generate a ephemeral key for this specific file (DEK)
        KeyGenerator keyGen = KeyGenerator.getInstance("AES");
        keyGen.init(256);
        SecretKey dek = keyGen.generateKey();

        // 2. Encrypt the DEK using your Key Management Service (Mocked here)
        // In reality: keyVaultClient.encrypt(masterKeyId, dek.getEncoded())
        byte[] wrappedDek = myKeyVaultClient.wrapKey(dek.getEncoded());

        // 3. Prepare Metadata
        Map<String, String> metadata = new HashMap<>();
        metadata.put("encryption_mode", "AES/GCM/NoPadding");
        metadata.put("wrapped_key", Base64.getEncoder().encodeToString(wrappedDek));
        metadata.put("iv", "..."); // Don't forget to store the IV too!

        // 4. Upload
        // Pass the 'dek' to the streaming encryption method we wrote earlier
        // Pass 'metadata' to the cloud provider's metadata fields
        cloudStorage.upload(blobName, data, dek, metadata);
    }
}

Why I Don’t Trust “Transparent” Solutions

I recently looked at a project where the team used a database driver that promised “transparent client-side encryption.” It worked, until it didn’t. They ran into a version mismatch between the driver and the JVM’s crypto policy, and suddenly production was down because the app couldn’t handshake with the DB.

When you own the crypto code—using standard javax.crypto—you know exactly what’s happening. You know that you aren’t reusing IVs (a fatal flaw in GCM). You know you aren’t using a weak key derivation function. You aren’t relying on a black box that might be deprecated in the next SDK release.

Yes, libraries like the Azure Storage Encryption SDK or the AWS Encryption SDK are great. I use them. They handle the envelope stuff for you. But you need to understand what they are doing. If you don’t understand why they are requesting a Key Vault permission, or why the metadata has a field called “encryptiondata”, you’re flying blind.

One last tip: Performance. Encryption is CPU intensive. AES-NI instructions on modern CPUs help a lot, but if you are doing this in Java, make sure you aren’t creating a new SecureRandom instance for every single method call. It blocks. It waits for entropy. Instantiate it once, or use ThreadLocal if you’re paranoid about contention.

Cryptography in Java isn’t magic. It’s just a pipeline. Get your bytes, lock them up, throw away the key (after wrapping it), and sleep better knowing that when—not if—the storage bucket leaks, all the hackers get is static.