Última atualização: 2026-07-09
“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.
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.
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 o exibem na tela. Se os códigos coincidem, as chaves não foram substituídas e ninguém está no meio. 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.
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.
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.
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.
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.
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.
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.
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é.
Pare a transferência. Uma divergência significa que a verificação de comprometer-e-depois-revelar falhou, o que aponta para um possível intermediário e não para uma falha inofensiva — não prossiga até entender o motivo.
Curioso para ver como isso fica na prática? Inicie uma transferência e veja o código de verificação aparecer você mesmo.
Experimente o Relayium agora