Security: Prevent keystream reuse when cloning or resuming stateful cipher workers #173

Summary

The new key-management architecture introduced in #172 raises a security concern around cloning and suspending stateful cipher workers.

Some cipher workers, including stream ciphers and AEAD implementations, can be cloned while an encryption/decryption operation is in progress. Cloning a worker may duplicate its internal state, including the current nonce, counter, and keystream position.

If both copies are subsequently used for encryption under the same key, they may generate identical keystream bytes.

This is especially dangerous for stream ciphers such as ChaCha20 and AES-CTR, where keystream reuse can compromise message confidentiality.

Related PRs:

• Key object rework: the traits lose their constructors, every mode gets a key, and workers borrow the key #172 — Key-management architecture
• Feat: Add ChaCha20, Poly1305, and Chacha20-Poly1305-AEAD #157 — ChaCha20, Poly1305, and ChaCha20-Poly1305 AEAD

Security implications

For a stream cipher:

C = P XOR K

Where:

C = Ciphertext

P = Plaintext

K = Generated keystream

If two workers are cloned at the same state and subsequently encrypt different plaintexts using the same keystream:

C1 XOR C2 = P1 XOR P2

The keystream cancels, potentially revealing information about both plaintexts.

For AEAD implementations, reusing the same key/nonce combination may additionally undermine authentication guarantees.

The concern extends to Suspendable and SuspendableKeyed interfaces if saved state can be restored multiple times, allowing multiple workers to continue from the same cryptographic state.

Note: This is a potential API misuse vulnerability, not a claim that the current implementation automatically reuses nonces or keystreams.

Affected interfaces

The following should be reviewed:

• Clone implementations on stateful encryption/decryption workers.
• Suspendable and SuspendableKeyed implementations.
• Resume operations that accept previously serialized cryptographic state.
• AEAD workers whose internal state includes nonce/counter or authentication state.
• APIs that allow multiple workers to be initialized from the same key/nonce combination.

In #157, implementing SuspendableKeyed for ChaCha20-Poly1305 was explicitly deferred because of these concerns.

Potential solutions

Option 1: Remove Clone from stateful cipher workers

Prevent workers from being duplicated while they hold an active cryptographic state.

Advantages:

• Compile-time prevention of accidental worker cloning.
• Simple security model.
• Consistent with Rust's ownership principles.

Disadvantages:

• Breaking API change.
• May affect legitimate use cases involving cloned state.

Recommendation: Strong default for encryption workers.

Option 2: Restrict or redesign SuspendableKeyed

Treat suspended encryption state as a one-time continuation capability.

Possible approaches include:

• Consuming the state when resuming.
• Avoiding Clone on in-memory suspended-state objects.
• Requiring explicit unsafe or hazardous APIs for state duplication.
• Introducing state-reuse tracking where appropriate.

Important limitation: Consuming an in-memory state does not prevent a caller from copying serialized checkpoint bytes before resuming.

Preventing replay across serialized copies requires additional mechanisms, such as persistent state tracking or monotonic counters, and cannot be guaranteed through Rust ownership alone.

Advantages:

• Reduces accidental state reuse.
• Makes security expectations explicit.

Disadvantages:

• Potentially breaking API changes.
• Persistent replay prevention introduces additional complexity.

Option 3: Separate encryption and decryption capabilities

Apply stricter rules to encryption workers than to decryption workers.

For example:

• Encryption workers are non-cloneable.
• Decryption workers may support cloning or replay when appropriate.
• Encryption resume operations require additional safeguards.

Advantages:

• Preserves useful decryption functionality.
• Targets restrictions at the highest-risk operations.

Disadvantages:

• More complex trait bounds and APIs.
• Does not eliminate misuse through copied serialized state.

Option 4: Document the risks and retain the existing API

Keep the current interfaces but document that cloning or restoring an encryption state can result in keystream reuse.

Advantages:

• Minimal implementation effort.
• No breaking changes.

Disadvantages:

• Relies entirely on callers following security guidance.
• Does not prevent accidental misuse.

Recommendation: Useful as defense-in-depth, but insufficient as the only mitigation for a misuse-resistant cryptographic API.

Proposed direction

I recommend:

1. Remove Clone from active encryption workers by default, unless an algorithm-specific security justification exists.
2. Review whether SuspendableKeyed should be implemented for stateful encryption workers at all.
3. If encryption-state restoration is supported, explicitly define its replay and state-ownership semantics.
4. Distinguish encryption from decryption where different restrictions are appropriate.
5. Add compile-fail tests verifying that restricted worker types cannot be cloned.
6. Add regression tests covering suspension/resumption and the handling of duplicated checkpoints.

Questions for maintainers

• Should Clone be permitted on active encryption workers?
• Is SuspendableKeyed intended to support resumable encryption, or primarily state persistence for other purposes?
• Should the library guarantee misuse resistance against duplicated state, or explicitly place that responsibility on callers?
• Should encryption and decryption workers have different cloning and suspension capabilities?

The goal is to establish consistent security semantics across the cipher APIs before adding SuspendableKeyed support to ChaCha20-Poly1305 and other stateful AEAD implementations.