Foi lançado o Ad Nihilum 0.4.3 — um serviço minimalista para troca de mensagens criptografadas no princípio de "leu — queimou", voltado principalmente para self-hosting.
O servidor atua apenas como um repositório cego. A criptografia e decriptação ocorrem exclusivamente do lado do cliente, no navegador (via AES-GCM).
Características
- criptografia e decriptação local, servidor nunca vê a chave;
- suporte para um nível adicional de criptografia por senha, que (1) o servidor não pode saber, (2) não pode ser identificado pela URL transmitida;
- o projeto contém cerca de 2200 linhas de código do servidor em C e 600 linhas de código do cliente em JS, facilitando a auditoria;
- Ad Nihilum depende apenas do libmicrohttpd. Para a geração de códigos QR, uma versão modificada do QRCode.js é fornecida;
- inclui um guia para o rápido levantamento do serviço local sem IP externo;
- Ad Nihilum funciona também no Android, um script correspondente para compilar no Termux é fornecido;
- servidor de thread única e síncrono.
Mudanças
Re-design abrangente
- As páginas de envio e recebimento de mensagens foram separadas, o código do cliente correspondente.
- No geral, o design foi amplamente alterado e ajustado com base nas sugestões dos usuários do lorchany.
- Clientes "simples" e locais:
- As páginas do cliente podem ser salvas localmente e usadas a partir de file://.
Políticas do navegador
- CSP foi implementado para combater XSS;
- o servidor envia HSTS.
Outras mudanças
- o projeto foi renomeado de Epha-ots;
- o domínio adnihilum.net foi adquirido;
- TLS é fornecido por meio do Let’s Encrypt, é importante ter isso em mente (sem dinheiro);
- facilitado o trabalho com arquivos;
- transição para fat-pointers;
- pequenos bugs foram corrigidos;
- auto-jsminify e compilação de arquivos do cliente ao compilar via CMake.
Visão geral do protocolo
Gerar três valores aleatórios: uma chave K, um vetor de inicialização N e um sal S. K — 256 bits, N — 96 bits, S — 128 bits.
Retirar ID do K e S usando HKDF baseado em SHA-256.
Formar uma string de dados adicionais autenticados aad — é apenas uma string do tipo: id=ID
Se o usuário definiu uma senha:
- exibir Pk da senha e S usando PBKDF2, SHA-256, 800000 iterações;
- o mesmo sal é usado para tudo;
- criptografar os dados usando AES-GCM, utilizando a chave Pk, IV/nonce N e transmitir aad.
Adicionar uma tag de dois bytes aos dados já criptografados, se uma senha foi usada, ou aos dados originais, se não houve senha.
O primeiro byte tem o valor: ele indica se os dados foram criptografados com uma senha:
- 0x73 — os dados estão criptografados com uma senha;
- 0x13 — os dados não estão criptografados com uma senha.
O segundo byte é um valor constante 0x37.
Recriptografar o resultado usando AES-GCM, utilizando o mesmo iv = N e o mesmo aad. Isso gera o texto criptografado final. — backup de um contêiner;.
Concatenar os bytes em uma string: blob = N .. S .. ct
Enviar blob para o servidor junto com ID. O servidor retorna blob por esse ID e não pode ser substituído: o cliente verificará primeiro ID usando N e K antes da descriptografia e, em seguida, através de aad.
O cliente armazena K. K nunca é enviado ao servidor. Pk tampouco é enviado; tudo relacionado à senha é removido da memória.
O cliente forma um link: origin/#ID/K
Aqui ID e K — strings no formato base64url.
Quando o destinatário abre o link:
- o navegador descarta tudo que começa com #; isso é chamado de location.hash;
- o aplicativo cliente é carregado do servidor;
- na minha opinião, essa é a principal falha: na verdade, voltamos à questão de que "TLS é falho;"
- no entanto, nada impede de manter o cliente offline;
- idealmente, deve haver um cliente standalone separado.
O JavaScript do cliente verifica o location.hash e, se houver ID e K, ele carrega os dados do servidor.
Em seguida, ele os verifica, descriptografa e, se necessário, solicita a senha e descriptografa mais uma vez.
Licença
O projeto é distribuído sob a GPLv3.
Fonte: linux.org.ru
