Relayium이 파일을 종단간 암호화하는 방식

마지막 업데이트: 2026-08-06

"Relayium은 안전한가요?"는 합리적인 질문입니다——모든 파일 전송 도구가 프라이버시를 지킨다고 말하니까요. 이 페이지는 Relayium이 실제로 파일을 어떻게 보호하는지 쉬운 말로 짚어보아, 그 말을 그냥 믿는 대신 스스로 판단할 수 있게 해드립니다.

여기에는 서로 다른 두 가지 암호화 방식이 작동합니다. 상황이 두 가지이기 때문입니다. 지금 온라인 상태인 상대에게 실시간으로 파일을 보내는 경우와, 나중에 받아가도록 다운로드 링크를 남겨두는 경우입니다. 둘 다 서버가 파일에 접근하지 못하게 하지만, 그 방식은 서로 다릅니다——언제 어떤 방식이 적용되는지 알아둘 가치가 있습니다.

실시간 전송: 서버가 절대 볼 수 없는 비밀을 두 기기가 합의하다

실시간으로 파일을 보낼 때——양쪽 모두 온라인 상태로, 브라우저 대 브라우저——Relayium은 먼저 각 기기가 X25519로 새로운 키 쌍을 생성하게 합니다. 이는 현대 보안 메신저에서 널리 쓰이는 것과 같은 타원곡선 키 교환 방식입니다(기술적으로는 libsodium의 crypto_kx). 각 기기는 개인 키를 자신만 갖고, 공개 키만 상대에게 보냅니다.

이 두 공개 키로부터 각 기기는 독립적으로 동일한 공유 비밀을 계산해냅니다——이는 비밀이 어딘가로 전송되었기 때문이 아니라, 타원곡선 키 교환이라는 방식 자체가 그렇게 작동하기 때문입니다. 이 공유 비밀은 두 브라우저 안에만 존재하는 AES-256-GCM 키가 됩니다. 파일의 각 청크는 발신 기기를 떠나기 전에 이 키와 고유한 논스로 봉인되므로, 네트워크를 지나가는 것——두 브라우저가 서로를 찾도록 도운 시그널링 서버를 포함해서——은 오직 암호문만 보게 됩니다.

전송마다 새로운 키 쌍이 생성되며, 세션 간에 재사용되지 않습니다.
공유되는 AES-256-GCM 키는 각 기기에서 독립적으로 도출되며, Relayium 자체 서버를 포함해 어디로도 전송되지 않습니다.
암호화는 WebRTC 자체의 전송 계층 보안 위, 애플리케이션 계층에서 이루어지므로 전송 계층이 침해되더라도 유효성을 유지합니다.

부정직한 서버를 잡아내는 6자리 코드

이 대조를 하려면 필요한 것

두 기기가 모두 눈앞에 있거나, 지금 자기 기기 앞에 있는 상대가 있을 것.
이 전송이 아닌 다른 경로 — 전화 통화, 또는 함께 있는 그 방. 걱정하고 있는 바로 그 대화창에 코드를 붙여 넣는 것은 아무것도 증명하지 못합니다.
10초. 정직하지 않은 서버를 잡아내는 유일한 확인의 비용 전부가 그것입니다.

여기서 솔직히 짚고 넘어갈 부분이 있습니다. WebRTC 자체 내장 암호화(DTLS)는 두 기기를 소개해주는 시그널링 서버를 통해 키 지문을 교환합니다. 만약 그 서버가 부정직하다면, 이론적으로는 중간에 끼어들어 자신의 키로 바꿔치기할 수 있습니다——고전적인 중간자 공격이며, 양쪽 브라우저 모두 즉시 알아차리지 못할 수 있습니다.

Relayium은 짧은 검증 코드로 이 틈을 막습니다. 두 기기는 각자의 공개 키에서 동일한 6자리 Short Authentication String(SAS)을 도출해 화면에 표시할 수 있습니다. 이를 표시하고 대조를 위해 멈출지는 «고급 검증»이며 기본값은 꺼짐입니다 — 즉 기본 전송에서는 코드가 표시되지 않습니다. 여기에서 설명하는 나머지, 곧 매번 새로 만드는 키와 암호화, 커밋 후 공개 핸드셰이크, 청크마다의 인증은 모든 전송에 그대로 적용됩니다. 기본 전송에 없는 것은 이 대조 자체입니다 — 키가 바뀌었는지, 상대가 의도한 사람이 아닌지 알아내려면 고급 검증을 켜고 두 사람이 실제로 다른 경로로 코드를 맞춰 봐야 합니다. 두 코드가 일치하면 공개 키가 바뀌지 않았으며, 시그널링 서버나 릴레이 서버가 어느 엔드포인트도 사칭하지 않았고 애플리케이션 계층의 종단 간 암호화를 종료하지 않았다는 뜻입니다. 이는 네트워크 경로에 서버가 없다는 뜻이 아닙니다——네트워크 간 암호문은 설계상 여전히 TURN을 통과할 수 있습니다. 하지만 단순한 6자리 코드는 약 20비트에 불과해서, 원칙적으로는 유리한 위치에 있는 공격자가 양쪽의 진짜 키를 본 뒤 일치하는 코드를 무차별 대입으로 만들어낼 여지가 있습니다. 이를 막기 위해 Relayium은 커밋 후 공개 핸드셰이크를 사용합니다. 각 측은 먼저 자신의 키에 대한 해시를 보내 커밋하고, 상대방의 커밋을 받은 후에야 진짜 키를 공개합니다. 이 순서 덕분에 악의적인 서버는 진짜 키를 보기도 전에 눈을 감은 채 가짜 키를 커밋해야 하며, 나중에 충돌하는 키를 고를 수 없습니다. 그래서 짧은 코드가 계속 신뢰할 수 있는 상태로 남는 것입니다.

두 기기 사이에 전송을 시작하고 각 화면에 검증 코드가 뜰 때까지 기다리세요.
```
https://relayium.com/
```
둘 중 하나를 대역 외 경로로 한 자리씩 소리 내어 읽으세요. 앱에 복사하거나 같은 대화창에 올리지 마세요.
여섯 자리를 모두 대조하세요. 일부만 맞는 것은 틀린 것입니다.
일치할 때만 수락하세요. 다르면 거절하고, 상대가 실제로 어느 기기에 있는지 확인한 뒤에 다시 시도하세요.
CLI에서는 이 대조를 선택이 아니라 차단으로 바꿀 수 있습니다. --verify는 그 지점에서 전송을 멈추고 확인을 기다리므로, 누군가 실제로 볼 때까지 단 1바이트도 움직이지 않습니다.
```
relayium send --verify ./report.pdf
```

일치한 대조가 증명하는 것과 하지 못하는 것

두 화면에 같은 여섯 자리가 뜬다는 것은 양쪽이 고정한 인증서 지문이 서로 맞는다는 뜻이고, 곧 랑데부가 종단을 바꿔치기하거나 어느 한쪽을 사칭하지 않았다는 뜻입니다. 이 절이 다루는 공격이 바로 그것입니다.

이것이 인증하는 것은 두 종단입니다. 그 사이 네트워크의 모든 구간에 대해서는 아무것도 증명하지 않으며, 아무도 대조하지 않으면 아무것도 증명하지 못합니다 — --verify가 있는 이유입니다.

가장 강력한 보장을 위해서는 먼저 고급 검증을 켠 다음, 나란히 놓인 두 화면을 눈으로 보기만 하지 말고 통화로 코드를 소리 내어 읽거나 직접 만나 대조하세요.
두 코드가 일치하지 않으면 중단하세요. 누군가 연결을 가로채고 있다는 신호로 받아들이세요.

도착한 것이 보낸 것과 정확히 같은지 확인하기

암호화는 기밀성을 지켜주지만, 전송 도중 아무것도 손상되거나 변조되지 않았음을 자동으로 증명해주지는 않습니다. Relayium은 이를 별도로 확인합니다. 각 청크는 자체 AES-GCM 인증 태그를 가지고 있어, 변조된 청크는 애초에 복호화에 실패합니다. 여기에 더해, 각 파일이 전송되는 동안 양쪽 모두 그 평문 내용에 대해 SHA-256 해시를 계속 계산합니다. 파일 전송이 끝나면 발신 측의 해시와 수신 측의 해시를 비교합니다. 일치하면 디스크에 도착한 것은 보낸 것과 바이트 단위로 동일한 것이고, 일치하지 않으면 그 파일은 조용히 받아들여지는 대신 표시가 됩니다.

저장 링크: 한 번만 생성되어 링크에만 존재하는 다른 키

실시간 전송은 양쪽이 동시에 온라인이어야 합니다. 그것이 불가능할 때 Relayium은 대신 저장형 다운로드 링크를 제공합니다——이는 위의 실시간 방식과 혼동하지 말아야 할, 진짜로 다른 메커니즘을 사용합니다.

여기에는 키 교환이 없습니다. 아직 교환할 상대 기기가 존재하지 않기 때문입니다. 대신 브라우저가 하나의 무작위 AES-256-GCM 키를 생성하고, 무언가 업로드되기 전에 그것으로 파일을 암호화합니다. 이 키는 서버로 전혀 전송되지 않습니다——다운로드 링크의 # 문자 뒤에 덧붙는, 이른바 URL 프래그먼트에 놓입니다. 이 부분의 주소는 브라우저가 의도적으로 서버에 전송하지 않는 부분입니다. 결과적으로 서버는 복호화할 방법이 없는 암호문과, 암호문 크기·만료 시각 같은 관리 정보만 저장하게 됩니다. 프래그먼트를 포함한 완전한 링크를 여는 사람은 누구나 자신의 브라우저 안에서 로컬로 파일을 복호화할 수 있습니다. 그것이 없는 사람에게는 서버에서 그저 알아볼 수 없는 덩어리로만 보입니다. 이것이 영지식이라는 부분입니다. 서버는 암호화된 파일을 보관하지만, 그것을 읽을 수단은 한 번도 갖지 않습니다.

저장 링크를 만들려면 발신자가 로그인해야 하지만, 다운로드를 위해 링크를 여는 데는 계정이 전혀 필요하지 않습니다.
링크는 1시간, 1일, 3일, 7일, 최대 14일(요금제에 따라 다름) 후 만료되도록 설정하거나, 첫 다운로드가 완료된 후 소멸하도록 설정할 수 있습니다.
완전한 링크를 파일 자체처럼 다루세요——그것을 가진 사람은 누구나 복호화할 수 있으므로, 파일을 공유할 때처럼 신중하게 공유하세요.

서버가 볼 수 있는 것, 그리고 볼 수 없는 것

서버가 이 모든 과정에서 정확히 어디에 위치하는지 짚어볼 가치가 있습니다. "종단간 암호화"라는 말은 하기는 쉬워도 정확히 말하기는 어렵기 때문입니다. 같은 네트워크의 실시간 모드에서는 파일 자체가 Relayium의 서버를 전혀 거치지 않습니다——두 브라우저 사이에서 직접 스트리밍됩니다. 시그널링 서버의 역할은 연결 설정 메시지(WebRTC가 직접 연결을 맺는 데 필요한 SDP/ICE 기술 정보)를 중계해 두 기기가 서로를 찾도록 돕는 데 국한됩니다. 파일 내용이나 파일 이름, 키를 보는 일은 전혀 없습니다.

네트워크를 넘는 전송에서는——제한적인 NAT나 방화벽 뒤에서는 직접 경로가 열리지 않는 경우가 많기 때문에——암호화된 스트림이 TURN 릴레이 서버를 거칩니다. 릴레이 서버는 오직 암호문만 전달합니다. 키가 없으므로 그것을 통과하는 내용을 복호화할 수 없습니다. 릴레이 서버가 하는 일은 발신 계정의 월간 릴레이 허용량에 대해 릴레이한 바이트 수를 세는 것뿐이며, 이는 순전히 계량과 남용 방지를 위한 것으로, 내용을 검사하는 일은 결코 없습니다.

대조가 어긋날 때

결과는 세 가지이고, 급한 것은 첫 번째뿐입니다. 지금 보고 있는 것이 어느 쪽인지 아는 것만으로 대부분의 값어치를 얻습니다.

보이는 것, 확인할 것, 그 의미

두 화면의 검증 코드가 다릅니다.

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

멈추고 파일을 보내지 마세요. 코드가 다르다는 것은 양쪽이 고정한 인증서 지문이 어긋난다는 뜻이고, 저쪽은 생각한 그 기기가 아닙니다. 상대가 어느 기기에 있는지 대역 외로 확인한 다음 다시 시작하세요. --verify를 붙여 다시 실행하면 전송이 그 대조 앞에서 기다리므로, 주의력에 맡기지 않아도 됩니다.

검증 코드가 아직 나타나지 않았습니다.

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

코드는 연결에서 유도되므로 양쪽이 연결된 뒤에야 존재합니다. 그 전에는 대조할 것이 없고, 「아예 연결되지 않는다」는 「코드가 어긋난다」와 다른 문제입니다.

이미 쓰고 있던 대화창에 코드를 붙여 넣어 대조했습니다.

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

그렇게 하면 확인하려던 것을 확인하지 못합니다. 걱정하는 대상이 바로 그 경로라면, 전송을 바꿀 수 있는 공격자는 붙여 넣은 코드도 바꿀 수 있습니다. 소리 내어 읽거나, 지금 점검 중인 경로와 고장 방식이 다른 경로를 쓰세요.

자주 묻는 질문

Relayium이 제 파일을 읽을 수 있나요?

아니요. 실시간 모드에서 암호화 키는 두 기기에서 독립적으로 도출되며 기기를 떠나지 않습니다——Relayium의 서버는 이 키나 파일 내용을 전혀 보지 못합니다. 저장 링크의 경우 키는 URL 프래그먼트에만 존재하며, 브라우저는 이를 어떤 서버로도 보내지 않으므로 서버는 복호화할 수 없는 암호문만 갖게 됩니다.

서버는 실제로 무엇을 보나요?

같은 네트워크의 실시간 모드에서는 두 기기를 서로 소개하는 데 필요한 연결 설정 정보만 봅니다——파일 바이트는 전혀 보지 않습니다. 네트워크를 넘을 때는 TURN 릴레이가 실제로 파일 바이트를 나르지만, 키가 없는 암호문으로서만 그렇습니다. 저장 링크의 경우 암호문과 크기·만료 시각 같은 관리 정보를 봅니다——평문, 파일 이름, 복호화 키는 전혀 보지 않습니다.

TURN 릴레이가 약점이 되지 않나요?

브라우저에서는 직접 연결이 실패했을 때만 쓰이는 것이 아니라 설계상 네트워크 간 전송 전부를 담당합니다——다만 항상 암호문만 다루고, 키가 없으므로 릴레이하는 내용을 읽을 수 없습니다. Relayium은 릴레이한 바이트 수를 계정의 월간 허용량에 대해 집계하지만, 내용은 절대 검사하지 않습니다.

Relayium은 오픈 소스인가요?

네. 프로토콜 설계와 클라이언트·서버의 모든 코드가 AGPL-3.0 라이선스로 GitHub에 공개되어 있어, 여기서 설명한 암호화 방식을 그냥 믿는 대신 독립적으로 감사할 수 있습니다.

화면에 표시된 두 검증 코드가 일치하지 않으면 어떻게 하나요?

전송을 중단하세요. 두 코드가 다르다는 것은 두 기기가 같은 연결을 보고 있지 않다는 뜻입니다 — 키가 교체되었거나 중간자가 있을 때 정확히 이렇게 나타나며, 단순한 오류가 아닙니다. (커밋 후 공개 핸드셰이크 실패는 이보다 앞서 일어나는 별개의 실패로, 코드가 표시되기도 전에 연결 자체가 중단됩니다.) 이유를 파악하기 전까지는 계속 진행하지 마세요.

실제로 어떻게 보이는지 궁금하신가요? 새 연결을 시작하기 전에 고급 검증을 켜 두면 코드 대조와 확인 단계가 처음부터 적용됩니다.

지금 Relayium 사용해보기