Verifique um destinatário antes de selar um arquivo

Antes de selar um arquivo sensível, verifique o endereço de recebimento do destinatário por um canal que dificilmente esteja sob o controle de um atacante. Um endereço de recebimento é uma chave pública, não um nome. Se você cifrar para a chave errada, o detentor da chave errada poderá abrir o arquivo — e a pessoa que você pretendia alcançar talvez não consiga.

Esta é a falha humana mais comum em fluxos de trabalho cifrados. A criptografia pode ser impecável e o envio ainda assim estar errado, porque nada em uma sequência de caracteres prova de quem é a chave. A criptografia responde "quem pode abrir estes bytes?". Ela não responde "será que escolhi a pessoa certa?".

O que é um endereço de recebimento?

Um endereço de recebimento é uma chave pública de criptografia que o remetente usa para selar um registro. Na CardanoWall, ele vem em duas formas:

age1... — um endereço de recebimento clássico X25519.
age1pqc... — um endereço de recebimento híbrido pós-quântico.

O remetente sela para o endereço publicado do destinatário. O destinatário abre o registro com a chave privada correspondente, derivada da sua Identity Seed. O endereço foi feito para ser compartilhado; a chave privada e a semente precisam permanecer secretas. (Para saber mais sobre o que é um endereço e como os destinatários o distribuem, veja o que é um endereço de recebimento.)

Por que verificar a chave importa tanto?

Porque chaves públicas não são identidades.

Qualquer pessoa pode lhe enviar uma sequência que parece um endereço de recebimento. Qualquer pessoa pode colar uma chave ao lado de um nome de exibição familiar. A sequência em si não prova nada sobre quem controla a chave privada correspondente — apenas que algum detentor de chave a controla. Um atacante que lhe repassa o próprio endereço passa a ler tudo o que você sela "para" o seu contato, enquanto o seu contato não recebe nada.

Para um arquivo de teste descartável, isso talvez não importe. Para provas em um processo legal, dados de incidente, informações pessoais, trabalho inédito ou material de denúncia, verifique a chave antes de selar. A agenda de contatos existe para tornar essa verificação duradoura: você confere a chave uma vez, salva e reutiliza a entrada salva em vez de colar de novo uma sequência em que você precisaria confiar a cada vez.

O que conta como um bom canal de verificação?

Use um caminho que dificilmente esteja sob o controle do atacante e confirme a chave por um canal separado daquele que a entregou. Opções razoáveis, mais ou menos em ordem de robustez:

Uma entrega presencial (por exemplo, escanear um QR code juntos).
Uma ligação telefônica para um número que você já conhece, lendo a impressão digital da chave em voz alta.
Uma página de chave .well-known no domínio oficial do destinatário.
Um registro DNS TXT nesse domínio.
Um perfil assinado com link a partir do site oficial do destinatário.
Uma conversa com criptografia fim-a-fim já existente, na qual você confia.
Um diretório de chaves aprovado pela organização.
Uma impressão digital de chave impressa, entregue por um processo em que você confia.

O método certo depende do que você está enviando. Para arquivos de alto valor, confirme por dois canais independentes — uma chave enviada por e-mail e relida em uma ligação é muito mais difícil de falsificar do que qualquer uma das duas isoladamente.

O que não basta por si só?

Um nome familiar não basta. Trate o seguinte como não verificado até que um segundo canal confirme:

Uma chave que chega em um tópico de e-mail recém-criado.
Uma mensagem direta de uma conta que você não verificou.
Uma captura de tela de uma chave.
Um perfil público sem nenhum link confiável de volta à pessoa.
Um endereço encaminhado a você por um terceiro.
Uma mensagem do tipo "aqui está minha nova chave" sem verificação por um segundo canal.

Os atacantes concentram esforços no momento da troca de chaves, porque é a única etapa em que uma chave substituída parece completamente normal. Depois que uma chave errada é salva, cada envio futuro pode continuar indo discretamente para o lugar errado.

Como você deve usar a agenda de contatos?

Salve a chave depois de tê-la verificado, nunca antes. Para cada contato confiável, a agenda de contatos registra:

Um nome de exibição.
A chave pública de assinatura Ed25519 do contato (o identificador que vincula os registros dele à própria pessoa).
Um endereço de recebimento age1..., se houver.
Um endereço de recebimento pós-quântico age1pqc..., se houver.
Como e quando você verificou a chave.
Notas livres — anote exatamente como você conferiu.

Depois, ao compor um registro selado, escolha o contato na agenda em vez de colar um endereço novamente. Isso transforma uma verificação cuidadosa em muitos envios mais seguros. Para um passo a passo de como montar uma agenda, veja crie a sua agenda de contatos e como funciona a agenda de contatos.

Você deve preferir o endereço pós-quântico?

Para arquivos que podem permanecer sensíveis por muitos anos, sim — use o endereço pós-quântico quando o destinatário oferecer um.

Um endereço híbrido age1pqc... é muito mais longo do que um clássico, mas protege contra um atacante que registre o texto cifrado selado hoje e o decifre depois com um futuro computador quântico ("harvest now, decrypt later"). Se um registro só precisa permanecer privado no curto prazo, um endereço clássico age1... costuma ser suficiente.

Qualquer que seja a sua escolha, a regra não muda: verifique o endereço primeiro. Uma chave pós-quântica que você não verificou não é mais segura do que uma chave clássica que você não verificou.

E se o destinatário trocar de chave?

Verifique a nova chave como se fosse um novo contato. Não sobrescreva um endereço de recebimento salvo só porque uma mensagem afirma que ele mudou — é exatamente esse o formato de um ataque de substituição de chave. Confirme a nova chave por um canal confiável, atualize a entrada e anote por que ela mudou.

Para equipes e organizações, a rotação de chaves deve ser anunciada em lugares previsíveis: um domínio oficial, um perfil assinado ou um processo interno documentado. Se você suspeitar que uma chave foi comprometida, pare de selar para o endereço antigo imediatamente e aguarde a confirmação do novo.

O que um registro selado revela na cadeia?

Não uma lista legível de destinatários. Um registro selado Label 309 envolve a chave de conteúdo em um compartimento cifrado por destinatário e depois embaralha esses compartimentos, de modo que o registro público não carrega nenhum campo "destinatário" em texto claro. A Inbox encontra os registros destinados a você tentando decifrar localmente cada compartimento com as suas próprias chaves. O que um observador consegue ver é que existe um registro selado, quando ele foi publicado e quantos compartimentos ele tem — nunca quem são os destinatários.

Essa cegueira quanto ao destinatário protege a privacidade na cadeia, mas não faz nada pela verificação de chave. A cadeia esconde para quem você selou; ela não consegue checar se você selou para a chave certa. Escolher o endereço correto continua sendo inteiramente tarefa do remetente. E observe o limite do outro lado: o selamento mantém o texto claro cifrado para os detentores da chave, mas não garante anonimato, e qualquer destinatário pode vazar o texto claro depois de decifrá-lo. (Para o que uma prova pode e não pode estabelecer, veja o que uma prova não prova.)

A versão curta

Boa criptografia mais uma verificação de chave ruim ainda é um envio ruim. Então:

Verifique um endereço de recebimento antes de selar qualquer coisa sensível, idealmente por dois canais.
Salve as chaves verificadas na agenda de contatos; anote como cada uma foi conferida.
Verifique de novo quando uma chave mudar — trate a nova chave como um contato recém-criado.

A criptografia é a parte fácil. A verificação é a parte que cabe a você.

Leituras adicionais

O que é um endereço de recebimento e perfis públicos e endereços de recebimento.
Como receber registros selados e divulgação confidencial sem arquivos públicos.
Modo de lista de permissões para registros recebidos — um filtro complementar da Inbox para o que você recebe.
O padrão aberto Label 309 em label309.org; o código aberto, os SDKs e a CLI em github.com/cardanowall.