Divulgação confidencial sem publicar o arquivo

Você pode provar que um arquivo existiu em determinado momento sem torná-lo público.

É isso que um registro Label 309 selado faz. O remetente calcula o hash do texto claro, cifra o arquivo e publica um registro de prova na Cardano. O texto cifrado fica armazenado em um local endereçado por conteúdo e é disponibilizado apenas aos detentores da chave capazes de decifrá-lo. A blockchain pública prova que um compromisso específico existia até um horário de bloco público; o texto claro permanece legível somente para o público escolhido.

Isso se encaixa em trabalhos jurídicos, de conformidade, de segurança, de jornalismo, com parceiros e de investigação interna — em qualquer situação em que a linha do tempo importa, mas o documento não deve ser publicado na internet aberta.

O que significa divulgação confidencial aqui?

Significa compartilhar provas com um público específico em vez de com o mundo inteiro.

Esse público pode ser um advogado, um auditor, um regulador, um jornalista, uma equipe de investigação interna, o contato de segurança de um cliente, um comitê do conselho, um parceiro — ou uma versão futura de você mesmo.

O objetivo é provar que a prova existia em determinado momento sem colocar o texto claro em uma blockchain pública ou em um site público. A Proof of Existence (prova de existência) selada foi feita exatamente para esse formato: uma afirmação pública de tempo sobre um arquivo privado.

O que de fato vai para a cadeia pública?

O registro de prova torna-se público. O texto claro, não.

O registro na cadeia pode carregar:

o hash do texto claro — esta é a prova de tempo;
o horário de bloco da transação Cardano;
um envelope de criptografia contendo o material de chave encapsulado;
uma ou mais URIs de texto cifrado endereçadas por conteúdo (ar:// ou ipfs://);
uma assinatura opcional, caso o remetente decida assinar;
uma raiz Merkle, caso a divulgação abranja muitos arquivos de uma só vez.

O registro deliberadamente não carrega:

o arquivo em texto claro;
uma lista legível de destinatários;
a chave privada de qualquer destinatário;
a sua Identity Seed;
as provas decifradas.

Vale enunciar com clareza uma sutileza: as chaves públicas dos destinatários também nunca aparecem na cadeia. Um destinatário não é nomeado no registro — ele descobre que um registro é seu apenas ao conseguir decifrá-lo por tentativa. Um observador percebe que um registro está selado, vê o hash do seu texto claro e o horário de bloco, e pode contar os compartimentos de chave encapsulados, mas os compartimentos são embaralhados em ordem aleatória segura antes da publicação, de modo que nem mesmo "destinatário principal primeiro" vaza nada. A contagem diz quantos, nunca quem.

O próprio texto cifrado pode ser baixado por qualquer pessoa que tenha a URI. Sem uma chave correspondente, ele permanece ilegível.

Como um destinatário abre um registro selado?

O destinatário compartilha um endereço de recebimento com o remetente, e o remetente sela o registro endereçado a ele.

Um endereço de recebimento é apenas uma chave pública. O remetente encapsula a chave de criptografia do arquivo a esse endereço. Mais tarde, o cliente do destinatário varre registros Label 309 públicos e tenta abrir os compartimentos de chave cifrados de cada registro com suas próprias chaves privadas de recebimento — tudo localmente, no dispositivo do destinatário. Nada sobre quais registros são seus jamais sai da máquina.

Quando um compartimento se abre, o cliente busca o texto cifrado, decifra-o, recalcula o hash do texto claro e confere esse hash contra o compromisso na cadeia. Uma correspondência confirma duas coisas ao mesmo tempo: o destinatário tem o arquivo real, e esse arquivo exato é o que foi fixado pelo compromisso no horário de bloco registrado.

Como o destinatário detém uma chave privada, é aqui que a verificação passa de "um compromisso existia" para "este conteúdo específico existia". Para a mecânica do lado do remetente de compartilhar um endereço de recebimento e receber registros selados, veja como receber registros selados.

Por que não simplesmente enviar o arquivo cifrado por e-mail?

O e-mail consegue mover arquivos, mas não é um carimbo de tempo durável e verificável de forma independente.

Uma mensagem pode ser excluída, alterada ou perdida. Anexos são removidos. Servidores de e-mail são desativados. Os formatos de exportação são confusos e difíceis de autenticar anos depois. Nada disso dá a um verificador uma forma de provar quando o arquivo existiu.

Um registro Label 309 selado dá ao arquivo uma âncora pública de prova que não depende da sua caixa de e-mail nem do servidor de ninguém. A carga cifrada pode ser preservada separadamente, e o destinatário pode depois provar que o conteúdo decifrado corresponde a um hash fixado por um compromisso em uma cadeia pública. Você ainda pode notificar o destinatário por e-mail — apenas não deixe a prova depender disso.

Por que não simplesmente subir o arquivo cifrado para um armazenamento privado?

Você pode, e muitas vezes deve. Mas o armazenamento privado, sozinho, não lhe dá nenhuma âncora pública de tempo.

Um bucket de armazenamento corporativo, uma ferramenta de gestão de casos ou um portal seguro conseguem guardar arquivos cifrados perfeitamente bem. O que nenhum deles responde por si só é: um verificador posterior consegue provar quando aquele pacote cifrado existiu, e que o texto claro decifrado corresponde a um compromisso público? Sem isso, "tínhamos este arquivo em março" é uma afirmação, não uma prova.

O Label 309 acrescenta o compromisso com carimbo de tempo. Ele não substitui o seu armazenamento seguro — dá a esse armazenamento uma camada de prova verificável por cima.

Quando o registro de divulgação deve ser assinado?

Assine quando a responsabilização importa mais do que o anonimato.

Assinar um registro é opcional. Uma assinatura permite que uma chave de identidade específica responda pela divulgação — útil quando uma empresa envia um pacote de provas formal a um auditor, ou quando uma equipe jurídica precisa de um registro responsável e atribuível. A assinatura é uma afirmação de autoria respaldada por chave pública, e um verificador pode conferi-la sem confiar em nenhum servidor.

Deixe o registro sem assinatura quando o anonimato do remetente importa mais. Um registro selado sem assinatura não vincula nenhuma identidade de remetente na cadeia, que é exatamente o que as denúncias de denunciantes e os cenários de lances selados exigem. Essa troca deve ser uma escolha deliberada: uma assinatura pode estabelecer quem esteve por trás da divulgação, e em contextos sensíveis essa mesma atribuição pode revelar mais do que o remetente gostaria.

Um registro pode alcançar vários destinatários?

Sim. Um único registro selado pode encapsular a chave de criptografia do arquivo em compartimentos separados para múltiplos destinatários.

Cada destinatário abre o registro com sua própria chave, e um destinatário não pode usar seu compartimento para derivar a chave de outro destinatário. Isso cobre um escritório de advocacia e seu cliente, uma equipe de investigação interna, um auditor e um contato da empresa, vários reguladores ao mesmo tempo, um comitê do conselho — ou um remetente que guarda uma cópia recuperável para si enquanto compartilha com os demais.

O registro público pode revelar o número de compartimentos, mas nunca uma lista legível de a quem eles pertencem.

E quanto a um grande pacote de provas com muitos arquivos?

Use um manifesto e agrupamento Merkle em vez de uma transação por arquivo.

Calcule o hash de cada arquivo em uma folha, combine as folhas em uma única raiz Merkle e publique essa raiz única no registro Label 309. Sele o manifesto e os arquivos de apoio conforme necessário. Depois, um destinatário ou auditor pode verificar qualquer arquivo individual com uma prova de inclusão curta — totalmente offline — em vez de tratar o pacote inteiro como um arquivo opaco. As provas de inclusão crescem apenas com o logaritmo do tamanho do lote, então uma divulgação de mil arquivos ainda se verifica item por item.

Este é o mesmo padrão de uma raiz para muitos arquivos descrito em um registro para milhares de arquivos; aqui ele torna as grandes divulgações inspecionáveis em vez de tudo-ou-nada.

O que um registro selado de fato prova?

As afirmações são fortes, mas são específicas. Um registro Label 309 selado pode mostrar:

que aqueles dados exatos existiam até um horário de bloco público;
que o texto cifrado decifrado corresponde ao hash do texto claro fixado pelo compromisso;
que uma chave específica assinou o registro, se o registro estiver assinado;
que um arquivo específico foi incluído em um conjunto de provas agrupado por Merkle;
que um destinatário que detém a chave e o texto cifrado teve acesso a provas decifráveis.

Cada uma delas é uma afirmação precisa e verificável de forma independente sobre tempo e integridade.

O que ele não prova?

Tão importante quanto, eis o que ele não estabelece:

Não prova que as provas são verdadeiras. Uma prova certifica bytes e tempo, não fatos.
Não prova que o remetente tinha o direito legal de divulgar o arquivo.
Não prova a identidade real do destinatário, a menos que o endereço de recebimento tenha sido verificado por um processo confiável. Confirmar quem realmente é dono de um endereço é uma etapa separada — veja verifique um destinatário antes de selar um arquivo.
Não fornece anonimato. Padrões de tempo, metadados de rede, rastros de gateway e de pagamento, impressões digitais de dispositivo e erros operacionais podem todos revelar informações que vivem fora do registro. Um destinatário também pode vazar o texto claro depois de tê-lo decifrado.
Não substitui aconselhamento jurídico nem procedimentos de divulgação segura, e se uma dada prova ajuda em uma disputa depende da jurisdição.

Para a versão geral desse limite, veja o que uma prova não prova.

Como uma equipe deve preparar isso antes de precisar?

Defina o fluxo de divulgação antes da crise, não durante ela. Decida com antecedência:

quem pode criar divulgações seladas;
qual identidade, se houver, assina registros formais;
quais endereços de recebimento são confiáveis, e como foram verificados;
onde o texto cifrado é armazenado;
quem tem permissão para decifrar;
como os manifestos são estruturados para pacotes de múltiplos arquivos;
como as referências de transação são registradas e repassadas;
como as provas são exportadas para a revisão jurídica.

A criptografia é apenas uma camada. O processo ao redor é o que determina se a prova é de fato útil quando a pressão chega. Para uma perspectiva de tratamento de provas, veja provas jurídicas e e-discovery e, para fontes de maior risco, provas de denunciantes.

A versão curta

A divulgação confidencial precisa de duas coisas ao mesmo tempo: privacidade e prova.

Registros Label 309 selados mantêm o arquivo cifrado para detentores de chave escolhidos enquanto publicam um compromisso público com carimbo de tempo sobre o seu hash. Os destinatários decifram localmente e confirmam que o texto claro corresponde ao hash na cadeia. Assinaturas, raízes Merkle e compartimentos para múltiplos destinatários acrescentam opções de fluxo mais robustas quando você precisa delas.

Use-os para provar a linha do tempo sem nunca publicar o arquivo.

Leitura complementar

Label 309 — o padrão aberto e neutro quanto ao fornecedor de Proof of Existence por trás dos registros selados. Label 309 é o rótulo de metadados na cadeia; a proposta está em análise no processo de CIP da Cardano como um CIP da categoria Metadata (PR aberto).
CardanoWall open source — o corpus do padrão, os SDKs e a ferramenta de linha de comando cardanowall, capaz de montar, selar e verificar registros.
O que uma prova não prova — os limites de qualquer Proof of Existence.
Verifique um destinatário antes de selar um arquivo — o erro humano mais comum em fluxos cifrados.