Cara achei sua ideia muito boa, para estudo é um exelente projeto, e com certeza vai agregar demais ao seu conhecimento e ao seu currículo, então se existe alguma dúvida sobre fazer a PoC, coloque a mão na massa que você só tem a ganhar.
Agora caso realmente queira tornar esse protocolo utilizável para produção no mundo real, com perigos reais, vou citar alguns pontos que me chamaram atenção e que talvez possam ser aprimorados ou repensados posteriormente.
Principais vulnerabilidades / riscos que você precisa considerar
Metadados de rede continuam sendo um risco
Mesmo com chaves descartáveis, quem observa a rede pode correlacionar conexões por IP, horários e padrões de tráfego.
Solução: usar mixnets / Tor (como você citou) / multi-hop relays, padding, atrasos aleatórios e cover traffic. Evitar usar sempre o mesmo relay/hint.
Bootstrap problem (troca inicial do token)
A primeira troca do token é crítica: se for feita por canal público, adversário pode interceptar.
Possíveis soluções: trocar tokens via canal físico/out-of-band (QR, NFC, Bluetooth (como você disse que faria para troca local), por URLs single-use entregues por e-mail temporário, ou usar mecanismos de verificação “compare fingerprint” (TOFU + verificação humana). Para contatos remotos, um serviço de rendezvous que não grava logs (ou grava apenas efemeramente e sem metadados) ajuda — mas é um ponto central de confiança. Infelizmente isso adiciona bastante complexidade.
Key zeroization em userland não é 100% confiável
Em linguagens como Go, o runtime pode fazer cópias da chave, paginar para disco, gerar snapshots, etc. Zeroizar um slice ajuda, mas não garante que não existam cópias em memória/arquivo temporário.
Possivel solução: minimizar cópias (manter chave em []byte, não em strings), usar mlock/mlock para evitar swap (se possível), evitar logging de chaves, e, quando possível, usar hardware de segurança (Secure Element / TEE) para armazenar a chave.
Relays ou serviços de rendezvous maliciosos
Se o hint aponta sempre pro mesmo relay, um operador deste relay pode correlacionar quem se conecta.
Solução: permitir múltiplos relays, rotacioná-los, e preferir relays federados/voluntários. Encriptar end-to-end a troca (Noise) mesmo via relay — relay só encaminha bytes, não vê conteúdo.
Cópias de token fora do seu controle
Quem recebeu seu token pode manter e reutilizar depois da sua revogação (a revogação local não “apaga” cópias alheias).
Possível solução: oferecer tokens com validade embutida (timestamps), ou tokens que exigem prova de posse contínua (ex: challenge-response onde a posse da chave privada é verificada). Mas cuidado: tempo de validade ou provas verificáveis podem diminuir anonimato e trazer novos problemas.
Algumas considerações de design
Usabilidade vs Privacidade: revogar identidade aumenta privacidade, mas exige re-compartilhar token — ou seja, atrito social. Pense em modos: “ephemeral mode” (muitos renascimentos) vs “stable mode”.
Descoberta de contatos: se você evita DHTs públicas (que criam grafos), então descoberta fica difícil. Opções: out-of-band, QR, troca via servidor anônimo efêmero, ou “introducer” (alguém confia e cria ponte).
Escalabilidade: se ambos ficarem off-line, como trocar token? Pensar em “store-and-forward” via relays criptografados pode ser necessário — aí aceita-se algum metadata leakage.
Abuso do protocolo: identidades descartáveis podem facilitar abuso (spam, doxxing). Você pode pensar em opções como rate-limits baseados em proof-of-work ou reputação social.