파일 전송용 종단간 암호화 작동 방식

개인정보보호위원회(PIPC)와 KISA는 개인정보 보호법(PIPA) 제29조를 근거로 개인정보가 포함된 파일 전송 시 암호화를 의무화합니다. 파일 전송용 종단간 암호화(E2EE)는 기기를 떠나는 바이트가 서버에 절대 닿지 않는 키로 암호화된다는 것을 의미합니다. 서버는 암호문만 저장하고, 침해당해도 파일 내용이 노출되지 않습니다. 암호화 레시피는 거의 항상 파일 자체에는 AES-256-GCM 또는 XChaCha20-Poly1305 같은 대칭 암호화, 키 교환에는 X25519 ECDH 또는 RSA-OAEP 2048/4096의 조합입니다.

E2EE가 실제로 방어하는 위협 모델

E2EE는 구체적으로 다음을 방어합니다. 전송 제공자가 해킹당하거나, 법원 명령을 받거나, 악의적인 경우. 네트워크 공격자가 프록시에서 TLS 복호화 트래픽을 가로채는 경우. 스토리지 버킷 백업 스냅샷이 잘못된 손에 넘어가는 경우. 서비스 직원의 내부자 접근. E2EE가 방어하지 못하는 것은 송수신 기기의 악성코드, 복호화 링크를 탈취하는 피싱, 침해된 수신자 계정입니다. "암호화"가 종종 "전송 중 TLS + 서버의 AES-at-rest"를 의미하는 데 오용되는데, 이 경우 제공자가 키를 보유합니다.

파일 페이로드를 위한 대칭 암호화

파일은 공개 키 암호화가 대량 데이터에 너무 느리기 때문에 대칭 알고리즘으로 암호화됩니다. 현대적 선택은 NIST SP 800-38D에 정의된 AES-256-GCM으로, 한 번의 패스에서 기밀성과 인증된 무결성을 모두 제공합니다. 무작위 256비트 키와 고유한 96비트 논스(동일한 키로 절대 재사용하지 않음)가 각 파일을 보호합니다. RFC 8439와 RFC 8103에 정의된 XChaCha20-Poly1305는 AES-NI 하드웨어 가속이 없는 구형 ARM 프로세서처럼 AES보다 빠른 경우의 대안입니다. 두 알고리즘 모두 암호문과 모든 변조를 감지하는 128비트 인증 태그를 생성합니다.

비밀번호에서 키 파생

E2EE가 비밀번호를 사용할 때, 비밀번호 자체는 암호화 키가 되지 않습니다. 무차별 대입 공격에 너무 취약하기 때문입니다. 대신 PBKDF2-HMAC-SHA256(OWASP 2025 지침에 따라 600,000번 이상 반복), Argon2id(m=19 MiB, t=2, RFC 9106), 또는 scrypt(RFC 7914) 같은 키 파생 함수가 비밀번호를 강력한 키로 늘립니다. 무작위 128비트 또는 256비트 솔트가 레인보우 테이블 공격을 방지합니다. 결과 키로 파일을 암호화합니다. 솔트와 반복 횟수는 암호문과 함께 저장되어 수신자가 비밀번호를 입력할 때 키를 재구성할 수 있습니다.

계정 기반 전송을 위한 공개 키 래핑

수신자가 공개된 공개 키가 있는 계정을 보유한 경우, 비밀번호 입력이 필요 없습니다. 송신자는 무작위 파일 암호화 키(FEK)를 생성하고, FEK로 AES-256-GCM을 사용하여 파일을 암호화한 다음, RFC 7748의 X25519 ECDH 키 합의와 RFC 5869의 HKDF-SHA256을 조합하거나 PKCS#1 v2.2의 RSA-OAEP with SHA-256을 사용하여 각 수신자의 공개 키로 FEK를 암호화합니다. 래핑된 FEK는 암호문 옆에 저장됩니다. 수신자의 개인 키 보유자만 FEK를 풀고 파일을 복호화할 수 있습니다.

URL 프래그먼트를 이용한 링크 기반 E2EE

브라우저 기반 전송의 영리한 트릭은 복호화 키를 URL 프래그먼트(# 뒤 부분)에 저장하는 것입니다. 프래그먼트는 HTTP 요청에서 서버로 전송되지 않습니다. https://example.com/d/abc123#k=B9kZtR... 같은 링크는 서버 측 파일 ID와 클라이언트 측 키를 담습니다. 브라우저는 암호문을 다운로드하고, JavaScript에서 프래그먼트를 읽고, 로컬에서 복호화합니다. 서비스는 키를 볼 수 없습니다. 단, 링크가 로그, 스크린샷, 메시지 앱 미리보기 어디서든 노출되면 키도 함께 노출됩니다.

AEAD와 해시를 통한 무결성

GCM 및 ChaCha20-Poly1305 같은 인증 암호화(AEAD) 모드는 변조를 방지합니다. 암호문의 단 한 비트 뒤집기도 인증 태그 검증 실패를 일으키고, 복호화 함수는 잘못된 평문 대신 오류를 반환합니다. AEAD에 더해, 많은 구현이 송신자가 의도한 파일과 일치하는지 수신자가 복호화 후 검증할 수 있도록 평문의 SHA-256 또는 BLAKE3 해시를 매니페스트 항목으로 계산합니다.

대용량 파일을 위한 청크 암호화

10 GB 파일을 하나의 AES-GCM 작업으로 암호화하려면 10 GB의 상태를 유지해야 하므로 브라우저에서는 실용적이지 않습니다. 실제 구현은 파일을 청크(일반적으로 1~16 MB)로 분할하고 각 청크를 파생된 하위 키와 카운터 기반 논스로 독립적으로 암호화합니다. age 암호화 도구는 ChaCha20-Poly1305로 64 KB 청크를 사용합니다. 청크 경계는 브라우저가 Streams API를 통해 복호화를 스트리밍하게 하여 전체 파일이 도착하기 전에 디스크로 다운로드를 시작할 수 있게 하고, 네트워크 중단 시 재개 가능한 업로드를 지원합니다.

E2EE 위에 추가되는 전송 보안

RFC 8446에 정의된 TLS 1.3은 E2EE 위에서도 여전히 중요합니다. 페이로드 기밀성이 아닌 파일 이름, 크기, 타이밍 같은 메타데이터 프라이버시를 위해서입니다. X25519 같은 전방 비밀 키 교환을 사용하는 TLS 1.3은 나중에 서버의 장기 키가 침해되더라도 기록된 세션을 복호화할 수 없습니다. E2EE와 TLS 1.3의 조합은 파일 내용과 누가 누구에게 무엇을 보내는지의 운용 패턴을 모두 보호합니다.

서비스가 실제로 E2EE를 수행하는지 검증하는 방법

마케팅 주장을 비판적으로 읽으세요. 진정한 E2EE는 법원 명령을 받더라도 제공자가 파일을 복호화할 수 없음을 의미합니다. 정확한 알고리즘(AES-256-GCM, X25519, HKDF, PBKDF2 반복 횟수)을 설명하는 공개된 기술 문서, 감사 가능한 오픈소스 클라이언트 코드, E2EE가 방어하는 것과 방어하지 못하는 것을 인정하는 위협 모델을 찾으세요. 암호화된 파일에 대한 서버 측 비밀번호 복구를 제공하는 서비스는 진정한 E2EE가 아닙니다. HexaTransfer는 검토된 패턴으로 클라이언트 측 표준 Web Crypto 프리미티브를 사용합니다.

https://hexatransfer.com 에서 무료로 시작하세요. 계정 불필요, 최대 10 GB.