Por que a KeysArk precisa ser de código aberto — e por que os backups carregam um número de versão

“Criptografado de ponta a ponta” é uma afirmação. O código aberto é o que a transforma em algo que você pode de fato verificar.

Confie, mas verifique

Se você não consegue ler o código, “nós nunca vemos seus dados” é apenas marketing. O código aberto permite que qualquer pessoa confirme que não há backdoor: que a chave é realmente derivada no navegador, que o texto em claro realmente nunca chega ao servidor. Segurança que não pode ser auditada não é segurança — é fé.

O problema de que ninguém fala

A autocustódia tem um problema de cauda longa. Você criptografa um backup hoje e depois vai abri-lo daqui a cinco ou dez anos — mas até lá o site pode já não existir, as bibliotecas podem ter mudado, os algoritmos podem ter sido ajustados. Um backup que você não consegue mais descriptografar não é um backup.

Por isso os backups carregam sua própria proveniência

Cada backup de frase mnemônica que a KeysArk exporta (PDF e HTML) incorpora um manifesto de proveniência descrevendo exatamente o que o produziu:

• A versão do ark CLI, e o repositório de origem + hash do commit.
• O horário da compilação e a versão do Node.js.
• As versões exatas das bibliotecas de criptografia (hash-wasm, @scure/bip39, @noble/hashes).
• A especificação criptográfica completa: frase BIP39 de 24 palavras, seed → HKDF-SHA256 → AES-256-GCM, e os parâmetros do Argon2id.

Por que o número de versão importa

Com esse manifesto, o você do futuro pode fazer checkout do commit exato que gerou o backup, reproduzir o ambiente de compilação e descriptografar — mesmo décadas depois, mesmo que keysark.com já não exista. O número de versão não é burocracia; é o mapa de volta ao ambiente de execução que ainda consegue abrir seu cofre.

O código aberto prova que não há backdoor hoje. A proveniência prova que você ainda conseguirá entrar amanhã.