마지막 업데이트: 2026-07-09
"Relayium은 안전한가요?"는 합리적인 질문입니다——모든 파일 전송 도구가 프라이버시를 지킨다고 말하니까요. 이 페이지는 Relayium이 실제로 파일을 어떻게 보호하는지 쉬운 말로 짚어보아, 그 말을 그냥 믿는 대신 스스로 판단할 수 있게 해드립니다.
여기에는 서로 다른 두 가지 암호화 방식이 작동합니다. 상황이 두 가지이기 때문입니다. 지금 온라인 상태인 상대에게 실시간으로 파일을 보내는 경우와, 나중에 받아가도록 다운로드 링크를 남겨두는 경우입니다. 둘 다 서버가 당신의 파일에 접근하지 못하게 하지만, 그 방식은 서로 다릅니다——언제 어떤 방식이 적용되는지 알아둘 가치가 있습니다.
실시간으로 파일을 보낼 때——양쪽 모두 온라인 상태로, 브라우저 대 브라우저——Relayium은 먼저 각 기기가 X25519로 새로운 키 쌍을 생성하게 합니다. 이는 현대 보안 메신저에서 널리 쓰이는 것과 같은 타원곡선 키 교환 방식입니다(기술적으로는 libsodium의 crypto_kx). 각 기기는 개인 키를 자신만 갖고, 공개 키만 상대에게 보냅니다.
이 두 공개 키로부터 각 기기는 독립적으로 동일한 공유 비밀을 계산해냅니다——이는 비밀이 어딘가로 전송되었기 때문이 아니라, 타원곡선 키 교환이라는 방식 자체가 그렇게 작동하기 때문입니다. 이 공유 비밀은 두 브라우저 안에만 존재하는 AES-256-GCM 키가 됩니다. 파일의 각 청크는 발신 기기를 떠나기 전에 이 키와 고유한 논스로 봉인되므로, 네트워크를 지나가는 것——두 브라우저가 서로를 찾도록 도운 시그널링 서버를 포함해서——은 오직 암호문만 보게 됩니다.
여기서 솔직히 짚고 넘어갈 부분이 있습니다. WebRTC 자체 내장 암호화(DTLS)는 두 기기를 소개해주는 시그널링 서버를 통해 키 지문을 교환합니다. 만약 그 서버가 부정직하다면, 이론적으로는 중간에 끼어들어 자신의 키로 바꿔치기할 수 있습니다——고전적인 중간자 공격이며, 양쪽 브라우저 모두 즉시 알아차리지 못할 수 있습니다.
Relayium은 짧은 검증 코드로 이 틈을 막습니다. 두 기기는 각자의 공개 키에서 동일한 6자리 Short Authentication String(SAS)을 도출해 화면에 표시합니다. 두 코드가 일치하면 키가 바뀌지 않았고 중간에 아무도 없다는 뜻입니다. 하지만 단순한 6자리 코드는 약 20비트에 불과해서, 원칙적으로는 유리한 위치에 있는 공격자가 양쪽의 진짜 키를 본 뒤 일치하는 코드를 무차별 대입으로 만들어낼 여지가 있습니다. 이를 막기 위해 Relayium은 커밋 후 공개 핸드셰이크를 사용합니다. 각 측은 먼저 자신의 키에 대한 해시를 보내 커밋하고, 상대방의 커밋을 받은 후에야 진짜 키를 공개합니다. 이 순서 덕분에 악의적인 서버는 진짜 키를 보기도 전에 눈을 감은 채 가짜 키를 커밋해야 하며, 나중에 충돌하는 키를 고를 수 없습니다. 그래서 짧은 코드가 계속 신뢰할 수 있는 상태로 남는 것입니다.
암호화는 기밀성을 지켜주지만, 전송 도중 아무것도 손상되거나 변조되지 않았음을 자동으로 증명해주지는 않습니다. Relayium은 이를 별도로 확인합니다. 각 청크는 자체 AES-GCM 인증 태그를 가지고 있어, 변조된 청크는 애초에 복호화에 실패합니다. 여기에 더해, 각 파일이 전송되는 동안 양쪽 모두 그 평문 내용에 대해 SHA-256 해시를 계속 계산합니다. 파일 전송이 끝나면 발신 측의 해시와 수신 측의 해시를 비교합니다. 일치하면 디스크에 도착한 것은 보낸 것과 바이트 단위로 동일한 것이고, 일치하지 않으면 그 파일은 조용히 받아들여지는 대신 표시가 됩니다.
실시간 전송은 양쪽이 동시에 온라인이어야 합니다. 그것이 불가능할 때 Relayium은 대신 저장형 다운로드 링크를 제공합니다——이는 위의 실시간 방식과 혼동하지 말아야 할, 진짜로 다른 메커니즘을 사용합니다.
여기에는 키 교환이 없습니다. 아직 교환할 상대 기기가 존재하지 않기 때문입니다. 대신 당신의 브라우저는 하나의 무작위 AES-256-GCM 키를 생성하고, 무언가 업로드되기 전에 그것으로 파일을 암호화합니다. 이 키는 서버로 전혀 전송되지 않습니다——다운로드 링크의 # 문자 뒤에 덧붙는, 이른바 URL 프래그먼트에 놓입니다. 이 부분의 주소는 브라우저가 의도적으로 서버에 전송하지 않는 부분입니다. 결과적으로 서버는 복호화할 방법이 없는 암호문과, 암호문 크기·만료 시각 같은 관리 정보만 저장하게 됩니다. 프래그먼트를 포함한 완전한 링크를 여는 사람은 누구나 자신의 브라우저 안에서 로컬로 파일을 복호화할 수 있습니다. 그것이 없는 사람에게는 서버에서 그저 알아볼 수 없는 덩어리로만 보입니다. 이것이 영지식이라는 부분입니다. 서버는 암호화된 파일을 보관하지만, 그것을 읽을 수단은 한 번도 갖지 않습니다.
서버가 이 모든 과정에서 정확히 어디에 위치하는지 짚어볼 가치가 있습니다. "종단간 암호화"라는 말은 하기는 쉬워도 정확히 말하기는 어렵기 때문입니다. 실시간 모드에서는 파일 자체가 Relayium의 서버를 전혀 거치지 않습니다——두 브라우저 사이에서 직접 스트리밍됩니다. 시그널링 서버의 역할은 연결 설정 메시지(WebRTC가 직접 연결을 맺는 데 필요한 SDP/ICE 기술 정보)를 중계해 두 기기가 서로를 찾도록 돕는 데 국한됩니다. 파일 내용이나 파일 이름, 키를 보는 일은 전혀 없습니다.
직접 연결이 불가능할 때——양쪽 모두 제한적인 NAT나 방화벽 뒤에 있을 때——암호화된 스트림은 그대로 실패하는 대신 TURN 중계 서버로 대체됩니다. 중계 서버는 오직 암호문만 전달합니다. 키가 없으므로 그것을 통과하는 내용을 복호화할 수 없습니다. 중계 서버가 하는 일은 발신 계정의 월간 중계 허용량에 대해 중계한 바이트 수를 세는 것뿐이며, 이는 순전히 계량과 남용 방지를 위한 것으로, 내용을 검사하는 일은 결코 없습니다.
아니요. 실시간 모드에서 암호화 키는 두 기기에서 독립적으로 도출되며 기기를 떠나지 않습니다——Relayium의 서버는 이 키나 파일 내용을 전혀 보지 못합니다. 저장 링크의 경우 키는 URL 프래그먼트에만 존재하며, 브라우저는 이를 어떤 서버로도 보내지 않으므로 서버는 복호화할 수 없는 암호문만 갖게 됩니다.
실시간 모드에서는 두 기기를 서로 소개하는 데 필요한 연결 설정 정보만 봅니다——파일 바이트는 전혀 보지 않습니다. 저장 링크의 경우 암호문과 크기·만료 시각 같은 관리 정보를 봅니다——평문, 파일 이름, 복호화 키는 전혀 보지 않습니다.
직접 연결이 불가능할 때만 쓰이는 대체 수단이며, 항상 암호문만 다룹니다——키가 없으므로 중계하는 내용을 읽을 수 없습니다. Relayium은 중계한 바이트 수를 계정의 월간 허용량에 대해 집계하지만, 내용은 절대 검사하지 않습니다.
네. 프로토콜 설계와 클라이언트·서버의 모든 코드가 MIT 라이선스로 GitHub에 공개되어 있어, 여기서 설명한 암호화 방식을 그냥 믿는 대신 독립적으로 감사할 수 있습니다.
전송을 중단하세요. 코드가 일치하지 않는다는 것은 커밋 후 공개 검증이 실패했다는 뜻이며, 단순한 오류가 아니라 중간자 공격 가능성을 가리킵니다——이유를 파악하기 전까지는 계속 진행하지 마세요.
실제로 어떻게 보이는지 궁금하신가요? 전송을 시작해서 검증 코드가 나타나는 것을 직접 확인해 보세요.
지금 Relayium 사용해보기