Como receber um registro selado

Para receber um registro selado, você compartilha um endereço de recebimento e deixa que seu software encontre os registros que suas chaves conseguem abrir. Não há caixa de correio que o servidor preenche para você. Seu cliente varre o feed público do Label 309, testa suas chaves de recebimento contra cada registro selado e exibe aqueles que decifram com sucesso.

Essa inversão é a ideia toda: sua caixa de entrada é descoberta por decifração, não atribuída por um servidor. A cadeia nunca carrega um campo de destinatário legível, e o gateway nunca precisa saber quais registros são seus.

O que é um registro selado?

Um registro selado é uma Proof of Existence (prova de existência) com o conteúdo cifrado.

O registro público ainda se compromete com o hash do texto claro, de modo que a prova pode, mais tarde, mostrar que aquele conteúdo exato existia em um horário de bloco público. O arquivo em si é cifrado, e o texto cifrado fica em um local endereçado por conteúdo, como Arweave ou IPFS — nunca na cadeia. (Para a mecânica da prova pública, veja como o Label 309 funciona.)

Qualquer pessoa que tenha uma chave correspondente pode decifrar o texto cifrado, recuperar os bytes originais, recalcular o hash do texto claro e confirmar que o arquivo decifrado corresponde ao compromisso na cadeia. Quem não tem uma chave vê que um registro selado existe — mas não deveria conseguir ler o conteúdo.

O que eu dou ao remetente?

Você dá ao remetente um endereço de recebimento. Nada mais.

Para registros selados Label 309, os endereços de recebimento vêm em duas formas:

• age1… — o caminho de recebimento clássico, com X25519.
• age1pqc1… — um caminho de recebimento híbrido pós-quântico (X25519 combinado com ML-KEM-768, na construção X-Wing).

Um endereço de recebimento é público e seguro de compartilhar. Ele permite que alguém cifre um registro para você e nada além disso. É derivado da sua identidade, mas não a revela.

Não dê ao remetente sua Identity Seed. A semente é a raiz privada da sua identidade — os 32 bytes a partir dos quais sua chave de assinatura e suas chaves de recebimento derivam deterministicamente. Quem a detém pode assinar e decifrar como se fosse você. (Mais sobre por que a semente é o verdadeiro backup: sua identidade é uma semente.)

Como o remetente cria o registro?

O software do remetente faz o selamento localmente. Em linhas gerais:

1. O remetente escolhe um arquivo ou mensagem.
2. O software calcula o hash do texto claro.
3. O software gera uma chave de conteúdo de uso único e cifra o conteúdo.
4. Para cada destinatário, ele empacota essa chave de conteúdo para a chave de recebimento do destinatário, produzindo um compartimento por destinatário.
5. O texto cifrado é enviado para um armazenamento endereçado por conteúdo (como ar://).
6. Um registro Label 309 é publicado na Cardano, carregando o hash do texto claro e o envelope selado.

O registro na cadeia prova o horário e carrega os compartimentos de chave empacotados. O texto cifrado armazenado guarda o arquivo cifrado. Sua chave privada é o que abre o seu compartimento. A mesma sequência — calcular o hash, assinar, selar, compartilhar — é percorrida em hash, sign, seal, share.

Como meu cliente encontra um registro destinado a mim?

Seu cliente varre os registros públicos e tenta abri-los.

Esta é a parte que soa estranha se você espera uma caixa de correio comum. Em uma caixa de entrada hospedada, o servidor sabe a qual conta uma mensagem pertence e a roteia. Um registro selado Label 309 não carrega esse tipo de roteamento. O envelope lista compartimentos de chave empacotados, mas nenhuma chave pública de destinatário aparece em lugar algum na transmissão — não há campo de destinatário para ler.

Então seu cliente sincroniza o feed público de registros Label 309 e, para cada registro selado, testa se algum compartimento abre com as chaves de recebimento da sua identidade. Isso é decifração por tentativa local: uma tentativa de desempacotar cada compartimento, realizada inteiramente no seu dispositivo. Se um compartimento abre, o registro é seu e seu cliente o adiciona à sua caixa de entrada. Se nenhum abre, seu cliente o ignora.

Uma consequência sutil mas importante: a ordem dos compartimentos também não vaza nada. O remetente embaralha os compartimentos antes de publicar, de modo que nem mesmo a posição do "destinatário principal" carrega qualquer sinal.

A decifração por tentativa precisa baixar cada arquivo?

Não. A decifração por tentativa roda contra o envelope carregado no registro na cadeia, não contra o arquivo armazenado.

Os compartimentos empacotados e uma pequena tag de autenticação ficam nos próprios metadados do registro. Seu cliente consegue determinar que um registro é endereçado a você — e recuperar a chave de conteúdo — apenas a partir desses bytes na cadeia, antes de buscar qualquer texto cifrado. Isso importa porque o texto cifrado pode ser grande: um cliente desktop pode primeiro descobrir quais registros são seus e, depois, buscar os arquivos cifrados de forma preguiçosa quando você os abre, ou pré-armazená-los em cache conforme suas configurações.

Para um cliente offline-first, essa separação é a base:

• sincronizar o feed público de registros;
• decifrar por tentativa localmente, contra os envelopes;
• armazenar em cache o texto cifrado correspondente, se você quiser;
• decifrar sob demanda quando você abre um arquivo;
• manter tudo que já foi sincronizado utilizável sem rede.

O que o gateway realmente sabe?

Um gateway sabe o que qualquer observador público sabe, mais os detalhes operacionais do serviço que ele opera.

Para um gateway hospedado, isso pode incluir a atividade da conta, o uso da API, seu fluxo de cotação e publicação, a atividade de upload, o estado do saldo, dados de infraestrutura no nível da rede e os metadados públicos dos registros que todos podem ver. (Para o quadro completo dessa fronteira, veja o que a CardanoWall consegue ver.)

O que ele não precisa é da sua Identity Seed, das suas chaves privadas de recebimento ou de qualquer capacidade de decifrar conteúdo selado por você. A propriedade de privacidade aqui não é "o servidor não aprende nada sobre nada" — isso seria desonesto. É mais restrita e mais útil: a correspondência de destinatários e a decifração acontecem localmente, de modo que nenhum campo de destinatário legível é publicado e nenhuma chave privada é jamais enviada ao gateway. O gateway é cego ao destinatário por design; qualquer tentativa de filtrar registros por destinatário é simplesmente ignorada, porque não existe coluna de destinatário para filtrar.

Por que não há um campo público de destinatário?

Porque um campo público de destinatário vazaria o grafo social.

Se cada registro selado nomeasse exatamente para quem foi destinado, um observador poderia mapear as relações entre remetentes e destinatários sem ler um único byte de texto claro. Para fluxos de trabalho confidenciais — uma fonte contatando uma redação, um lance selado, evidências em custódia —, essa exposição pode ser o risco inteiro.

O Label 309 usa compartimentos de chave empacotados em vez disso. O registro carrega material cifrado que apenas os detentores de chave pretendidos podem abrir. Um observador consegue ver que um registro está selado e quantos compartimentos ele tem, mas não uma lista legível de destinatários.

Isso não é anonimato perfeito, e não deve ser vendido como tal. A quantidade de compartimentos, o horário de publicação e metadados externos ainda podem revelar algo, e um remetente que precise derrotar a correlação de horários tem de publicar fora da linha do tempo sensível. O que o design elimina é o vazamento mais óbvio: uma coluna pública de destinatários em um livro-razão permanente.

E se eu tiver várias identidades?

Seu cliente tenta cada identidade desbloqueada.

Você pode manter uma identidade para registros pessoais, uma para uma empresa, uma para recepção jurídica e uma para um canal confidencial de alto risco. Cada uma tem sua própria semente e suas próprias chaves de recebimento, de modo que um registro selado para uma é invisível para as outras até que as chaves daquela identidade sejam testadas.

Um cliente offline-first acompanha de forma independente até onde cada identidade varreu o feed de registros. É essa independência que permite a você importar uma semente antiga depois e fazer o cliente revarrer todo o feed para aquela identidade — em vez de começar a partir de hoje e silenciosamente perder tudo que foi enviado antes da importação.

O que acontece quando eu restauro uma Identity Seed antiga?

Um software compatível volta a derivar as mesmas chaves de recebimento a partir da semente, deterministicamente.

Isso significa que uma semente antiga pode encontrar registros selados antigos, desde que os registros ainda estejam na cadeia para serem varridos e o texto cifrado ainda seja recuperável ou esteja em cache. O cliente revarre o feed público, decifra por tentativa os envelopes selados e reconstrói a visão de caixa de entrada para aquela identidade. Restaurar a semente restaura a capacidade de reconhecer os registros destinados a ela — o gateway não guarda nenhuma caixa de correio privada para devolver.

Esta é uma das razões mais claras de a semente importar tanto, e de a semente de identidade ainda merecer sua atenção. Se você perde a semente de uma identidade destinatária, os registros selados endereçados a ela podem se tornar ilegíveis — mesmo que as provas públicas permaneçam na cadeia e continuem a verificar. A criptografia não tem porta dos fundos de recuperação por design; a semente é o caminho de recuperação.

Um cliente desktop consegue receber registros offline?

Ele consegue trabalhar com o que já tiver sincronizado.

O CardanoWall Desktop — um aplicativo open-source em Rust, construído com Tauri sobre o SDK Rust open-source (github.com/cardanowall) — foi feito exatamente em torno disso. Uma vez que tenha sincronizado registros e armazenado texto cifrado em cache, ele lista, busca, verifica e decifra esses dados locais sem nenhuma conexão de rede. Se um registro ainda não foi sincronizado, ou um texto cifrado ainda não foi buscado, ele precisa da rede para recuperá-los — e diz isso claramente, em vez de falhar em silêncio.

Isso espelha o comportamento de um cliente de e-mail sério: estar offline não significa que o mundo para. Seu espelho local, seu cache e seu cofre se tornam a fonte da verdade até a rede voltar. (Mais sobre o modelo offline: provas offline e CardanoWall Desktop.)

Como devo verificar quem enviou um registro?

Receber um registro selado prova apenas que sua chave consegue abri-lo. Isso não prova quem o enviou.

A autoria no Label 309 é opcional. Se um registro carrega uma assinatura, essa assinatura mostra que uma chave específica atestou o registro — mas você ainda precisa de contexto para decidir de quem é aquela chave. Se um registro não é assinado, o remetente pode ter deliberadamente evitado vincular qualquer identidade, que é exatamente o que alguns fluxos de trabalho confidenciais exigem.

Para material sensível, confirme as chaves do remetente e os endereços de recebimento por um canal paralelo: mantenha uma agenda de contatos, compare impressões digitais de chave e use um diretório ou uma confirmação direta em que você já confie. A criptografia protege o conteúdo; decidir com a chave de quem você está falando é uma decisão de confiança separada e humana. A mecânica da agenda de contatos é abordada em como funciona a agenda de contatos.

O que pode dar errado?

A falha mais grave é perder a semente. Perca a Identity Seed de uma identidade destinatária e você pode perder a capacidade de decifrar os registros endereçados a ela — permanentemente, para aquela identidade.

O resto é operacional, e um bom software deveria expô-los honestamente em vez de escondê-los:

• o texto cifrado nunca foi enviado com sucesso;
• o local de armazenamento está temporariamente indisponível;
• o remetente usou o endereço de recebimento errado;
• você importou a identidade errada;
• o dispositivo local está comprometido (um programa malicioso em uma máquina desbloqueada pode ler segredos na memória — veja modo de computador público);
• o registro é muito recente e não atingiu a profundidade de confirmação que você exige;
• o registro é válido mas não assinado, então nenhuma identidade de remetente é estabelecida.

Um sistema de provas conquista confiança mostrando a incerteza, não encobrindo-a.

A versão curta

Para receber registros selados:

1. Compartilhe um endereço de recebimento.
2. Mantenha sua Identity Seed segura e com backup.
3. Deixe seu cliente varrer o feed público do Label 309.
4. Deixe-o decifrar por tentativa localmente.
5. Abra e verifique os registros que suas chaves conseguem decifrar.

Sua caixa de entrada não é uma lista de mensagens, no servidor, endereçadas à sua conta. É uma visão local dos registros selados que sua identidade consegue abrir — e é precisamente isso que mantém o gateway fora da sua correspondência privada.

Uma última nota honesta sobre limites: um registro selado mantém o texto claro cifrado para os detentores de suas chaves, mas não garante anonimato, e quem o decifra pode escolher vazar o texto claro depois. A prova mostra que bytes específicos existiam até um horário público. Ela não prova verdade, propriedade ou autoria — veja o que uma prova não prova.

Leitura complementar

• O que é um endereço de recebimento?
• Verifique um destinatário antes de selar um arquivo
• Divulgação confidencial sem arquivos públicos
• O padrão aberto e seu código de referência: label309.org e github.com/cardanowall. O Label 309 está submetido ao processo CIP da Cardano e em análise.