Segurança e modelo de ameaças

Criptografia de arquivos em tempo real no navegador (X25519 + AES-256-GCM)

Para arquivos em tempo real no navegador, cada transferência gera um par X25519 efêmero em cada dispositivo e os navegadores derivam uma chave AES-256-GCM compartilhada. Cada bloco usa um nonce único, então a sinalização e o retransmissor veem texto cifrado, não o arquivo simples. As sessões com código de pareamento da CLI usam o mesmo esquema com uma ponta atualizada; o push e o sync de servidor para servidor da CLI, e o seu pareamento antigo, usam outro protocolo direto TLS 1.3 descrito abaixo.

• As chaves são efêmeras e específicas de cada transferência — nada é reutilizado entre sessões.
• A chave compartilhada é derivada nos dois dispositivos; ela nunca é enviada a nenhum servidor nem armazenada nele.
• A criptografia é aplicada na camada de aplicação, acima da própria segurança de transporte do WebRTC, de modo que se mantém mesmo se a camada de transporte for comprometida.

O código de verificação (SAS) — detectar um servidor malicioso

O WebRTC troca impressões digitais pelo servidor de sinalização, que poderia tentar substituir chaves. Por isso a Relayium pode mostrar um SAS de 6 dígitos nas duas telas. Códigos iguais oferecem a verificação mais forte somente quando as duas pessoas os comparam fora de banda. Mostrar esse código e parar para compará-lo é uma preferência: “verificação avançada” na web (desligada por padrão) e `--verify` na CLI. Desligá-la muda o que aparece e quais passos param para pedir confirmação; não muda a criptografia. O handshake de compromisso e revelação abaixo roda em toda conexão e recusa aquela cuja revelação não confere, as chaves continuam sendo geradas no seu aparelho e nunca são enviadas a nós, o retransmissor continua carregando apenas texto cifrado, e, no navegador, receber arquivos continua perguntando antes de salvar qualquer coisa — já o aplicativo nativo de macOS grava sem perguntar na sua pasta de destino configurada (Downloads por padrão). Essa pergunta evita gravações não solicitadas no seu disco; ela não diz quem está do outro lado, e só a comparação do código estabelece isso.

O compromisso e posterior revelação impede que o servidor escolha depois uma chave que colida. As sessões com código de pareamento da CLI usam este mesmo handshake com uma ponta atualizada; o pareamento antigo, só direto, usa um SAS separado derivado da troca das impressões do certificado TLS fixado. Qualquer um dos dois só detecta algo se alguém realmente o comparar fora de banda, que é para o que `--verify` para.

• Para a garantia mais forte, ative a verificação avançada e compare o código fora de banda — pessoalmente ou por uma chamada de voz.
• Se os dois códigos forem diferentes, interrompa a transferência: alguém pode estar interceptando a conexão.

Texto simples que o servidor não pode ver nem descriptografar

Nossos servidores foram projetados para não poder ver nem descriptografar o seguinte texto simples:

Na mesma rede, bytes de arquivos e mensagens fluem diretamente entre dispositivos. Entre redes passam pelo TURN como texto cifrado, sem que o retransmissor tenha a chave. A sinalização ainda processa dados da conexão e vê metadados como IP público, sala, horário, apelido e presença.

• O conteúdo dos seus arquivos.
• Os nomes dos seus arquivos.
• O texto simples das suas mensagens.
• Suas chaves de criptografia.

Quando arquivos e textos do navegador são retransmitidos (TURN)

Arquivos e textos do navegador entre redes usam TURN por projeto, não como alternativa, pois NATs e firewalls tornam improvável o caminho direto. Sessões do navegador na mesma rede conectam diretamente sem credenciais de retransmissão. As sessões com código de pareamento da CLI (arquivos, texto e pair) usam TURN sempre que o servidor emite um retransmissor para o código, mesmo havendo caminho direto, e seus bytes retransmitidos contam para a cota mensal de retransmissão da conta que criou o código; só quando nenhum é emitido elas se conectam diretamente, e falham sem caminho direto. O push e o sync de servidor para servidor da CLI nunca usam TURN.

• O retransmissor encaminha apenas texto cifrado — ele não consegue ler seus arquivos nem mensagens, que permanecem criptografados de ponta a ponta.
• Registramos o número de bytes retransmitidos por conta, para aplicar uma cota mensal de retransmissão e evitar abusos — nunca inspecionamos o que é retransmitido, apenas a contagem de bytes.
• Nunca inspecionamos o conteúdo retransmitido.

Transferência de texto temporário

As sessões de texto no navegador usam o protocolo Web: os pares fazem uma troca X25519 efêmera e derivam subchaves AES-256-GCM separadas por direção em um domínio distinto das chaves de transferência de arquivos. Cada mensagem UTF-8 válida é autenticada e criptografada como um quadro independente. Entre redes, as sessões do navegador usam TURN por decisão de projeto; o retransmissor transporta texto cifrado e não possui a chave da mensagem. Com a verificação avançada ativada, comparar o SAS fora de banda detecta também a interceptação da sinalização.

O texto da CLI usa este mesmo protocolo com uma ponta atualizada, incluindo TURN sempre que o servidor emite um retransmissor para o código; só com um relayium antigo ele usa um protocolo diferente e direto, sobre TLS 1.3 com certificado fixado, que falha se nenhum caminho direto puder ser estabelecido. A Relayium não armazena o corpo das mensagens, mas qualquer ponta pode copiar, registrar, capturar a tela ou reter o texto de outra forma após recebê-lo.

• As duas pessoas precisam estar online ao mesmo tempo; a Relayium não oferece entrega de texto offline nem histórico de mensagens no servidor.
• Os servidores necessariamente processam metadados de conexão, como endereços IP, participação na sala, horário, apelido do dispositivo e presença em sessões do navegador e, quando aplicável, a associação da conta usada para criar um código de emparelhamento.
• Em sessões TURN, a Relayium pode registrar a quantidade de bytes retransmitidos para aplicar a cota e prevenir abusos, mas não inspeciona o texto simples das mensagens.

Links de download armazenados — a chave nunca deixa seu navegador

O modo opcional de link de download é para quando o destinatário não está online. Seu navegador criptografa os arquivos com AES-256-GCM antes de qualquer coisa ser enviada, e a chave de descriptografia é colocada apenas no fragmento da URL — a parte depois do # —, que os navegadores nunca enviam ao servidor.

• O servidor armazena apenas texto cifrado, além do tamanho do texto cifrado e marcas de tempo para cota e limpeza — nunca texto simples, nomes de arquivos ou chaves.
• Qualquer pessoa com o link completo pode descriptografar, então trate o link como o próprio arquivo e compartilhe-o por um canal confiável.
• Os links podem ser configurados para expirar (de 1 hora até 14 dias, dependendo do seu plano) ou para se destruir após o primeiro download completo.

Integridade dos arquivos (SHA-256)

Além da confidencialidade, a integridade de cada arquivo é verificada. Cada bloco carrega uma tag de autenticação AES-GCM, e um hash SHA-256 por arquivo é verificado de ponta a ponta no lado receptor, de modo que um arquivo corrompido ou adulterado é detectado em vez de aceito silenciosamente.

Contra o que a Relayium não protege

A criptografia de ponta a ponta protege os dados em trânsito entre dois pontos de extremidade honestos. Por design, ela não pode proteger contra:

• Um dispositivo ou navegador comprometido em qualquer uma das pontas — malware, uma extensão de navegador hostil ou alguém lendo a tela.
• Os metadados necessários: horário da sessão, bytes retransmitidos e, para um link armazenado ou sessão com código, a conta que criou o link ou o código.
• Um destinatário que guarda, copia ou encaminha arquivos ou mensagens depois de recebê-los.
• Compartilhar um link de download por um canal não confiável, já que a chave de descriptografia viaja dentro do link.

Suporte a navegadores e seus limites

A Relayium funciona em qualquer navegador moderno com WebRTC sobre HTTPS. Alguns recursos diferem conforme o navegador:

• Chrome e Edge no desktop têm a API File System Access e transmitem arquivos grandes diretamente para o disco, sem um teto de memória prático.
• Firefox, Safari e todos os navegadores móveis (no iOS, todo navegador é WebKit) não têm essa API e montam o arquivo na memória no caminho em tempo real, por isso o aplicativo avisa acima de cerca de 256 MB — uma estimativa deliberadamente conservadora, não um limite medido. Para arquivos desse tamanho, prefira Chrome/Edge no desktop, ou use o modo de link de download, cuja página de download ainda pode gravar em disco por meio de um service worker.
• O WebRTC exige um contexto seguro (HTTPS); o aplicativo não se conecta por HTTP simples.

Código aberto e relato de problemas

O design do protocolo e todo o código de cliente e servidor são públicos no GitHub, de modo que qualquer pessoa pode auditar a criptografia, executar o próprio servidor ou contribuir. Se você encontrar um problema de segurança, relate-o de forma privada por meio do relato de vulnerabilidades do GitHub no repositório, em vez de abrir uma issue pública.