Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#173 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@officialfrancismendoza đang làm issue này rồi.

Từ ngày 21/10/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

enhancement

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:

  • #172 — Key-management architecture
  • #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.

Ngôn ngữ chính
Rust
Star
25
Fork
18
Merge trung bình
56 phút
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của bcgit/bc-rust

Tất cả issue của bcgit/bc-rust

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.