AES-256-GCM · chave do cofre
Chave do cofre trancada
Cada item é cifrado com AES-256-GCM e uma chave do cofre. No servidor, essa chave só existe trancada com a chave pública RSA-OAEP 3072 do usuário, e o servidor não consegue abri-la.
Segurança
Segurança do Vaukt: cofre que só você abre, envio direto e antiescâner
Cada camada resolve uma falha conhecida dos gerenciadores de senha e dos sistemas de envio direto. Esta página traz o detalhe técnico, com termos explicados ao lado.
Cofre permanente
Como o cofre é protegido, camada por camada.
A chave do cofre, a validação de cada bloco, a chave de recuperação, a transferência e os dados cedidos, sem que o servidor consiga ler.
Dado autenticado · id + tipo
Cada bloco é amarrado ao item
O id e o tipo do item entram como dado autenticado (AAD) no AES-GCM. Se um bloco for trocado de lugar ou de tipo, a leitura falha. O servidor não embaralha o cofre sem que isso apareça.
Chave de 32 caracteres
Chave de recuperação
Mostrada uma única vez, ao criar o cofre, ela o reabre se a senha for redefinida. Sem ela e sem a senha, ninguém abre o cofre, nem o Vaukt. Perdeu os dois? Apague o cofre e comece outro.
RSA-OAEP 3072 · código de 16 dígitos
Transferência entre usuários
O navegador cifra o item com a chave pública do destinatário, que só ele abre. O remetente confere o código de segurança de 16 dígitos. O servidor guarda um bloco ilegível. O remetente é o dono: escolhe a validade e se o destinatário pode guardar no cofre.
Referência · só leitura
Dado cedido por terceiros
Quando o dono permite, o item aparece em "Cedidos", só para leitura, como referência ao dado do dono e não como cópia solta. Se ele cancelar a permissão, o item some do cofre na hora.
Hard delete · sem lixeira
Apagar é apagar de verdade
Itens apagados do cofre não vão para lixeira. Numa transferência, o bloco sai do banco quando o remetente cancela, quando o destinatário recusa ou quando a validade acaba.
Limpeza em 30 s
Área de transferência limpa
Depois de copiar uma senha, o cofre limpa a área de transferência em 30 segundos, para a senha não ficar esperando para ser colada em outro lugar.
Camadas de proteção
Oito camadas, cada uma com um problema para resolver.
Da proteção no aparelho à destruição de verdade do link: o que cada tecnologia faz e por que ela está ali.
AES-256-GCM · RSA-OAEP 3072
Protegido no seu aparelho
Itens do cofre e textos são cifrados com AES-256-GCM antes de sair do aparelho. Cada link tem uma chave própria, trancada com RSA-OAEP 3072 para cada destinatário ou enviada depois do # do endereço (#k=), que o navegador não manda ao servidor.
PBKDF2 · HKDF
A senha nunca viaja
A senha passa por PBKDF2-SHA256, com 600 mil iterações (o e-mail serve de sal). Dela saem, por HKDF, um segredo de login e a chave que sela a sua chave privada. A privada fica selada no banco e, aberta, só existe no navegador (IndexedDB, não extraível).
WebRTC · DTLS
Arquivo de um aparelho ao outro
O arquivo segue por um canal cifrado (RTCDataChannel). Cada pedaço leva sessão, contador e posição no cabeçalho, que entra como dado autenticado no AES-GCM. O vetor de inicialização nunca se repete, e a posição não pode ser alterada.
Pedaços de 16 a 256 KB
Envio em pedaços que se ajustam
O navegador lê o arquivo com File.slice() e ajusta o pedaço conforme a fila do canal. O destinatário confirma o que gravou, e o remetente nunca mantém mais de 32 MB em trânsito. A File System Access API grava cada pedaço direto no disco.
Redis sem persistência
Espera na memória (RAM)
Com o destinatário offline, o envio espera cifrado na RAM do servidor. O relay guarda só bytes ilegíveis, apaga cada pedaço ao entregar e aplica teto de memória por sala e expiração automática. Se a conexão cair, o envio continua do último byte confirmado.
TURN sobre TLS · porta 443
Atravessa firewalls corporativos
Quando as conexões diretas estão bloqueadas, o envio sobe por TURN sobre TLS na porta 443, a do HTTPS. Ele só repassa pacotes cifrados, sem ler nem gravar, e usa credenciais temporárias.
Anti-link spoiling
Mecanismo antiescâner
Abrir o link nunca gasta nada. Revelar exige botão pressionado com interação humana real, desafio assinado (HMAC) com prazo, mesma origem e, se ativado, código de confirmação (OTP) com limite de tentativas.
Hard delete
Destruição de verdade
O DELETE é real, sem soft delete: o token é invalidado, e o bloco cifrado e as chaves trancadas saem do banco. A sala do relay cai e o destinatário descarta o parcial. Até o VACUUM remover a linha, resta só texto cifrado, sem chave no servidor.
Travas contra interceptação
Proteção que só aparece quando algo está errado
Pensadas para não acrescentar passos ao usuário.
Código de segurança de 16 dígitos
O navegador do profissional calcula o código da própria chave e o envia no link, em parte que não passa pelo servidor. A página do cliente confere a chave. Se não bater, bloqueia o envio, registra o evento e avisa por e-mail.
Ver o Fluxo de EntradaCSP com nonce
Cada requisição ganha um nonce, e scripts injetados não executam, então não chegam às chaves no navegador. A política também restringe conexões à própria origem e ao relay e bloqueia o uso em frames.
Ver a privacidadeTetos de OTP e limites por IP
Há tetos de tentativas por código e por link: ao atingir o limite, o link é destruído e o remetente é avisado. O código chega por e-mail. Ações sensíveis também têm limite por IP.
Ver o Fluxo de SaídaZero-knowledge na prática
O que o servidor guarda e o que ele nunca vê.
O Vaukt guarda blocos cifrados, chaves públicas e chaves trancadas. Nada que permita ler o conteúdo.
| Item | O que o Vaukt guarda | O que o Vaukt nunca vê |
|---|---|---|
| Itens do cofre | Blocos cifrados (AES-256-GCM) ligados ao id e ao tipo do item | O conteúdo do item em claro |
| Chave do cofre | Só trancada com a chave pública RSA-OAEP 3072 do usuário | A chave do cofre aberta: o servidor não consegue destrancá-la |
| Chave de recuperação | Nada em claro: ela é mostrada uma única vez, ao criar o cofre | A chave de recuperação |
| Transferências entre usuários | Um bloco ilegível, pela validade escolhida pelo remetente; depois, apagado de verdade | O item em claro: só o destinatário o abre |
| Dado cedido no cofre | Só o vínculo com o dado do dono, enquanto ele permitir | O conteúdo em claro |
| Credenciais e textos dos links | Blocos cifrados ilegíveis (AES-256-GCM) e metadados do link | O texto em claro e a chave de leitura |
| Arquivos | Nada: vão de um aparelho ao outro. No máximo bytes cifrados na RAM até a entrega | O conteúdo do arquivo |
| Senha do usuário | Um segredo derivado dela, que o servidor ainda passa por scrypt | A senha em si e a chave que sela a chave privada |
| Chave privada | A chave privada selada, ilegível sem a senha | A chave privada aberta |
| Chave de leitura do link | Chaves trancadas para as chaves públicas autorizadas | A chave de dados em claro: ela vai depois do # da URL, que o navegador não envia |
Perguntas frequentes
Dúvidas sobre segurança Respostas técnicas.
O Vaukt consegue ler minhas senhas e arquivos?
+
Não. A criptografia acontece no navegador (AES-256-GCM, com um par de chaves RSA-OAEP 3072 por usuário), e o servidor guarda só blocos ilegíveis, chaves públicas e chaves trancadas, inclusive a do cofre. Arquivos vão direto de um aparelho ao outro ou, com o destinatário offline, esperam cifrados na memória (RAM).
O Vaukt consegue ler minhas senhas e arquivos?
+
Não. A criptografia acontece no navegador, e o servidor recebe só blocos cifrados, chaves públicas e chaves trancadas, inclusive a do cofre. Sua chave privada fica selada por uma chave derivada da sua senha, que nunca sai do seu aparelho.
O titular da conta consegue ler o que os clientes enviam?
+
Sim, nos dados enviados pelo Fluxo de Entrada: o titular da conta guarda uma cópia da chave, para o dado não se perder se quem pediu sair da equipe. O cliente pode retirar todo o acesso pelo link de controle dele. Com aprovação dupla, ninguém lê sozinho. O Vaukt continua sem acesso ao conteúdo.
Como a chave do cofre é protegida?
+
No servidor, a chave do cofre só existe trancada com a sua chave pública RSA-OAEP 3072, e o servidor não consegue abri-la. Cada item é cifrado com AES-256-GCM e validado com o id e o tipo dele, então um bloco trocado de lugar não abre.
O que é a chave de recuperação do cofre?
+
Uma chave de 32 caracteres, mostrada uma única vez ao criar o cofre, que o reabre se a senha for redefinida. Sem ela e sem a senha, ninguém abre o cofre, nem o Vaukt. Guarde-a em lugar seguro. Se perder os dois, apague o cofre e comece outro.
O que acontece se eu redefinir a minha senha?
+
A redefinição gera um par de chaves novo, então credenciais recebidas antes deixam de abrir. O cofre se reabre com a chave de recuperação. O Vaukt avisa nas telas de redefinição e no login, e a troca só vale logo após um login, dispara e-mail e fica registrada.
Como chega o código de confirmação (OTP)?
+
Por e-mail, em todos os planos.
Funciona atrás de firewall corporativo?
+
Sim. Quando a conexão direta é bloqueada, o tráfego passa por um servidor TURN sobre TLS na porta 443. Ele só repassa pacotes cifrados, sem ler nem gravar em disco.
O escâner de e-mail da empresa pode queimar o link?
+
Não. Abrir o link nunca gasta nada: a página só mostra uma confirmação mecânica. Robôs como Microsoft Defender Safe Links, Barracuda e Proofpoint recebem só essa tela e não conseguem revelar o conteúdo.
Como o link é apagado de verdade?
+
O token é invalidado, o registro e as chaves trancadas saem com DELETE real (sem soft delete), a sala do relay cai e o buffer é apagado. O Postgres remove a linha de vez no VACUUM. Até lá, existe só texto cifrado, sem chave no servidor.
Quais navegadores gravam o arquivo direto no disco?
+
Chrome e Edge, pela File System Access API. No Firefox e no Safari, o arquivo é montado na memória antes de salvar.
Teste o cofre e o seu primeiro link.
Crie sua conta, guarde uma senha no cofre e envie um link. Arquivos de até 10 GB.