自制智能灯泡控制APP遇蓝牙加密难题，求问灯泡加密类型

Great question! Based on your observations—identical bulb actions from different encrypted payloads, plus the 3-byte incrementing counter at the start—here are the most probable encryption schemes used by your smart bulb:

• AES in GCM or CCM Mode
  These are Authenticated Encryption with Associated Data (AEAD) algorithms, extremely common in Bluetooth Low Energy (BLE) devices like smart bulbs. Both rely on a unique nonce (or counter-based nonce) for each encryption operation. Your 3-byte incrementing counter is likely part of this nonce: every time you send the same command, the counter increments, generating a different nonce. Even though the encrypted payload changes, the underlying plaintext command stays the same, so the bulb executes the same action. GCM and CCM also include integrity checks, which is a bonus for smart devices to prevent tampered commands.

• ChaCha20-Poly1305
  Another popular AEAD algorithm, especially in resource-constrained devices (like low-power smart bulbs). It uses a unique nonce (often combined with an incrementing counter) to generate distinct ciphertexts for the same plaintext. Since ChaCha20-Poly1305 is lighter on hardware requirements than AES, it’s a go-to for devices without dedicated AES acceleration. Your 3-byte counter fits perfectly here as part of the nonce to ensure each encryption uses a unique key stream.

• Stream Ciphers with Unique IV/Counter
  Older or simpler devices might use stream ciphers like RC4 (though this is less secure and less common now) or Salsa20. These ciphers generate a unique key stream based on an Initial Vector (IV) or counter. The 3-byte incrementing value would act as the IV/counter, creating a different key stream each time—so XORing it with the same plaintext command results in different ciphertexts, but decrypting with the matching IV/counter gets back the original command.

Quick Checks to Narrow It Down #

• Confirm the 3-byte value strictly increments with each identical command (e.g., 080000 → 0a0000 as in your example) — this strongly points to a counter-based nonce system, favoring AES-CCM/GCM or ChaCha20-Poly1305.
• Check if the encrypted core length is consistent across identical commands (fixed length usually aligns with AEAD modes, which add a small authentication tag).

内容的提问来源于stack exchange，提问作者user9343873