feat: request-time data encryption

[infiniteregrets]

No description provided.

[greptile-apps]

Greptile Summary

This PR adds request-time data encryption to the S2 stream store, supporting AEGIS-256 and AES-256-GCM. Records are encrypted on append (via the s2-encryption HTTP header) and decrypted on read, with the stream ID used as AEAD additional data to bind ciphertext to its stream. The SDK injects the encryption header per append/read request only — not as a shared default header — which resolves the concern from the prior review thread. Command records are never encrypted by design. The cryptographic implementation, nonce handling, and key zeroization are solid.

Confidence Score: 5/5

Safe to merge; all remaining findings are P2 style suggestions that do not affect correctness or security.

The cryptographic implementation is solid: random nonces, stream-scoped AAD, correct zeroization on error paths, and per-request (not global) header injection. The two flagged items are both P2 — a cosmetic over-marking of the 'plain' header as sensitive, and the TUI silently skipping encryption — neither of which affects the encryption correctness or security of the core append/read paths.

cli/src/tui/app.rs (encryption not surfaced to users of encrypted streams) and common/src/encryption.rs (plain header sensitivity flag)

Important Files Changed

Filename	Overview
common/src/record/encryption.rs	New file: per-record AEAD with random nonces, stream_id AAD binding, and a post-decryption metered_size integrity check; both AEGIS-256 and AES-256-GCM paths are well-tested
common/src/encryption.rs	Header parsing and key handling with correct zeroization; plain header value is marked sensitive unnecessarily (P2)
lite/src/handlers/v1/records.rs	Encryption injected correctly per append/read request; stream_id used as AAD; all three protocol variants (unary, SSE, S2s) handled
api/src/v1/stream/extract.rs	Missing encryption header defaults to EncryptionConfig::Plain via unwrap_or_default(); encryption propagated to all read and append variants
sdk/src/api.rs	Encryption header injected per-request via set_encryption_header on append/read paths only — not in default_headers — resolving the previously noted concern
cli/src/tui/app.rs	TUI hardcodes None for encryption across all three read call sites; users of encrypted streams will see opaque decryption errors in the TUI
cli/src/main.rs	resolve_encryption correctly handles both --encryption flag and --encryption-file; encryption passed as Option<&EncryptionConfig> to all stream ops
cli/src/cli.rs	EncryptionArgs flattened into AppendArgs, ReadArgs, TailArgs; --encryption and --encryption-file are mutually exclusive via conflicts_with

Sequence Diagram

sequenceDiagram
    participant Client
    participant SDK
    participant Server
    participant KV

    Note over Client,KV: Append (encrypted)
    Client->>SDK: append(records, EncryptionConfig::Aegis256(key))
    SDK->>Server: POST /records [s2-encryption: aegis-256; <key>]
    Server->>Server: parse s2-encryption header → EncryptionConfig
    Server->>Server: encrypt_record(record, config, aad=stream_id)
    Note right of Server: [suite_id‖nonce‖ciphertext‖tag]
    Server->>KV: put(stream_record_data_key, StoredRecord::Encrypted)
    Server-->>SDK: AppendAck
    SDK-->>Client: AppendAck

    Note over Client,KV: Read (decrypt on the fly)
    Client->>SDK: read(start, end, EncryptionConfig::Aegis256(key))
    SDK->>Server: GET /records [s2-encryption: aegis-256; <key>]
    Server->>KV: scan(start_key..end_key)
    KV-->>Server: StoredRecord::Encrypted{metered_size, record}
    Server->>Server: decrypt_payload(record, config, aad=stream_id)
    Server->>Server: verify metered_size matches plaintext
    Server-->>SDK: ReadBatch (plaintext records)
    SDK-->>Client: ReadBatch

    Note over Client,KV: Missing header → plaintext
    Client->>Server: GET /records (no s2-encryption header)
    Server->>Server: unwrap_or_default() → EncryptionConfig::Plain
    Server->>KV: scan(...)
    KV-->>Server: StoredRecord::Plaintext(record)
    Server-->>Client: ReadBatch (plaintext, no decryption)

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: common/src/encryption.rs
Line: 86-98

Comment:
**`plain` header value unnecessarily marked sensitive**

`value.set_sensitive(true)` is called unconditionally, including for the `Plain` variant whose header value is the constant string `"plain"`. This causes any HTTP-logging middleware or debugging tool that respects `HeaderValue::is_sensitive()` to redact a non-secret constant, making it harder to diagnose plaintext-stream issues without any security benefit.

```suggestion
    pub fn to_header_value(&self) -> HeaderValue {
        let mut value = match self {
            Self::Plain => return HeaderValue::from_static("plain"),
            Self::Aegis256(key) => {
                header_value_for_key(EncryptionAlgorithm::Aegis256, key.secret())
            }
            Self::Aes256Gcm(key) => {
                header_value_for_key(EncryptionAlgorithm::Aes256Gcm, key.secret())
            }
        };
        value.set_sensitive(true);
        value
    }
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: cli/src/tui/app.rs
Line: 4611

Comment:
**TUI silently ignores encryption for all read paths**

All three TUI `read` call sites set `encryption: Default::default()` in `ReadArgs` but then pass `None` directly to `ops::read`. A user who has encryption configured for their stream will see `AlgorithmMismatch` or `AuthenticationFailed` errors in the TUI with no indication that an encryption key is required. If full TUI support is deferred, consider surfacing a user-visible hint when a decryption error is encountered (e.g. "stream appears encrypted; use the CLI with `--encryption` to read it").

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (4): Last reviewed commit: "red" | Re-trigger Greptile}

[shikhar]

@greptileai rereview