ctr256_encrypt/decrypt reject bytearray for iv/state — breaks pyrogram and forks

[illvart]

What's wrong

ctr256_encrypt and ctr256_decrypt only accept bytes for iv/state. pyrogram (and kurigram, pyrofork, etc) always pass bytearray, so calling this library from pyrogram-based projects crashes:

import tgcrypto, os

key = os.urandom(32)
iv = bytearray(os.urandom(16))
state = bytearray(1)

tgcrypto.ctr256_encrypt(b"data", key, iv, state)

TypeError: 'bytearray' object is not an instance of 'bytes'

Why it matters

pyrogram uses bytearray for iv/state on purpose — it mutates them in place to carry the CTR counter across chunks (needed for its obfuscated TCP transport and CDN file downloads). This means the crash happens right at connection time, so a pyrogram/kurigram bot can't connect to Telegram at all with this library installed as the crypto backend — not just an edge case.

What would fix it

• Accept bytearray for iv/state (matching how TgCrypto's own docs show it being used), and
• Make sure the counter state can actually be carried forward between calls — right now the function only returns ciphertext, with no way to continue a stream across multiple calls.

Happy to test a fix if useful.

Environment

• TgCryptoRust 1.3.0
• Python 3.12.3 and Python 3.14.7 (both reproduced, clean uv venvs)
• Reproduced against pyrogram (official, latest) and kurigram 2.2.24

[illvart]

Follow-up with more precise scope — the crash isn't universal across all transports, so here's exactly where it does and doesn't happen:

Where it breaks

Only the obfuscated TCP transports call CTR during the connection itself:

• tcp_abridged_o.py (TCPAbridgedO)
• tcp_intermediate_o.py (TCPIntermediateO)

Both construct iv/state as bytearray right when the connection is set up:

nonce = bytearray(os.urandom(64))
...
self.encrypt = (nonce[8:40], nonce[40:56], bytearray(1))
...
aes.ctr256_encrypt(data, *self.encrypt)   # called on every packet sent

If a client uses either of these, the handshake itself fails immediately with TgCryptoRust installed.

Where it's fine

The default transport, TCPAbridged, doesn't touch CTR at all — checked its source directly, it only does packet-length framing, no aes import, no encryption at that layer. So a normal pyrogram/kurigram client using the default transport connects fine.

One more spot that's still affected regardless of transport

client.py's CDN file-download path calls ctr256_decrypt with a bytearray iv whenever a downloaded file gets redirected to Telegram's CDN — this happens independently of which TCP transport is active, so it's still a crash risk even on TCPAbridged.

Summary of impact

Transport	Hits CTR at connect time?
TCPAbridged (default)	No
TCPIntermediate	No
TCPAbridgedO (obfuscated)	Yes — breaks handshake
TCPIntermediateO (obfuscated)	Yes — breaks handshake
CDN file download (any transport)	Yes — breaks mid-download

So the practical severity depends on whether a project uses the obfuscated transport (often chosen specifically to evade DPI/blocking) and whether downloaded files get redirected to CDN. Wanted to flag this since it affects the fix priority — the obfuscated-transport case is a hard blocker at connect time, not just a download-time edge case.

[joyccn]

Fixed in #5 — thanks for the detailed report (especially the transport-by-transport impact table, that was spot on).

What changed (ctr256_encrypt/ctr256_decrypt)

• data, key, iv, and state now accept bytearray (and still bytes, zero-copy). This covers all four pyrogram call sites — the handshake's nonce bytearray, the bytearray key/iv slices from nonce[8:40]/nonce[40:56], and bytearray(1) states.
• In-place carry for iv/state: when passed as bytearray, the advanced counter and residual offset are written back into the same objects, so reusing them across calls continues the keystream — exactly the TgCrypto semantics pyrogram's obfuscated transports (TCPAbridgedO, TCPIntermediateO) and CDN downloads rely on. Verified against pyrogram's pyaes fallback algorithm in aes.py.
• Validation unchanged (key=32, iv=16, state 0..15); new tests cover chunked-stream == one-shot, a 512 KB CDN-style chunked roundtrip, and in-place mutation.

Full obfuscated-connect simulation (64-byte nonce handshake + multi-packet streaming) roundtrips correctly. 13/13 Python tests, 19/19 Rust tests, fmt/clippy clean.

If you're still on Python 3.12/3.14 envs — happy for you to be the final drop-in test on your side: install from the PR branch and try connecting with TCPAbridgedO on pyrogram/kurigram. 🚀

[illvart]

Fixed in #5 — thanks for the detailed report (especially the transport-by-transport impact table, that was spot on).

What changed (ctr256_encrypt/ctr256_decrypt)

• data, key, iv, and state now accept bytearray (and still bytes, zero-copy). This covers all four pyrogram call sites — the handshake's nonce bytearray, the bytearray key/iv slices from nonce[8:40]/nonce[40:56], and bytearray(1) states.
• In-place carry for iv/state: when passed as bytearray, the advanced counter and residual offset are written back into the same objects, so reusing them across calls continues the keystream — exactly the TgCrypto semantics pyrogram's obfuscated transports (TCPAbridgedO, TCPIntermediateO) and CDN downloads rely on. Verified against pyrogram's pyaes fallback algorithm in aes.py.
• Validation unchanged (key=32, iv=16, state 0..15); new tests cover chunked-stream == one-shot, a 512 KB CDN-style chunked roundtrip, and in-place mutation.

Full obfuscated-connect simulation (64-byte nonce handshake + multi-packet streaming) roundtrips correctly. 13/13 Python tests, 19/19 Rust tests, fmt/clippy clean.

If you're still on Python 3.12/3.14 envs — happy for you to be the final drop-in test on your side: install from the PR branch and try connecting with TCPAbridgedO on pyrogram/kurigram. 🚀

Retested on 1.3.1 (Python 3.12.3 & 3.14.7, kurigram 2.2.24) — confirmed fixed. bytearray iv/state works now, chained calls advance state correctly, and output matches pytgcrypto byte-for-byte. CTR is also ~7-8x faster than pytgcrypto in my benchmarks. Thanks for the quick fix! 🔥