본문으로 건너뛰기
HexaTransfer
블로그로 돌아가기
비교 및 대안

파일 전송 암호화 방식 상세 비교

AES-256, RSA, ChaCha20, 종단간과 서버 측 암호화 방식을 포함한 파일 전송 암호화 방식을 기술적으로 비교합니다.

2026년 파일 전송 서비스는 다섯 가지 주요 암호화 방식을 사용합니다. TLS 전용(전송 중 암호화, 서버에서 평문), 서버 측 보관 AES-256(공급자가 키 보유), Web Crypto API 통한 클라이언트 측 AES-256-GCM(종단간, URL 프래그먼트에 키), XChaCha20-Poly1305 스트림 암호화(확장 nonce, libsodium과 Tresorit 사용), OpenPGP 하이브리드 암호화(Curve25519 ECC + AES-256 세션 키, Proton 사용). 올바른 선택은 위협 모델, 성능 요구 사항, 규제 요건에 따라 다릅니다.

다섯 가지 암호화 모델

모델 1: TLS 1.3만 사용. 파일이 네트워크 전송 중에 암호화되고 서버에 평문으로 저장됩니다. 예: TLS 상의 기본 FTP(FTPS), 보관 시 암호화 없는 HTTP POST 업로드. 수동적 네트워크 도청으로부터 보호하며 그 외에는 보호하지 않습니다.

모델 2: TLS + 서버 측 보관. AES-256이 저장된 파일을 암호화하며 공급자가 마스터 키를 보유합니다(주로 AWS KMS, GCP Cloud KMS 등). 예: WeTransfer, SwissTransfer, Dropbox. 저장 장치 절도에 대해 보호하며 내부자 접근, 법원 명령, 실시간 서버 침해에 대해서는 보호하지 않습니다.

모델 3: 대칭 키를 사용한 클라이언트 측 종단간 암호화. 브라우저 또는 클라이언트가 256비트 키를 파생하고 AES-256-GCM으로 암호화한 후 URL 프래그먼트 또는 외부 채널에 키를 배치합니다. 예: HexaTransfer, Send(Firefox Send 프로토콜 계열). 서버는 암호문만 보며 어떤 상황에서도 복호화할 수 없습니다.

모델 4: 인증된 스트림 암호. XChaCha20-Poly1305는 24바이트 nonce(ChaCha20-Poly1305의 12바이트 대비)를 사용하여 대용량 파일에서 생일 한계 충돌을 실행 불가능하게 만듭니다. 예: libsodium secretbox(Internxt), Tresorit Send. AES-NI 하드웨어 가속이 보편적이지 않은 경우(구형 Android 기기, IoT) ChaCha20이 소프트웨어에서 빠르게 실행될 때 선택합니다.

모델 5: 하이브리드 공개 키 + 대칭. OpenPGP(RFC 9580, 2024 개정)는 ECC Curve25519 또는 RSA-4096을 사용해 파일별 AES-256 세션 키를 암호화합니다. 예: Proton Drive, 전통적 GPG 파일 암호화. 비대칭 키 관리를 가능하게 하여 수신자의 공개 키가 있으면 공유 비밀이 필요하지 않습니다.

AES-256 대 ChaCha20: 실질적 차이

두 방식 모두 256비트 대칭 암호입니다. AES-256은 NIST 표준(FIPS 197)이며 하드웨어 가속을 갖추고 있습니다(x86의 AES-NI, 모바일의 ARM Cryptography Extensions). 최신 하드웨어에서 AES-256-GCM은 코어당 2-4 GB/s로 실행됩니다. ChaCha20-Poly1305는 순수 소프트웨어에서 코어당 1-2 GB/s로, AES-NI가 없는 하드웨어에서는 AES보다 빠릅니다. 4 GB 파일을 암호화하는 데스크톱에서는 두 방식 모두 2초 이내에 완료되며 네트워크가 병목입니다. 암호학적으로 2026년 기준 두 방식은 동등하게 안전한 것으로 간주됩니다.

RSA는 파일 전송에서 거의 사용되지 않음

RSA-4096은 작업당 512바이트 평문을 암호화합니다. 1 GB 파일을 RSA로 직접 암호화하는 것은 수백만 개의 512바이트 블록으로 분할해야 하므로 비현실적입니다. 패턴은 항상 하이브리드입니다. RSA가 파일별 AES-256 세션 키를 래핑하고 AES가 콘텐츠를 암호화합니다. ECC Curve25519는 더 빠르고 키가 작으며(256비트 ECC = 3072비트 RSA 보안) 타이밍 공격에 강하기 때문에 대부분의 새 설계에서 RSA를 대체했습니다. 2024년 OpenPGP는 이제 RSA보다 Curve25519(키 교환에 X25519)를 권장합니다. 레거시 SFTP 배포에서는 여전히 RSA를 볼 수 있습니다.

URL 프래그먼트 키가 중요한 이유

HexaTransfer와 Firefox Send 프로토콜 계열은 암호화 키를 URL 프래그먼트(# 이후)에 배치합니다. 브라우저는 사양에 따라(RFC 3986) HTTP 요청에서 프래그먼트를 전송하지 않습니다. 이는 서버가 GET /file/abc123 요청을 받지만 키를 포함하는 프래그먼트를 볼 수 없음을 의미합니다. 사용자가 전체 URL을 붙여넣거나 클릭하면 프래그먼트가 브라우저 메모리에 남아 클라이언트 측 복호화를 구동합니다. 이것이 부채널 없이 공유 가능한 종단간 암호화 링크를 전달하는 아키텍처적으로 우아한 방법입니다.

종단간 대 서버 측: 위협 모델 테스트

서버 측 암호화는 한 가지를 보호합니다. 저장 장치의 물리적 절도. 디스크가 도난당하면 보관 시 AES-256 암호화가 KMS가 침해될 때까지 데이터를 불투명하게 유지합니다. 종단간 암호화는 서버가 할 수 있는 모든 것으로부터 보호합니다. 법원 명령, 내부자 접근, 실시간 데이터에 접근하는 랜섬웨어, 국가 수준의 강제. 위협 모델이 "데이터 센터에서 드라이브 절도"라면 서버 측으로 충분합니다. "정부, 적대자, 또는 경쟁자가 서비스에 데이터 제출을 강제"라면 종단간 암호화만이 보호합니다.

인증된 암호화는 선택이 아님

MAC 없는 기본 AES-CBC는 선택된 암호문 쿼리로 암호문을 복호화할 수 있는 패딩 오라클 공격(BEAST, Lucky13)을 허용합니다. 현대 파일 전송은 AEAD를 사용해야 합니다. AES-256-GCM(NIST SP 800-38D) 또는 ChaCha20-Poly1305(RFC 8439). Poly1305 태그 또는 GCM 태그가 암호문과 연관 데이터(파일 크기, nonce, 파일명 헤더)를 인증합니다. 전송 중 비트가 뒤집히면 복호화가 명확히 실패합니다. 2026년에도 HMAC 래퍼 없이 AES-CBC를 사용하는 곳은 2010년에 머물러 있는 것입니다.

비밀번호 보호 전송을 위한 키 파생

사용자가 전송 보호를 위해 비밀번호를 입력할 때 비밀번호를 AES 키로 직접 사용할 수 없습니다. 엔트로피가 낮고 무차별 대입에 취약합니다. 현대적 키 파생: PBKDF2-SHA-256 600,000회 반복(OWASP 2023 권장), N=2^17의 scrypt, 또는 19 MiB 메모리와 2회 반복의 Argon2id. HexaTransfer는 600,000회 반복의 PBKDF2를 사용합니다. Tresorit는 Argon2id를 사용합니다. 두 방식 모두 GPU 가속 비밀번호 크래킹에 저항합니다. PBKDF2를 10,000회 반복(2015년 지침)으로 여전히 사용하는 공급자는 보안이 취약합니다.

비교 표

| 방식 | 기밀성 | 인증 | 서버가 평문 접근 | 양자 우려 | |---|---|---|---|---| | TLS 1.3만 | 전송 중 | 예 (암호 스위트의 MAC) | 예 | 키 교환 위험 | | 서버 측 AES-256 | 보관 시 + 전송 중 | 예 | 예 (키 보유) | 낮음 | | 클라이언트 측 AES-256-GCM | 전체 경로 | 예 (GCM 태그) | 아니오 | 낮음 | | XChaCha20-Poly1305 | 전체 경로 | 예 (Poly1305 태그) | 아니오 | 낮음 | | OpenPGP (Curve25519 + AES-256) | 전체 경로 | 예 (MDC/OCB) | 아니오 | Curve25519 위험 |

방식 선택 가이드

단기 보관 일회성 민감 전송: URL 프래그먼트 키를 사용하는 클라이언트 측 AES-256-GCM. HexaTransfer가 구현체입니다. GDPR·HIPAA·PIPA 규제 대상 지속 워크플로우: 감사 로그를 갖춘 XChaCha20-Poly1305(Tresorit). 키 관리가 필요한 다중 수신자: OpenPGP(Proton Drive, GPG). 대용량 분산 배포: 삭제 코딩을 더한 libsodium secretbox(Storj 기반 Internxt). 민감하지 않은 대용량: TLS + 보관 시 암호화로 충분합니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.

엔드투엔드 암호화로 대용량 파일을 안전하게 전송

엔드투엔드 암호화로 최대 10GB의 파일을 무료로 전송하세요. 계정이 필요하지 않습니다. 업로드 전에 브라우저에서 파일이 암호화되어 다른 사람은 읽을 수 없습니다.

파일 보내기