Cansado do WeTransfer ler seus arquivos? Conheça o share·me, um serviço de compartilhamento que não confia nem em si mesmo
Um desenvolvedor criou o share·me, um projeto open-source em Rust, para resolver o problema de compartilhar arquivos de forma segura e privada. A solução inovadora mantém os arquivos criptografados no cliente, garantindo que nem mesmo o servidor possa acessá-los.
MundiX News·09 de junho de 2026·6 min de leitura·👁 8 views
A tarefa comum de compartilhar arquivos, seja um documento sensível, uma senha de servidor ou um dump de banco de dados, pode se tornar um pesadelo de segurança. Serviços como WeTransfer e equivalentes, por sua própria natureza, têm acesso aos dados carregados. E-mails e aplicativos de mensagens, embora convenientes, frequentemente armazenam arquivos em texto plano em seus servidores, expondo-os a potenciais interceptações. Soluções como o PrivateBin são excelentes para textos curtos, mas impraticáveis para arquivos grandes. O que muitos desejam é uma solução simples: enviar um arquivo, obter um link, e ter a garantia de que o servidor, mesmo sendo de sua própria infraestrutura, não consegue ler o conteúdo. Foi essa frustração recorrente que levou à criação do share·me.
O share·me, um projeto gratuito e de código aberto sob a licença AGPL, foi concebido com um princípio fundamental: a chave de criptografia reside no link, mas nunca é exposta ao servidor. O processo começa no navegador do usuário, onde uma chave aleatória é gerada e utilizada para criptografar o arquivo localmente usando AES-256-GCM. A URL gerada então incorpora essa chave de forma segura: https://share.example/d/AbC123#k=<chave_base64>. Crucialmente, qualquer informação após o caractere # é tratada pelo navegador e nunca enviada ao servidor. Isso significa que os logs do servidor, os access-logs de proxies ou qualquer outro componente de infraestrutura apenas veem o texto cifrado e os nomes dos arquivos, mas não a chave de descriptografia. Para maior segurança, o share·me também oferece um modo de senha, onde a chave é derivada usando Argon2id (com fallback para PBKDF2). Se a senha estiver incorreta, a autorização do servidor falha, e o sistema de rate-limiting impede ataques de força bruta offline.
Um desafio técnico frequentemente negligenciado em tutoriais de criptografia no lado do cliente é a limitação de memória. Tentar criptografar um arquivo inteiro de vários gigabytes de uma vez em um navegador pode facilmente levar a um erro de falta de memória (OOM). O share·me contorna isso implementando um sistema de criptografia AES-256-GCM segmentado e em stream. O arquivo é dividido em blocos menores, cada um criptografado com uma chave derivada de HKDF e um nonce incremental. Dois pontos cruciais que exigiram atenção especial foram a necessidade de nonces determinísticos e ordenados para permitir a descriptografia sequencial sem buffer completo, e a natureza não key-committing do AES-GCM, que poderia permitir a falsificação de textos cifrados. Para mitigar isso, um cabeçalho key-committing foi adicionado para vincular inequivocamente o texto cifrado a uma chave específica. A arquitetura do share·me é projetada para eficiência: o navegador e a API Rust (construída com Axum) se comunicam diretamente via stream, evitando que o serviço Rust precise carregar arquivos inteiros na memória. Um Back-end for Front-end (BFF) leve em Next.js gerencia tokens de proprietário em cookies httpOnly, enquanto os dados de arquivo maiores fluem diretamente para a API. Recursos como prazo de validade, limite de downloads e a funcionalidade burn-after-reading são impostos no lado do servidor, garantindo que o cliente não possa burlar essas restrições. A implantação é simplificada via Docker Compose, e o serviço requer recursos mínimos, como 1 vCPU e 1 GB de RAM, sendo limitado principalmente por disco e tráfego, não por processamento. Embora ainda não tenha passado por auditoria externa, o código criptográfico foi isolado em um pacote pequeno e de fácil revisão, com licença AGPL-3.0, incentivando a comunidade a buscar vulnerabilidades.
A tarefa comum de compartilhar arquivos, seja um documento sensível, uma senha de servidor ou um dump de banco de dados, pode se tornar um pesadelo de segurança. Serviços como WeTransfer e equivalentes, por sua própria natureza, têm acesso aos dados carregados. E-mails e aplicativos de mensagens, embora convenientes, frequentemente armazenam arquivos em texto plano em seus servidores, expondo-os a potenciais interceptações. Soluções como o PrivateBin são excelentes para textos curtos, mas impraticáveis para arquivos grandes. O que muitos desejam é uma solução simples: enviar um arquivo, obter um link, e ter a garantia de que o servidor, mesmo sendo de sua própria infraestrutura, não consegue ler o conteúdo. Foi essa frustração recorrente que levou à criação do share·me.
O share·me, um projeto gratuito e de código aberto sob a licença AGPL, foi concebido com um princípio fundamental: a chave de criptografia reside no link, mas nunca é exposta ao servidor. O processo começa no navegador do usuário, onde uma chave aleatória é gerada e utilizada para criptografar o arquivo localmente usando AES-256-GCM. A URL gerada então incorpora essa chave de forma segura: https://share.example/d/AbC123#k=<chave_base64>. Crucialmente, qualquer informação após o caractere # é tratada pelo navegador e nunca enviada ao servidor. Isso significa que os logs do servidor, os access-logs de proxies ou qualquer outro componente de infraestrutura apenas veem o texto cifrado e os nomes dos arquivos, mas não a chave de descriptografia. Para maior segurança, o share·me também oferece um modo de senha, onde a chave é derivada usando Argon2id (com fallback para PBKDF2). Se a senha estiver incorreta, a autorização do servidor falha, e o sistema de rate-limiting impede ataques de força bruta offline.
Um desafio técnico frequentemente negligenciado em tutoriais de criptografia no lado do cliente é a limitação de memória. Tentar criptografar um arquivo inteiro de vários gigabytes de uma vez em um navegador pode facilmente levar a um erro de falta de memória (OOM). O share·me contorna isso implementando um sistema de criptografia AES-256-GCM segmentado e em stream. O arquivo é dividido em blocos menores, cada um criptografado com uma chave derivada de HKDF e um nonce incremental. Dois pontos cruciais que exigiram atenção especial foram a necessidade de nonces determinísticos e ordenados para permitir a descriptografia sequencial sem buffer completo, e a natureza não key-committing do AES-GCM, que poderia permitir a falsificação de textos cifrados. Para mitigar isso, um cabeçalho key-committing foi adicionado para vincular inequivocamente o texto cifrado a uma chave específica. A arquitetura do share·me é projetada para eficiência: o navegador e a API Rust (construída com Axum) se comunicam diretamente via stream, evitando que o serviço Rust precise carregar arquivos inteiros na memória. Um Back-end for Front-end (BFF) leve em Next.js gerencia tokens de proprietário em cookies httpOnly, enquanto os dados de arquivo maiores fluem diretamente para a API. Recursos como prazo de validade, limite de downloads e a funcionalidade burn-after-reading são impostos no lado do servidor, garantindo que o cliente não possa burlar essas restrições. A implantação é simplificada via Docker Compose, e o serviço requer recursos mínimos, como 1 vCPU e 1 GB de RAM, sendo limitado principalmente por disco e tráfego, não por processamento. Embora ainda não tenha passado por auditoria externa, o código criptográfico foi isolado em um pacote pequeno e de fácil revisão, com licença AGPL-3.0, incentivando a comunidade a buscar vulnerabilidades.
