Uma nota sobre financiamento: o CypherpunkGuide não veicula publicidade de vigilância — nada de redes de anúncios, pixels de rastreamento ou conteúdo patrocinado. O projeto se sustenta com fontes transparentes de receita: doações de leitores agora; assinatura e afiliados alinhados à linha editorial mais adiante. Respondemos aos leitores, não aos anunciantes.
Um pagamento privado, uma conversa criptografada e uma pasta protegida antes de ir para a nuvem parecem três problemas resolvidos. Monero, SimpleX e Cryptomator de fato protegem registros importantes. O erro é supor que adotar os três transforma o fluxo completo em um sistema anônimo.
Com base na documentação oficial vigente em 13 de agosto de 2026, auditei 18 dados observáveis — seis para cada ferramenta. O CSV vinculado às fontes registra quatro estados. Um validador determinístico, que sempre produz o mesmo resultado para a mesma entrada, rejeita linhas sem escopo, fonte ou data de verificação. Não criei uma nota geral de privacidade: somar campos com observadores e consequências diferentes produziria uma classificação sem sustentação.
O problema mais difícil aparece quando as três ferramentas compartilham informações. A auditoria revelou seis pistas recorrentes capazes de ligar os registros: apelido, aparelho, rota de rede, contraparte, material de recuperação e padrões de horário e volume. Um observador com acesso a mais de um conjunto de registros pode usar essas coincidências para associar pagamento, mensagem e arquivo. Primeiro, é preciso delimitar o que a documentação permite afirmar sobre cada ferramenta. Depois, o trabalho deve se concentrar nos registros que continuam existindo.
Três ferramentas protegem três registros diferentes#
Um conjunto de controles de privacidade reúne proteções com alcances distintos; não cria uma garantia geral de anonimato. O Monero protege campos do pagamento, o SimpleX protege a entrega das mensagens e o Cryptomator protege o conteúdo enviado à nuvem. Nenhum deles protege contra todos os observadores.
Comece pelo registro, não pelo produto. Quem analisa a blockchain, o provedor de internet, um servidor intermediário, o serviço de nuvem, a contraparte e um malware no seu aparelho veem informações diferentes. O mesmo dado pode ficar oculto para um deles e exposto para outro.
| Uso | O que a ferramenta procura proteger | O que fica fora desse alcance |
|---|---|---|
| Pagamento — Monero | dificuldade de identificar a entrada real do remetente, privacidade do endereço do destinatário e valor da transação | IP da carteira, registros do comerciante, identidade revelada por você, chaves e texto legível no aparelho |
| Mensagens — SimpleX | conteúdo em trânsito, entrega sem um único identificador global de perfil, separação entre origem e servidor do destinatário | identificadores de fila por contato, horários, alguns metadados de rede e servidores, identidade conhecida pelo contato e histórico no aparelho |
| Armazenamento — Cryptomator | conteúdo e nomes dos arquivos antes da sincronização; estrutura de diretórios difícil de interpretar | horários, quantidade de objetos, tamanhos armazenados, formato reconhecível do cofre, identidade da conta de sincronização e texto legível depois de abrir o cofre |
Neste artigo, protected significa que o dado está protegido do observador indicado, somente dentro do alcance documentado. Não quer dizer que o destinatário não o veja, que um aparelho comprometido seja seguro ou que a informação não possa ser comparada com outros registros. Partial indica redução do que o observador consegue obter, sem eliminar o dado ou todas as formas de associação. Exposed indica que a fonte confirma a visibilidade do campo ou o exclui da proteção. Unknown significa que a fonte não confirma proteção nem exposição; portanto, não serve como evidência em nenhum dos dois sentidos.
Essa é a disciplina de um modelo de ameaças útil: identifique o observador, o dado e o acontecimento antes de escolher um controle. Quando o observador muda, a resposta também pode mudar.
O Monero protege o histórico público da transação, não o pagamento inteiro#
O Monero dificulta a identificação da entrada real do remetente, usa endereços únicos para o destinatário e oculta valores com RingCT. Essas propriedades pertencem ao protocolo. A conexão com um nó remoto, a rede, os registros da contraparte, a conta na corretora e uma carteira comprometida exigem controles separados.
As especificações técnicas do Monero descrevem um tamanho de anel de 16: uma entrada real aparece ao lado de 15 decoys, entradas escolhidas para parecer possíveis origens da transação. O resultado é negação plausível — há explicações alternativas críveis para qual entrada foi gasta — e não uma probabilidade comprovada de “uma chance em dezesseis” de identificação. A pesquisa OSPEAD do Monero modela riscos de seleção não uniforme e ligados ao tempo. O número do protocolo não deve ser convertido em uma probabilidade pessoal de anonimato.
O destinatário e o valor usam outros mecanismos. Um endereço furtivo (stealth address) cria um destino único para cada pagamento, de modo que a blockchain pública não exponha diretamente o endereço reutilizável do destinatário. RingCT, ou transações confidenciais em anel, oculta o valor transferido. Assim, “privacidade no Monero” reúne três afirmações diferentes — sobre remetente, destinatário e valor — e não uma propriedade absoluta.
| Observador | O que o Monero muda | O que ainda pode estar disponível |
|---|---|---|
| Analista da blockchain pública | dificulta identificar a entrada real e oculta a ligação pública com o destinatário e o valor | existência e horário do evento no protocolo; inferências probabilísticas |
| Operador de nó remoto | não lê o endereço do destinatário nem o valor em texto aberto na blockchain | conexão da carteira e IP de origem se o caminho de rede não for protegido à parte |
| Provedor de internet ou VPN | a privacidade do histórico de transações permanece | caminho da conexão, horário e padrão de destinos |
| Contraparte ou corretora | observadores externos não recebem os campos privados pela blockchain | identidade, pedido, endereço de entrega, conta, valor ou conversa informados por você |
| Aparelho comprometido | as proteções do protocolo continuam valendo para observadores públicos | chaves da carteira, destino, valor, tela, área de transferência e senha digitada |
A FAQ oficial rejeita a ideia de anonimato garantido e alerta para aparelho comprometido, chaves expostas, senhas fracas e dados pessoais entregues a outra parte. Um subendereço diferente para cada pagador ou finalidade reduz a possibilidade de a contraparte ligar pagamentos pela reutilização do endereço. Ele não faz o mesmo comerciante esquecer o endereço de entrega.
A origem da conexão é outro problema. A documentação alerta que uma carteira ligada a um nó remoto — um servidor externo que consulta a blockchain em nome da carteira — não recebe proteção de IP por padrão. Tor ou I2P aparecem como controles adicionais. O Dandelion++ muda a propagação da transação, mas não esconde a conexão do provedor de internet, da VPN nem do primeiro nó conectado. Se a origem da rede estiver no seu modelo de ameaças, configure essa rota deliberadamente e confirme que a carteira realmente a utiliza.
O guia de privacidade do Bitcoin na blockchain trata do modelo de ameaças mais amplo para pagamentos. O protocolo é diferente, mas a conclusão operacional se mantém: proteger o registro público não apaga dados comerciais nem evidências no aparelho.
O SimpleX dispensa um ID global de perfil, mas deixa outras pistas#
O SimpleX não usa um identificador global de perfil para entregar mensagens. Em vez disso, usa identificadores de fila exclusivos de cada relação e criptografia de ponta a ponta. Servidores, redes, contatos, notificações e aparelhos observam dados diferentes.
A política de privacidade do SimpleX informa que perfis e histórico já entregue ficam nos aparelhos, e não em contas mantidas pelos servidores intermediários. Mensagens criptografadas ainda não entregues podem permanecer nos servidores predefinidos até a entrega ou por até 21 dias. Arquivos criptografados ficam nos servidores de arquivo predefinidos por 48 horas. Portanto, “os servidores não armazenam nada” é uma descrição errada, ainda que eles não tenham o conteúdo em texto legível.
Mensagens recebem preenchimento até 16 KiB, e arquivos são divididos em blocos de tamanho fixo. Isso reduz a precisão da informação sobre tamanho; não esconde a existência do tráfego. No iOS, notificações instantâneas também podem revelar ao servidor de notificações a quantidade aproximada de filas habilitadas e o volume aproximado de mensagens.
| Ponto a examinar | Comportamento padrão | Configuração mais restritiva | Informação que continua disponível |
|---|---|---|---|
| Identidade do perfil | não há um ID global de perfil; cada conexão usa seus próprios dados | use perfis anônimos (incognito) quando relações diferentes precisarem de informações distintas | contatos conhecem o perfil usado com eles; características repetidas podem ligar contextos |
| Caminho pelos servidores | o roteamento privado coloca um servidor de encaminhamento configurado antes do servidor de destino; havendo operadores predefinidos distintos, o aplicativo prefere separá-los | use Tor ou uma rede adicional adequada quando o servidor escolhido não puder ver o IP de origem | não há garantia de operadores independentes; observadores locais ainda podem ver o tráfego |
| Relação entre conexões | um perfil compartilha uma conexão TCP por padrão | depois de avaliar o estado BETA, ative o isolamento de transporte por contato | horários e volumes ainda podem formar um padrão |
| Autenticidade do contato | um link de convite estabelece a conexão | compare o código de segurança por um canal independente | o canal adicional também precisa pertencer à pessoa certa |
| Histórico no aparelho | o histórico entregue fica armazenado localmente | use uma senha no banco de dados do aplicativo e defina uma retenção adequada | aparelho desbloqueado, destinatário, captura de tela e malware podem conservar o texto aberto |
O guia de privacidade e segurança alerta que um link de convite pode ser substituído no caminho. Para um contato sensível, compare o código de segurança do aplicativo por um meio realmente independente, como uma chamada já autenticada ou um encontro presencial. Outra mensagem recebida pela mesma conta ainda não verificada não constitui confirmação independente.
O modelo de ameaças do protocolo também mostra por que “sem identificadores” seria amplo demais. Um contato pode testar se as informações de dois perfis fora do modo anônimo são iguais. Confirmações de recebimento ou respostas automáticas podem revelar se e quando alguém está ativo. Não haver um identificador global de perfil para entrega não significa ausência de identificadores por conexão ou de metadados próprios de cada observador.
Chamadas têm outro alcance. Segundo o guia de áudio e vídeo, numa chamada assistida por um servidor TURN — que encaminha áudio e vídeo quando os aparelhos não conseguem se conectar diretamente —, o servidor vê a duração. Numa ligação direta entre os participantes, os contatos veem os respectivos endereços IP. Se as chamadas fizerem parte do procedimento, audite-as separadamente das mensagens.
O SimpleX protege a entrega de mensagens; não torna seguro todo conteúdo enviado. O guia sobre privacidade do número de telefone explica o benefício de retirar esse identificador. Mesmo assim, o comportamento dos contatos e o comprometimento do aparelho continuam exigindo controles próprios.
O Cryptomator criptografa os arquivos, não o padrão de atividade#
O Cryptomator criptografa conteúdo e nomes antes da sincronização e torna a estrutura de diretórios difícil de interpretar. Segundo o documento de segurança, o serviço de nuvem ainda vê horários, quantidade de arquivos e pastas, tamanhos armazenados e o formato reconhecível do cofre.
O documento que define o alcance de segurança do Cryptomator é direto sobre o que fica de fora. O provedor de nuvem não recebe nomes nem conteúdo legível, mas observa quando arquivos e pastas mudam, quantos existem e qual é o tamanho armazenado. Extensões .c9r ou .c9s e os arquivos de configuração também podem revelar o uso do Cryptomator. Trata-se de criptografia, não de esteganografia — a técnica de esconder até a existência de uma mensagem ou arquivo protegido.
Depois que o cofre é aberto, o endpoint — o aparelho que manipula a chave e o texto já descriptografado — torna-se mais importante que o provedor de nuvem. Malware, administrador hostil, capturas de tela, arquivos temporários, histórico da área de transferência e cópias criadas fora do Cryptomator podem contornar a proteção. O aplicativo não protege uma cópia que outro programa faça enquanto trabalha com os arquivos abertos.
O Cryptomator também não substitui sincronização nem cópias de segurança. As boas práticas oficiais pedem backups regulares do cofre criptografado. O guia de conflitos trata a sincronização como outro sistema, sujeito a conflitos. Separe as credenciais e o material de recuperação tanto da conta de nuvem quanto do aparelho que abre o cofre. A recuperação do cofre não recria arquivos criptografados apagados. Se vários programas leem a unidade aberta, todos precisam ser tratados como software confiável no aparelho.
A auditoria de 18 campos revela o que sobra entre os usos#
A auditoria compara três ferramentas em seis campos observáveis cada. Toda linha identifica observador, fonte oficial, data e limitação. O objetivo é localizar as pistas que permitem relacionar os três registros; não é criar um comparativo de desempenho, uma nota de produto nem um ranking de privacidade.
Preparei o registro com 18 linhas a partir das fontes oficiais citadas neste artigo. Em seguida, rodei o validador, que confirmou 18 linhas, seis por ferramenta, campos únicos, domínios de fonte aprovados, datas no formato ISO e limitações não vazias. O resumo gerado mantém os quatro estados, mas adverte contra a comparação das contagens.
O método adota cinco regras:
- Um campo, um observador. A origem de rede é avaliada contra um servidor ou observador da rede, não contra um “atacante” indefinido.
- Estado padrão e configuração reforçada ficam separados.
Hardenedregistra uma opção documentada ou outro controle nomeado. Não é uma avaliação obtida em teste prático nem prova de que Cora testou aquela rota. A possibilidade de usar Tor não transforma Tor no padrão. - Toda linha declara o que continua exposto. Uma mensagem protegida em trânsito ainda pode aparecer em texto legível nos dois aparelhos.
- A falta de evidência permanece
unknown. O documento de segurança do Cryptomator não promete anonimato de rede para a sincronização. Por isso, esse campo ficaunknown, sem uma resposta inventada. O estado não prova exposição nem proteção. - As contagens nunca viram notas. Seis dados com observadores e consequências diferentes não podem ser somados como uma medida válida de privacidade do produto.
A quarta regra produziu um dos resultados mais úteis. Mantive um campo do Cryptomator como unknown, em vez de preenchê-lo com a reputação do produto. Também atribuí um observador específico a cada linha antes da classificação. Esse cuidado evita que uma matriz aparentemente completa leve alguém a mudar o controle errado.
Seis pistas que podem relacionar os três registros#
O quadro abaixo apresenta uma inferência feita por Cora ao combinar as evidências de cada ferramenta. Não é o resultado de uma desanonimização medida, nem uma afirmação dos fornecedores sobre o uso combinado das três ferramentas. O glossário do NIST define dissociabilidade como a capacidade de processar dados ou eventos sem ligá-los a pessoas ou aparelhos além do necessário para a operação. Essa propriedade se perde quando os três usos compartilham uma característica duradoura.
| Pista compartilhada | Exemplo | Quem pode comparar os registros | Como reduzir a associação |
|---|---|---|---|
| Apelido ou conta | o mesmo nome aparece no perfil do SimpleX, no cadastro da corretora e na conta de nuvem | contraparte, provedor da conta, corretor de dados | use identidades distintas por finalidade e não compartilhe o e-mail de recuperação |
| Aparelho | um notebook infectado vê carteira, conversa e cofre aberto em texto legível | malware, administrador do aparelho, perito forense | aparelhos separados ou sistemas realmente isolados quando o risco justificar; contas comuns do sistema organizam acessos, mas não impedem malware com privilégios de administrador |
| Rota de rede | carteira, servidores de mensagens e nuvem recebem conexões do mesmo IP residencial estável | provedor de internet, VPN, servidor intermediário ou nuvem com dados auxiliares | planeje a rota de cada uso sensível; criptografia de arquivo ou protocolo não oculta IP por si só |
| Contraparte | a mesma pessoa recebe mensagem, pagamento e link para o arquivo | destinatário ou comerciante | revele apenas os dados necessários; use subendereços e links específicos para cada finalidade |
| Horário e tamanho | mensagem, pagamento e upload acontecem em poucos segundos | observador capaz de acessar mais de um conjunto de logs | agrupe ou atrase ações e evite narrar valores ou nomes de arquivos em tempo real |
| Material de recuperação | um e-mail, gerenciador de senhas ou backup de fotos recupera os três usos | invasor da conta, provedor de nuvem, pessoa obrigada a entregar o material | canais de recuperação separados e material offline; teste cada rota isoladamente |
Horários exigem cautela. A proximidade entre dois eventos é uma pista, não uma prova de que pertencem à mesma pessoa. Contudo, repetir a sequência mensagem, pagamento e upload pode criar um padrão mais forte que uma coincidência única. Atrasos aleatórios não produzem anonimato. Primeiro, remova os vínculos mais fortes, como identidade e aparelho compartilhados; só depois reduza a precisão desnecessária dos horários.
Esse problema lembra o guia sobre desanonimização por IA: relacionar registros fica mais fácil de automatizar quando vários sinais fracos carregam o mesmo identificador. Aqui, os sinais são eventos observáveis por máquinas, e não estilo de escrita.
Use as três ferramentas sem criar um identificador único para tudo#
Parta do modelo de ameaças: separe finalidades, verifique software e contatos, proteja as rotas necessárias, criptografe antes de sincronizar e ensaie a recuperação. O trabalho termina quando a falha de uma conta ou aparelho não expõe os três usos ao mesmo tempo.
Siga esta ordem com dados sem importância antes de mover dinheiro real ou informações sensíveis:
- Escreva três frases dizendo quem não pode ver o quê. Por exemplo: “a blockchain pública não deve revelar o destinatário nem o valor”, “o servidor de mensagens não deve guardar texto aberto” e “o provedor de nuvem não deve ler nomes nem conteúdo”. Só acrescente rede e aparelho quando o risco justificar o custo.
- Separe identidades por finalidade. Decida se você aceita que a contraparte associe pagamento, conversa e arquivo. Se não aceitar, evite compartilhar apelido, e-mail de recuperação, foto de perfil, conta de nuvem ou uma descrição que revele a relação.
- Obtenha o software pela fonte oficial e confira sua autenticidade. Verifique assinaturas de versões ou orientações sobre compilações reproduzíveis quando o projeto as publicar. Teste o Monero na
stagenet, a rede criada para ensaios, e use dados não secretos no SimpleX e no Cryptomator. Um executável não verificado torna todas as outras proteções dependentes de uma origem que você não conferiu. - Configure o pagamento. Use um subendereço diferente por pagador ou finalidade. Se o nó remoto não deve ver o IP da carteira, prepare e teste essa rota à parte. Registre quais dados a contraparte ainda conserva.
- Autentique o contato. Estabeleça a conexão no SimpleX, compare o código de segurança por um canal independente, revise o modo anônimo e a configuração de isolamento do transporte e decida se notificações ou chamadas cabem no modelo de ameaças.
- Configure o armazenamento. Crie o cofre localmente, use uma senha forte e exclusiva, separe o material de recuperação e só então sincronize os dados criptografados. Confirme que exportações temporárias e backups de outros programas não deixaram cópias em texto legível.
- Ensaie falhas com material sem importância. Restaure um cofre de teste, recupere ou migre um perfil de conversa não crítico conforme a documentação atual e use uma carteira de teste vazia ou um ambiente deliberadamente isolado para praticar a recuperação. Nunca digite uma seed que protege dinheiro real — a informação secreta capaz de restaurar a carteira — em site, nuvem, aparelho não verificado ou ferramenta desconhecida. Não sobrescreva a carteira existente durante o ensaio. Descubra antes da emergência se os três procedimentos dependem do mesmo celular.
- Revise as pistas entre os usos. Compare apelido, aparelho, caminho de rede, contraparte, horário, tamanho e recuperação. Retire coincidências sem utilidade operacional e documente as que decidiu aceitar.
Separar tudo tem custos: mais material de recuperação, fluxos mais lentos, notificações perdidas, falhas de rota e mais oportunidades para erro humano. A meta não é a separação máxima, e sim a menor separação que impeça o observador identificado de associar os registros. O guia de soberania com serviços próprios aplica o mesmo princípio à infraestrutura: trazer um serviço para casa muda em quem você confia, mas não elimina administração nem recuperação.
Conclusão: escolha o registro que precisa proteger#
Use Monero quando precisar de privacidade no histórico público da transação, SimpleX para mensagens sem um ID global de perfil e Cryptomator para criptografar arquivos na nuvem. Depois, audite os dados compartilhados de identidade, aparelho, rede, horários e recuperação.
Se a única preocupação for o provedor de nuvem ler nomes de arquivo, o Cryptomator pode ser a resposta completa. Se um comerciante já conhece sua identidade legal e o endereço de entrega, o Monero não apaga esse registro comercial. Se o contato não foi verificado, a criptografia do SimpleX pode estabelecer com segurança uma conexão com a pessoa errada. Mais ferramentas não corrigem um modelo de ameaças mal definido.
O conjunto só é defensável quando toda afirmação nomeia um observador e cada recuperação foi testada. Se necessário, preserve um unknown honesto. É mais seguro que uma tabela impecável que atribui à ferramenta uma propriedade não confirmada pela fonte.
Perguntas frequentes#
As ferramentas protegem campos específicos do protocolo e do armazenamento, não todos os registros de identidade, rede, aparelho e recuperação ao redor deles. Identifique primeiro o observador e adote apenas os controles que mudam o que ele consegue ver.
Monero, SimpleX e Cryptomator juntos me tornam anônimo?#
Não. Cada ferramenta protege registros diferentes. Uma contraparte, um aparelho comprometido, um IP estável, horários sincronizados ou uma única conta de recuperação podem associar as atividades. Trate o anonimato como o resultado de um modelo de ameaças, não como um recurso herdado de três marcas.
O Monero esconde meu IP de um nó remoto?#
Não por padrão. A documentação técnica trata a privacidade da rede como outro controle e descreve o uso de Tor ou I2P para essa finalidade. Confirme a rota realmente usada pela carteira; as proteções do remetente, destinatário e valor na blockchain não comprovam proteção do IP.
O SimpleX não tem identificadores nem metadados?#
Ele não usa um identificador global de perfil para entregar mensagens, mas utiliza identificadores de fila por contato e conserva metadados operacionais dentro dos limites documentados. Servidores intermediários, contatos, notificações, observadores da rede e aparelhos veem campos diferentes.
O provedor de nuvem consegue saber que uso Cryptomator?#
Sim. O Cryptomator criptografa conteúdo e nomes, mas não tenta esconder o formato do cofre. Extensões dos objetos criptografados, arquivos de configuração, horários, quantidades e tamanhos armazenados podem continuar visíveis.
Devo guardar todo o material de recuperação em um só gerenciador de senhas?#
Somente se o seu modelo de ameaças aceitar que a invasão desse gerenciador ou de sua recuperação exponha os três usos de uma vez. Em situações de maior risco, separe materiais cujo comprometimento conjunto exporia tudo. Depois, teste a recuperação para que a separação não deixe você sem acesso.
Fontes#
As treze fontes oficiais sujeitas a mudanças aparecem com uma captura exata do Wayback. As afirmações se apoiam nas páginas oficiais atuais; a coluna de arquivo oferece uma segunda forma de verificar o conteúdo mais tarde.
