Política de segurança

O Herkos lida com chaves privadas e mensagens criptografadas, por isso levamos a sério os relatos de segurança e preferimos saber de um problema cedo do que tarde.

Como relatar uma vulnerabilidade

Por favor, não abra uma issue pública para problemas de segurança.

Relate-o de forma privada por e-mail para security@herkos.email.

Coisas úteis para incluir: qual é o problema, como reproduzi-lo, em qual plataforma e versão você testou e o que um atacante poderia conseguir. Uma prova de conceito ajuda muito.

Nunca inclua num relato sua própria nsec, sua chave secreta ou o segredo do seu bunker.

Procuramos confirmar o recebimento dos relatos em poucos dias. Como o Herkos é um projeto pequeno, por favor, dê um prazo razoável para a correção antes de divulgar publicamente. Teremos prazer em dar crédito a você no aviso de segurança, a menos que prefira o contrário.

O que está no escopo

O próprio aplicativo Herkos: o tratamento e o armazenamento de chaves, a criptografia e descriptografia de mensagens (incluindo as verificações de remetente do NIP-59 e o isolamento do Cco em local_packages/nostr_mail), o bloqueio do aplicativo, a comunicação com relays e bridges, o tratamento de anexos e o processo de compilação e publicação. No Herkos Drive, também o pacote do protocolo dele (packages/herkos_drive_protocol) e a página que abre os links dele (herkos.app/f/); veja a seção própria dele mais abaixo.

O que está fora do escopo

• O próprio protocolo Nostr e seus NIPs — relate esses problemas na origem.
• Relays, bridges e servidores Blossom operados por terceiros. O Herkos vem com padrões, mas não os opera; relate os problemas aos seus operadores.
• O projeto original Nostr Mail Client, a menos que o problema seja específico das mudanças feitas no Herkos.
• A falta de um reforço que já documentamos como limitação conhecida (ver abaixo).

Limitações conhecidas, ditas com clareza

Estas são escolhas de projeto, não vulnerabilidades. Preferimos deixá-las por escrito a alguém descobri-las do pior jeito:

• O e-mail para endereços tradicionais não é criptografado de ponta a ponta. As mensagens entre usuários do Nostr usam gift wrap NIP-17 e são criptografadas de ponta a ponta. Quando você escreve para um endereço de e-mail comum, um bridge converte a mensagem e consegue lê-la.
• O bloqueio do aplicativo (PIN e biometria) é uma barreira de conveniência, não criptografia em repouso. Ele detém quem pega um dispositivo desbloqueado; não protege contra um atacante com acesso total ao dispositivo ou ao seu armazenamento.
• No Windows, não é possível exigir apenas a autenticação biométrica. O Windows Hello não permite escolher o método, então o PIN do sistema sempre continua disponível como alternativa.
• Perder sua chave significa perder a conta. Não há recuperação, de propósito.
• Os metadados não ficam totalmente ocultos. Os relays podem observar padrões de conexão, e todo relay vê seu endereço IP, mesmo quando não consegue ler o conteúdo das mensagens. O que o Herkos não entrega (desde 30-09-2026) é quem está escrevendo para quem quando um relay pede autenticação NIP-42:
• Descobrir para onde entregar. As listas de relays e de servidores Blossom de um destinatário são pedidas por uma conexão separada que nunca identifica você, primeiro em relays que não exigem autenticação (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Perfis e o agendador. O nome e a imagem exibidos para qualquer outra pessoa (kind 0), e a lista de relays do DVM de agendamento quando você agenda ou cancela um e-mail, são pedidos da mesma forma: primeiro de modo anônimo e, se um relay insistir, com a chave temporária descrita abaixo, nunca com a sua (desde 01-10-2026; antes, um relay que pedia autenticação recebia sua chave e podia saber de quem era o perfil que você estava vendo). Apenas o seu próprio perfil continua sendo lido como você.
• Entregar. Os gift wraps vão para os relays de DM do destinatário, por essa mesma conexão separada. Se algum deles exigir autenticação, o Herkos responde com uma chave criada para esse fim e mantida só na memória, nunca com a sua; cada conta no dispositivo tem a sua. O relay ainda consegue ver que o mesmo dispositivo (mesmo IP, mesma chave temporária) enviou vários envelopes durante uma sessão.
• E-mails grandes. A cópia criptografada de um e-mail com mais de 32 KB é enviada a servidores Blossom, inclusive os dos destinatários. Só os seus próprios servidores (a sua lista Blossom) recebem o envio autorizado com a sua chave. Qualquer outro servidor o recebe de forma anônima e, se insistir numa autorização, uma assinada com a mesma chave temporária de antes (desde 01-10-2026; antes, todos os servidores recebiam sua chave). Um servidor que só aceita chaves conhecidas o recusa, e a cópia fica nos outros servidores.
• Seus próprios dados. A sincronização da sua caixa postal, etiquetas, configurações e rascunhos se autentica, quando um relay pede, como a conta a que os dados pertencem, mesmo durante uma troca de conta. Nos seus próprios relays isso não lhes diz nada que eles já não soubessem: os pedidos citam sua chave de qualquer forma. Suas próprias listas de relays e de servidores Blossom são públicas e são pedidas sem identificar você, assim como os relays citados num link de e-mail.
• O estado de leitura e as pastas são metadados públicos (por enquanto). Marcar um e-mail como lido, favorito, arquivado ou movido publica um evento de etiqueta NIP-32 não criptografado, ligado à sua chave pública, inclusive os nomes das pastas personalizadas. Um remetente que conhece o identificador de um e-mail que te enviou consegue saber quando você agiu sobre ele. Criptografar essas etiquetas está nos planos; até lá, trate os nomes das pastas como públicos.
• As notificações push e o envio agendado usam serviços de terceiros. O servidor push, se você escolher um (nenhum por padrão; api.nmail.li com relay.nmail.li se você pedir), fica sabendo sua chave pública, um token push e quando você recebe e-mail; o DVM de agendamento fica sabendo sua chave pública e as mensagens já criptografadas que ele precisa publicar. Os dois são opcionais e estão documentados em PRIVACY.md. O texto de uma notificação push é escolhido pelo servidor push, e o Herkos só confia nele quando o UnifiedPush o entrega criptografado (RFC 8291); um conteúdo não criptografado apenas acorda o aplicativo para que ele mesmo busque o e-mail.
• A versão web guarda sua chave no navegador, que é o lugar mais fraco para ela. Os aplicativos instalados entregam sua chave secreta ao armazenamento seguro do sistema operacional (Android Keystore, DPAPI no Windows, libsecret, Chaveiro do iOS/macOS). Um navegador não tem nada disso: a chave fica no armazenamento da origem e passa pelo JavaScript a cada assinatura, ao alcance de qualquer código que rode na página — uma extensão do navegador com acesso a todos os sites, uma falha de XSS no aplicativo ou numa dependência, uma implantação adulterada — e de qualquer infostealer que copie o perfil do navegador. Também não existe um momento em que você verifica o código uma vez: um binário assinado é verificado na instalação, enquanto uma página web entrega código novo a cada visita. Entre na versão web com um assinador remoto (bunker NIP-46, Amber), para que a chave nunca chegue ao navegador, ou trate-a como uma identidade descartável e mantenha sua chave real num aplicativo instalado.
• O e-mail que passa por um bridge só é tão confiável quanto o bridge. O Herkos verifica se uma mensagem marcada como vinda por um bridge foi mesmo assinada por um bridge que você configurou (ou por um dos padrões). Ele não consegue verificar nada sobre o endereço From: tradicional que o bridge repassa.
• Os anexos são abertos pelo sistema operacional. O Herkos nunca executa tipos de arquivo executáveis ou de script e pergunta antes de entregar qualquer outro anexo sem pré-visualização ao aplicativo padrão do sistema, mas o aplicativo que abre o arquivo está fora do nosso controle.

Herkos Local Relay: o que ele protege e o que não protege

O Herkos Local Relay guarda no seu dispositivo os eventos dos seus aplicativos, inclusive os privados (rascunhos, listas privadas, os envelopes que você recebe). Isto é o que os protege e onde fica o limite, plataforma por plataforma. Problemas de segurança do relay são relatados do mesmo jeito que os outros (acima).

O banco de dados é criptografado por inteiro, inclusive o journal (SQLite3 Multiple Ciphers, AEGIS-256). A chave são 32 bytes aleatórios criados no dispositivo e guardados no armazenamento seguro do sistema: o Keystore no Android, a DPAPI no Windows, o chaveiro (libsecret) no Linux. Ela não depende de nenhuma senha sua, porque o relay precisa iniciar sozinho. Sem a chave, o relay não inicia e avisa: ele nunca abre nem cria um banco não criptografado, e nunca apaga o que não consegue abrir.

No computador, o limite da DPAPI e do chaveiro é o de qualquer programa: eles protegem contra outros usuários e contra quem leva o disco, não contra um programa malicioso que já roda com o seu usuário. Se esse caso te preocupa, o que protege é a criptografia do disco do sistema (BitLocker, LUKS) junto com não rodar programas em que você não confia. Num Linux sem chaveiro (sem Secret Service), o relay não inicia e explica por quê: ele nunca guarda a chave em texto puro.

Quem entra, no próprio dispositivo. O relay só escuta em 127.0.0.1, e qualquer aplicativo do dispositivo, ou uma página web no navegador, consegue alcançar esse endereço. Por isso:

• Um aplicativo precisa ser pareado: ele aparece na tela do relay e você o aprova (com o PIN ou a impressão digital, se você os definiu). Qualquer aplicativo pode se dar qualquer nome: só aprove se você acabou de pedir isso nesse aplicativo.
• Uma página web sempre é pareada, e um pareamento só vale a partir de onde foi feito: o de um aplicativo do dispositivo não abre nada para uma página web, mesmo que ela assine com a mesma chave.
• Um aplicativo pareado só lê e escreve os tipos de evento que você liberou para ele, e só apaga os que pode escrever. Revogá-lo o desconecta na hora.
• Um aplicativo não pareado só lê seus eventos públicos (que já são públicos) e não escreve nada, a menos que você ative a configuração que deixa entrar os aplicativos do dispositivo não pareados.
• Os eventos privados só são entregues a quem provar com NIP-42 que tem a chave a que eles pertencem, e um envelope, só ao seu destinatário.

O que ele não protege, aqui:

• Um aplicativo malicioso no dispositivo pode deixar o relay lento ou fazê-lo gastar memória. Com isso, ele não consegue ler nada privado.
• Enquanto o relay dorme ou não está rodando, a porta fica livre. No Android, ele dorme depois de 10 minutos sem conexões; no computador, a porta fica livre enquanto você não o inicia. Outro aplicativo poderia escutar ali e se passar por ele. Os aplicativos Herkos vão verificar a chave do relay antes de enviar a ele qualquer coisa privada; eles ainda não fazem isso, e até lá esse é um limite real.
• No computador, outros usuários da máquina podem se conectar como um aplicativo não pareado: ler seus eventos públicos e pedir pareamento.

A rede local, se você ativá-la (ela vem desativada):

• Só wss://, com um certificado próprio do relay; nunca ws:// não criptografado fora do dispositivo.
• Nada antes de se autenticar (NIP-42) com uma chave da sua lista. Uma conexão que não fizer isso em 30 segundos é fechada, e a rede local tem um número de conexões próprio: ela nunca ocupa as dos aplicativos do dispositivo.
• Uma chave da lista lê seus eventos públicos e os privados dela, e só escreve eventos assinados por ela. Tirá-la da lista a desconecta.
• O certificado só vale para nomes de casa (localhost, .local, endereços privados): mesmo que alguém roubasse a chave dele, ela não serviria para assinar um domínio da Internet nos aparelhos que o instalaram.

O que ele não protege, aqui: quem está na mesma rede vê que o aparelho tem uma porta aberta e quanto tráfego passa, mas não o que passa; e se o aparelho tem um endereço público (sem roteador no meio), essa porta fica visível na Internet, embora continue pedindo uma chave da sua lista.

Cópias. A cópia criptografada tem senha (scrypt e XChaCha20-Poly1305): sem ela ninguém consegue abri-la, nem nós. A exportação JSONL não é criptografada e contém seus eventos privados em texto puro; o aplicativo avisa.

O bloqueio (PIN, e impressão digital ou Windows Hello) é pedido ao abrir o aplicativo, depois de 30 segundos fora, e para aprovar um pareamento. É uma barreira de conveniência, como no Mail: ele não criptografa nada. No Android, com PIN definido não há capturas de tela nem miniatura nos aplicativos recentes, e desde o Android 12 nenhuma janela de outro aplicativo pode ficar por cima da do relay enquanto você o usa.

Herkos Drive: o que ele protege e o que não protege

O Herkos Drive guarda seus arquivos em servidores Blossom e a lista dos seus arquivos e pastas em relays Nostr, ambos criptografados no seu dispositivo. Isto é o que os protege e onde estão os limites. O detalhe completo está em spec-drive.md e no modelo de ameaças amenazas-drive.md, em packages/herkos_drive_protocol/; o que cada relay e servidor vê está na política de privacidade. Relate os problemas de segurança do Drive da mesma forma que qualquer outro (acima).

O que os relays e servidores não conseguem fazer:

• Ler seus arquivos ou os nomes deles. Cada bloco de um arquivo é criptografado com AES-256-GCM sob uma chave própria da sua revisão; nomes, pastas, tamanhos, datas e chaves vão selados com XChaCha20-Poly1305 sob a chave da pasta em que estão. Nada é derivado do conteúdo: o mesmo arquivo enviado duas vezes gera blocos diferentes.
• Alterar, trocar ou mover algo sem que se perceba. Cada bloco é conferido com o manifesto selado na entrada do seu arquivo, e cada entrada é assinada pela chave do volume e selada para o seu próprio lugar (volume, identificador e pasta): um relay não consegue fazer uma entrada passar por outra, nem um bloco por outro.
• Trazer de volta uma versão antiga. O aplicativo nunca aceita uma entrada mais antiga do que a que ele já tem para o mesmo identificador.
• Escrever como você só com a chave do volume. O que seus dispositivos escrevem leva a marca do dono, um HMAC com uma chave que nenhum link dá; uma entrada ou uma exclusão sem ela não é aceita, e o aplicativo avisa você.

O que ele não protege:

• O padrão do seu Drive. Os relays podem contar seus arquivos e pastas, ver a forma da árvore e quando cada entrada muda; os servidores veem mais ou menos o tamanho de cada arquivo (os blocos são preenchidos até 64 KiB, as entradas até uma potência de dois). Cada relay e servidor vê seu endereço IP. Use Tor ou Orbot no nível do sistema se isso importa para você.
• O que alguém já baixou. Remover um link, ou uma pessoa, troca na hora as chaves do que ela podia abrir, então ela não abre o que você adicionar depois; não dá para tomar de volta o que ela já salvou.
• Um link vazado. Um link sem senha é a chave. O navegador pode guardá-lo no histórico antes que a página o tire da barra de endereço. Para qualquer coisa sensível, dê ao link uma senha, enviada por outro meio, ou compartilhe com a conta da pessoa. Uma senha fraca pode ser quebrada com tempo: quem tem o link pode tentar offline.
• A página herkos.app/f/ roda no navegador de quem abre um link. Ela é servida com uma Content-Security-Policy estrita, Subresource Integrity e nenhum código de terceiros, mas quem controla a hospedagem web poderia servir uma página diferente. Esse é o limite de toda página web que descriptografa no navegador.
• Quem teve a chave do volume (a sua, ou recebida com um link para uma pasta) ainda pode apagar os blocos que foram enviados com ela, até que sejam enviados de novo. Você pode trocar a chave do volume (Configurações → Chave do volume): seus outros dispositivos acompanham sozinhos.
• Seu dispositivo. A lista de arquivos fica em cache criptografada, com a chave no armazenamento seguro do sistema; um arquivo que você baixa ou abre é gravado sem criptografia onde você escolher. O PIN do Drive é uma barreira de conveniência, como no Mail.
• Um computador quântico, mais tarde. Os blocos e os selos são simétricos (AES-256, XChaCha20), mas seu localizador é criptografado com NIP-44 sobre secp256k1: alguém que o guarde hoje e quebre o secp256k1 amanhã poderia abrir o Drive inteiro.

Como é verificado. Duas revisões internas com base no modelo de ameaças (2 de novembro de 2026) e suas correções; testes do que cada evento e bloco mostra; fuzzing de cada leitor do que vem de fora (eventos, selos, manifestos, links, cópias). Ainda sem auditoria externa: uma está prevista antes do beta público, e o relatório dela será publicado na íntegra. O Drive ainda está em desenvolvimento.

Versões com suporte

As correções de segurança são aplicadas à versão publicada mais recente. Dado o tamanho do projeto, as versões antigas não são mantidas — por favor, atualize antes de relatar.