End-to-end encryption engine

I own large parts of the client-side encryption layer in a Flutter codebase that ships to iOS, Android, macOS, Windows and Web. The product is an enterprise, self-hosted messenger for organizations that keep their communication infrastructure in-house, including air-gapped deployments with no outside network at all.

That covers key management, keeping encryption state consistent as messages move through the app lifecycle (backgrounding, reconnects, multi-device sync), and closing the race conditions that appear when someone forwards a message while a key exchange is still in flight.

The platform is proprietary, so the notes below describe the engineering problem and my approach rather than protocol internals.

• Race conditions: forwarding a message could hit a window where encryption state hadn’t caught up with a key rotation, and the client had to resend to refetch that state. I traced it to a batching regression in public-key handling and rewrote the flow so key state stays authoritative on every read.
• Security auditing: I contributed to the review that cleared the platform for air-gapped, on-premise customers, where nothing falls back to a cloud service and a wrong assumption reaches the customer before it reaches us.
• Observability without leaking secrets: encryption bugs resist reproduction. I maintain a tag-based logging convention ([ENCRYPTION], [PUSH], [VOIP]) that lets me root-cause a production issue from a log file, without writing key material into one.