Como o Relayium criptografa seus arquivos de ponta a ponta

Última atualização: 2026-08-06

“O Relayium é seguro?” é uma pergunta justa — toda ferramenta de transferência de arquivos afirma ser privada. Esta página percorre exatamente como o Relayium mantém os arquivos privados, em linguagem simples, para que você possa julgar a afirmação em vez de aceitá-la por fé.

Há dois esquemas de criptografia diferentes em jogo, porque há duas situações diferentes: enviar um arquivo ao vivo para alguém que está online agora mesmo, e deixar um link de download para alguém pegar mais tarde. Ambos mantêm o servidor fora do seu arquivo, mas chegam lá por caminhos diferentes — e vale a pena saber qual se aplica em cada caso.

Transferências ao vivo: dois dispositivos combinam um segredo que o servidor nunca vê

Quando você envia um arquivo em tempo real — ambas as pessoas online, de navegador para navegador — o Relayium começa fazendo cada dispositivo gerar um novo par de chaves com X25519, a mesma troca de chaves de curva elíptica usada nas mensagerias seguras modernas (tecnicamente, o crypto_kx do libsodium). Cada dispositivo guarda sua chave privada para si e envia apenas sua chave pública para o outro lado.

A partir dessas duas chaves públicas, cada dispositivo calcula independentemente o mesmo segredo compartilhado — um processo que funciona precisamente por causa de como a troca de chaves de curva elíptica é construída, e não porque o segredo tenha sido enviado a algum lugar. Esse segredo compartilhado se torna uma chave AES-256-GCM que existe apenas dentro dos dois navegadores. Cada bloco do arquivo é selado com essa chave e um nonce único antes mesmo de sair do dispositivo do remetente, então tudo o que atravessa a rede — incluindo o servidor de sinalização que ajudou os dois navegadores a se encontrarem — só vê texto cifrado.

Um novo par de chaves é gerado para cada transferência — nada é reutilizado entre sessões.
A chave AES-256-GCM compartilhada é derivada independentemente em cada dispositivo; ela nunca é transmitida a lugar nenhum, incluindo os próprios servidores do Relayium.
A criptografia acontece na camada de aplicação, acima da própria segurança de transporte do WebRTC, então ela se mantém mesmo que essa camada de transporte venha a ser comprometida.

O código de 6 dígitos que flagra um servidor desonesto

O que você precisa para fazer essa comparação

Os dois aparelhos à sua frente, ou outra pessoa que esteja agora diante do dela.
Um canal que não seja esta transferência: uma ligação, ou a sala em que os dois estão. Colar o código na mesma conversa que preocupa você não prova nada.
Dez segundos. É esse o custo inteiro da única checagem que pega um servidor desonesto.

Há uma sutileza que vale a pena reconhecer com honestidade. A criptografia embutida do WebRTC (DTLS) troca as impressões digitais das chaves através do servidor de sinalização que apresenta os dois dispositivos um ao outro. Se esse servidor fosse desonesto, ele poderia em teoria se colocar no meio e substituir suas próprias chaves — um clássico ataque de intermediário — sem que nenhum dos dois navegadores percebesse de imediato.

O Relayium fecha essa brecha com um curto código de verificação. Ambos os dispositivos derivam o mesmo Short Authentication String (SAS) de 6 dígitos a partir de suas duas chaves públicas e podem exibi-lo na tela. Exibi-lo e parar para compará-lo é a “verificação avançada”, desligada por padrão: uma transferência padrão não mostra código algum. Todo o restante descrito aqui continua valendo para cada transferência: as chaves novas, a criptografia, o handshake de comprometer-e-depois-revelar e a autenticação de cada bloco. O que falta a uma transferência padrão é justamente essa conferência — detectar uma chave substituída, ou um desconhecido do outro lado, exige a verificação avançada ligada e as duas pessoas comparando o código de fato por outro canal. Se os códigos coincidem, as chaves públicas não foram substituídas: o servidor de sinalização ou de retransmissão não se passou por nenhum dos endpoints nem encerrou a criptografia de ponta a ponta da camada de aplicação. Isso não significa que não havia servidor no caminho de rede — o texto cifrado entre redes ainda pode passar pelo TURN por design. Mas um código simples de 6 dígitos tem apenas cerca de 20 bits, o que em princípio um atacante bem posicionado poderia tentar quebrar por força bruta até fazer coincidir depois de ver as duas chaves reais. Para evitar isso, o Relayium usa um handshake de comprometer-e-depois-revelar: cada lado primeiro envia um hash que o compromete com sua chave, e só revela a chave real depois de receber o compromisso do outro lado. Essa ordem significa que um servidor malicioso tem de se comprometer com uma chave falsa às cegas, antes de ter visto a real — ele não pode escolher depois uma chave que colida, então o código curto continua confiável.

Comece uma transferência entre os dois aparelhos e espere o código de verificação aparecer em cada tela.
```
https://relayium.com/
```
Leia um deles em voz alta, dígito por dígito, pelo canal à parte — sem copiar para o aplicativo nem para a mesma conversa.
Compare os seis dígitos. Bater em parte é não bater.
Aceite só se forem iguais. Se diferirem, recuse e descubra em qual máquina a outra pessoa realmente está antes de tentar de novo.
Na CLI, torne a comparação bloqueante em vez de opcional: o --verify para a transferência nesse ponto e espera a sua confirmação, então nenhum byte se move até alguém ter de fato olhado.
```
relayium send --verify ./report.pdf
```

O que uma comparação que bate prova, e o que não prova

Duas telas mostrando os mesmos seis dígitos significam que as impressões digitais de certificado fixadas pelas duas pontas coincidem, ou seja, o rendezvous não trocou nenhuma ponta nem se passou por nenhum dos lados. É exatamente o ataque de que esta seção trata.

Ela autentica as duas pontas. Não prova nada sobre cada salto de rede no meio, e não prova nada mesmo se ninguém comparar — é para isso que existe o --verify.

Para a garantia mais forte, ative a verificação avançada e então leia o código em voz alta em uma chamada ou compare-o pessoalmente, não apenas a olho em duas telas lado a lado.
Se os dois códigos não coincidirem, pare — trate isso como um sinal de que alguém pode estar interceptando a conexão.

Garantir que o que chega é exatamente o que foi enviado

A criptografia protege o sigilo, mas não prova automaticamente que nada foi corrompido ou adulterado pelo caminho. O Relayium verifica isso separadamente: cada bloco carrega sua própria etiqueta de autenticação AES-GCM, de modo que um bloco modificado simplesmente falha ao ser descriptografado. Além disso, à medida que cada arquivo é enviado, ambos os lados calculam um hash SHA-256 contínuo sobre seu conteúdo em texto claro; quando o arquivo termina, o hash do remetente é comparado com o do destinatário. Se coincidem, o que chegou ao disco é byte por byte o que foi enviado — se não, o arquivo é sinalizado em vez de ser aceito silenciosamente.

Links armazenados: uma chave diferente, gerada uma única vez, guardada apenas no link

A transferência em tempo real precisa das duas pessoas online ao mesmo tempo. Quando isso não é possível, o Relayium oferece em vez disso um link de download armazenado — e este usa um mecanismo genuinamente diferente, que convém não confundir com o de tempo real acima.

Aqui não há troca de chaves, porque ainda não existe um segundo dispositivo com quem trocar. Em vez disso, seu navegador gera uma única chave AES-256-GCM aleatória e a usa para criptografar os arquivos antes que qualquer coisa seja enviada. Essa chave nunca é enviada ao servidor — ela é anexada ao link de download depois de um caractere #, no que se chama fragmento da URL, uma parte do endereço que os navegadores deliberadamente nunca transmitem a um servidor. O servidor acaba armazenando apenas texto cifrado que não tem como descriptografar, mais dados administrativos como o tamanho do texto cifrado e um carimbo de data/hora de expiração. Qualquer pessoa que abra o link completo — incluindo o fragmento — pode descriptografar o arquivo localmente em seu navegador; quem não o tem vê apenas um bloco opaco no servidor. Essa é a parte de conhecimento zero: o servidor guarda o arquivo criptografado sem jamais ter os meios de lê-lo.

Criar um link armazenado exige que o remetente entre na conta; abrir um para baixar nunca exige.
Os links podem ser configurados para expirar após 1 hora, 1 dia, 3 dias, 7 dias ou até 14 dias conforme o seu plano, ou para se autodestruir após o primeiro download concluído.
Trate o link completo como o próprio arquivo — qualquer pessoa que o tenha pode descriptografá-lo, então compartilhe-o do jeito que compartilharia o arquivo.

O que o servidor pode ver — e o que ele não pode

Vale a pena explicitar exatamente onde o servidor se situa em tudo isso, porque “criptografado de ponta a ponta” é uma afirmação fácil de fazer e mais difícil de fazer com precisão. No modo tempo real na mesma rede, o próprio arquivo nunca toca os servidores do Relayium — ele é transmitido diretamente entre os dois navegadores. O trabalho do servidor de sinalização se limita a retransmitir as mensagens de estabelecimento de conexão (as informações técnicas SDP/ICE de que o WebRTC precisa para estabelecer um link direto) para que os dois dispositivos possam se encontrar; ele nunca vê o conteúdo dos arquivos, os nomes dos arquivos ou as chaves.

Entre redes — onde NATs ou firewalls restritivos costumam descartar qualquer caminho direto — o fluxo criptografado passa por um servidor retransmissor TURN. O retransmissor só encaminha texto cifrado; ele não tem chave e não pode descriptografar o que passa por ele. O que ele faz é contar os bytes que retransmite em relação à cota mensal de retransmissão da conta que envia, puramente para medição e prevenção de abuso — sem nunca inspecionar o que há dentro.

Quando a comparação dá errado

Três desfechos, e só o primeiro é emergência. Saber qual deles está diante de você já é a maior parte do valor.

O que você vê, o que checar, o que significa

As duas telas mostram códigos diferentes.

https://relayium.com/   # the two screens show different verification codes

Pare e não envie o arquivo. Códigos diferentes significam que as duas pontas fixaram impressões digitais de certificado distintas, então o outro lado não é a máquina que você imagina. Confirme por um canal à parte em qual aparelho a outra pessoa está e recomece. Rodar de novo com --verify faz a transferência esperar nessa comparação em vez de deixá-la por conta da sua atenção.

Nenhum código de verificação apareceu.

https://relayium.com/   # no verification code on screen yet

O código é derivado de uma conexão, então existe assim que as duas pontas se conectam. Antes disso não há o que comparar, e uma transferência que nunca conecta é um problema diferente de uma cujos códigos divergem.

Você comparou os códigos colando um deles na conversa que já estava usando.

relayium send --verify ./report.pdf   # holds the transfer at the comparison

Isso não testa o que você queria testar. Se é justamente esse canal que preocupa você, um atacante capaz de alterar a transferência também consegue alterar o código colado. Leia em voz alta, ou use um canal que falhe de um jeito diferente daquele que você está conferindo.

Perguntas frequentes

O Relayium pode ler meus arquivos?

Não. No modo tempo real, a chave de criptografia é derivada independentemente em ambos os dispositivos e nunca os deixa — os servidores do Relayium nunca a veem, nem o conteúdo dos arquivos. Para os links armazenados, a chave vive apenas no fragmento da URL, que os navegadores nunca enviam a nenhum servidor, então o servidor só chega a guardar texto cifrado que não pode descriptografar.

O que o servidor realmente vê?

No modo tempo real na mesma rede, apenas as informações de estabelecimento de conexão necessárias para apresentar dois dispositivos um ao outro — nunca os bytes do arquivo. Entre redes, o retransmissor TURN de fato transporta esses bytes, mas apenas como texto cifrado do qual não tem a chave. Para os links armazenados, ele vê texto cifrado mais dados administrativos como tamanho e hora de expiração — nunca o texto claro, os nomes dos arquivos ou a chave de descriptografia.

O retransmissor TURN é um ponto fraco?

No navegador ele transporta, por decisão de projeto, todas as transferências entre redes, e não apenas aquelas em que um caminho direto falhou — mas ele sempre lida somente com texto cifrado, e não tem chave, então não pode ler o que retransmite. O Relayium conta os bytes que retransmite em relação à cota mensal da sua conta, mas nunca inspeciona o conteúdo deles.

O Relayium é de código aberto?

Sim. O design do protocolo e todo o código de cliente e servidor são públicos no GitHub sob a licença AGPL-3.0, então a criptografia descrita aqui pode ser auditada de forma independente em vez de aceita por fé.

E se os dois códigos de verificação na tela não coincidirem?

Pare a transferência. Dois códigos diferentes significam que os dois dispositivos não estão vendo a mesma conexão — é exatamente o que uma chave substituída ou um intermediário produziria, e não uma falha inofensiva. (Uma falha no handshake de comprometer-e-depois-revelar é outra coisa, e ocorre antes: ela aborta a própria conexão, sem exibir código algum.) Não prossiga até entender o motivo.

Curioso para ver como isso fica na prática? Ative a verificação avançada antes de iniciar uma nova conexão: assim a comparação do código e as etapas de confirmação valem desde o início.

Experimente o Relayium agora