A camada de privacidade da Newton faz uma alegação de segurança precisa: quando dados privados são criptografados e enviados, o texto cifrado é criptograficamente vinculado a uma política específica e a uma cadeia específica.
Tente reenviar esse mesmo envelope criptografado em outro lugar — uma política diferente, uma cadeia diferente — e a verificação de autenticação falha completamente.
A descriptografia é recusada. Eu queria ver exatamente o que "vinculado a" cobre e, igualmente importante, o que não cobre.
Aqui está a fórmula real.
Os dados adicionais autenticados anexados à criptografia são calculados a partir exatamente de duas entradas: o cliente da política e o ID da cadeia, combinados e convertidos em hash juntos.
Esse hash passa a fazer parte daquilo que o algoritmo de criptografia autentica junto com o próprio texto cifrado.
Se qualquer uma das entradas mudar — uma política diferente, uma cadeia diferente — a tag de autenticação inteira é quebrada, e o algoritmo se recusa a descriptografar.
Isso é uma garantia forte e bem delimitada, e é exatamente o tipo de proteção que você gostaria contra alguém tentando levantar um payload cifrado válido e reutilizá-lo em um contexto para o qual ele nunca foi destinado.
Mas a chamada de upload que carrega esse texto cifrado não carrega apenas o texto cifrado e esses dois valores vinculados.
Ele também carrega um time-to-live — um valor que determina por quanto tempo esse pedaço de dados deve permanecer válido ou recuperável antes de expirar.
E quando verifiquei o que de fato entra na fórmula dos dados autenticados, o TTL não está nela.
A fórmula cobre exatamente duas coisas: cliente de política, ID da cadeia. Nada mais.
Essa é uma distinção real, não uma mera questão técnica. Um campo autenticado é aquele em que adulterar algo quebra a prova criptográfica e é detectado automaticamente.
Um campo não autenticado é aquele que o sistema simplesmente confia como declarado, porque nada na própria criptografia está observando isso.
O cliente de política e o ID da cadeia ficam na primeira categoria.
O TTL, com base no que está documentado, fica na segunda.
Isso levanta uma pergunta específica e testável: se alguém com a capacidade de interceptar ou reenviar essa requisição de upload alterasse apenas o TTL — deixando o texto cifrado, o cliente de política e o ID da cadeia completamente intocados — a checagem de autenticação sequer perceberia?
Com base na fórmula como está escrita, não.
O texto cifrado ainda seria descriptografado sem problemas, porque nada da manipulação do TTL afeta os dois valores que o algoritmo realmente está verificando.
Os dados ainda seriam exatamente o que o remetente original cifrou. Apenas o tempo de validade (vida útil) mudaria silenciosamente.
Isso importa mais do que pode parecer à primeira vista, porque o TTL não é mera metadado cosmético — é um controle de segurança por si só.
Presumivelmente, é o que limita por quanto tempo um pedaço de dados sensíveis e cifrados permanece algo com que o sistema ainda vai agir, ainda vai recuperar, ainda vai tratar como atual.
Um TTL encurtado poderia fazer dados legítimos expirarem cedo e falharem silenciosamente fluxos de trabalho que dependem disso.
Uma versão estendida poderia manter dados sensíveis vivos e recuperáveis bem depois de a parte original ter pretendido que isso importasse.
Nenhuma delas exige quebrar a criptografia.
Nenhuma das duas dispara a única verificação de integridade que o sistema está documentado a executar.
Quero ser preciso sobre o que não estou afirmando.
Não sei se essa lacuna é realmente explorável de ponta a ponta — isso depende de coisas que a documentação não cobre, como se o Gateway compromete independentemente o TTL on-chain no momento do upload de um jeito que não possa ser alterado depois, se a própria requisição de upload viaja por um canal com proteção de integridade em nível de transporte que detectaria adulteração antes mesmo de chegar a esta camada, ou se o TTL é tratado como algo apenas consultivo e não como algo crítico para a segurança em si.
Qualquer uma dessas coisas poderia fechar a lacuna completamente, e nenhuma delas apareceria na própria fórmula de AAD, porque seriam proteções em camadas acima dela, e não dentro dela.
Então a questão em aberto é exata: o valor do TTL é comprometido em algum lugar de forma imutável e verificável no momento do upload — on-chain, ou dentro de alguma outra estrutura autenticada — ou ele é aceito à vista como um parâmetro da chamada de RPC, confiado do mesmo jeito que qualquer campo de requisição não autenticado é confiado?
A documentação é precisa sobre o que a própria criptografia protege.
Não diz nada sobre o que protege o valor limitado por tempo único que determina por quanto tempo essa proteção sequer deve durar.