Production Pitfalls

Implementing Signal in production is treacherous. Real bugs and considerations:

1. Random number generation:

• Bad RNG = predictable keys = total break.
• Use OS CSPRNG (/dev/urandom, getrandom(), BCryptGenRandom).

2. Key serialization:

• Sealed-sender certificates encoded as protobuf. Off-by-one in length prefix → buffer overrun.
• Use generated parsers; never roll your own protobuf.

3. State persistence atomicity:

• Crash mid-write → corrupted session → can't decrypt incoming.
• Use atomic file replace (write tmp → fsync → rename) or SQLite WAL.

4. Out-of-order message handling:

• Cache must bound: attacker sends n=2^32 first. Without bound: OOM.
• Cap skip count (Signal: 1000 messages).

5. Multi-device sync:

• Linked devices share IK_pub but each has own DH ratchet.
• Sync of session state via "device sync messages" — encrypted between linked devices.

6. Re-keying:

• Identity key rotation requires safety number re-verification.
• SPK rotation: smooth. No user action.

7. Side channels:

• Display-time differences ("decrypting…" vs "instant") leaks info.
• Push notifications on iOS/Android: contents are encrypted; metadata may leak.

8. Group race conditions:

• Sender adds member; member sends; new member doesn't have sender key yet.
• Buffer messages, fetch sender keys on demand, retry.

9. Crypto upgrade path:

• Migrating from Curve25519 → post-quantum (e.g., Kyber). Hybrid mode: combine X25519 + Kyber.
• Signal announced PQXDH (Post-Quantum X3DH) in 2023 — already shipping.

10. Don't reinvent:

• Use libsignal (official). Ports exist for Java, Swift, Rust, Python (libsignal-python).
• Audited. Hardware-tested. Has the edge cases right.