Um ponto que ainda não apareceu aqui é quem distribui as chaves públicas. Se o cliente pede ao servidor a lista de devices de cada membro, um servidor comprometido pode incluir um device próprio ou trocar a chave de alguém, e todo mundo passa a cifrar pra ele sem perceber. A criptografia no browser continua correta; o MITM acontece na entrega da chave.

O que costuma resolver:

• fingerprint/safety number verificável entre pessoas (QR de um device pro outro, estilo Signal);
• aviso visível quando o conjunto de chaves de um membro muda;
• um log append-only de chaves (key transparency).

Nas chamadas o problema é o mesmo, só que com a chave do E2EE do LiveKit. A doc deixa a distribuição por conta da aplicação, e o exemplo típico é gerar a chave no servidor e mandar junto com o token. No seu modelo, isso deixa o "ponta a ponta" decorativo. Melhor gerar no cliente, mandar pelo canal já cifrado e rotacionar quando alguém sai da chamada. E gravação/egress no servidor deixa de funcionar, a menos que você entregue a chave pro gravador, o que quebra o E2E de novo.

Quando um dispositivo novo é autorizado, os outros membros verificam a assinatura do dispositivo antigo antes de cifrar pra ele, ou confiam na lista que vem do servidor?