2026-07-25

비밀번호 건 ZIP 파일, 이메일로 보내도 정말 안전할까?

민감한 파일 — 서명된 계약서, 신분증 스캔본, 급여 스프레드시트 — 을 이메일로 보내기 전에 가장 흔히 하는 일 중 하나가 "일단 압축하고 비밀번호를 걸자"입니다. 문제를 해결한 것처럼 느껴집니다. 하지만 실제로 해결되는지는 서로 다른 두 가지 질문에 달려 있고, 이 둘은 자주 섞여서 생각됩니다: 비밀번호 보호 자체가 실제로 버텨주는가, 그리고 애초에 "파일을 이메일로 보낸다"는 워크플로에서 가장 큰 위험을 암호화가 해결해주기는 하는가. 두 질문 모두에 대한 정직한 답은 흔한 "압축파일 비밀번호 걸기" 안내글들이 말해주는 것보다 훨씬 구체적이며, 민감한 파일을 맡기기 전에 그 구체적인 내용을 정확히 알아둘 가치가 있습니다.

같은 ".zip" 확장자라도 같은 암호화가 아니다

ZIP 형식에는 같은 ".zip" 확장자와 같은 "비밀번호 추가" 체크박스 뒤에 전혀 다른 두 가지가 숨어 있습니다. 원래 방식인 ZipCrypto(흔히 "Zip 2.0" 암호화라고도 불립니다)는 1990년대 초부터 스펙에 포함되어 있었습니다. 더 나중에 추가된 옵션인 WinZip의 AES 확장은 진짜 AES-256에 제대로 된 키 유도 단계까지 갖춘 방식입니다. 어느 쪽이 적용될지는 전적으로 도구에 달려 있습니다 — 간단한 "압축파일에 비밀번호 걸기" 유틸리티나 일부 운영체제 내장 "압축" 기능은 여전히 ZipCrypto를 기본값으로 씁니다. 지구상의 거의 모든 압축 해제 도구가 열 수 있는, 가장 널리 호환되는 옵션이기 때문입니다. 대신 AES-256을 쓰려면 보통 7-Zip이나 WinRAR 같은 도구를 열어서 암호화 방식으로 AES-256을 명시적으로 선택해야 합니다. 처음 뜨는 대화상자에 그냥 비밀번호만 입력하는 것으로는 안 됩니다. 겉에서 보면 ZipCrypto 파일과 AES-256 파일은 똑같아 보입니다 — 확장자도 같고, 열 때 "비밀번호 입력" 프롬프트도 같습니다. 지금 내가, 혹은 공격자가 어떤 종류의 보호에 의존하고 있는지 알려주는 시각적 단서는 전혀 없습니다.

known-plaintext 공격, 구체적으로

ZipCrypto의 약점은 정도의 문제가 아닙니다 — "AES-256보다 약하다" 수준이 아니라, Eli Biham과 Paul Kocher가 수십 년 전에 발표했고 지금은 bkcrack이라는 무료 오픈소스 도구가 자동으로 실행해주는 구조적 결함입니다. ZipCrypto는 스트림 암호로 동작합니다: 32비트 내부 키 세 개가 키스트림을 생성하고 이를 파일 바이트와 XOR 하는데, 이 세 키는 암호화가 진행되는 동안 바이트 단위로, 평문 자체를 이용해 계속 갱신됩니다. 이 갱신 규칙 자체가 결함입니다. 공격자가 평문의 일부 — bkcrack 자체 문서에 따르면 이론상 단 12바이트만으로도 충분합니다 — 를 이미 알고 있다면, 이 갱신 규칙을 알려진 바이트로부터 거꾸로 계산해서 세 내부 키를 곧바로 복구할 수 있습니다. 비밀번호를 추측하는 과정 자체가 아예 필요 없습니다. 키가 복구되면 실제 비밀번호가 얼마나 길고 무작위적이었는지와 무관하게 압축파일 전체가 열립니다. 실제로 있었던, 날짜가 명확한 사례: 2025년 4월 7일자 badoption.eu의 글은 공격자가 이미 가지고 있던 공개된 Windows 시스템 DLL 파일의 평문 약 10,600바이트를 이용해 ZipCrypto로 보호된 압축파일의 보호를 무력화했고, 키 복구를 포함한 전체 과정이 7.75초 만에 끝났다고 밝히고 있습니다. 같은 글은 이 기법이 AES로 암호화된 zip에는 통하지 않는다는 점도 명확히 밝히고 있습니다 — 이 결함은 ZIP 비밀번호 일반이나 비밀번호 길이의 문제가 아니라 ZipCrypto의 설계 자체에 있는 문제입니다.

"이미 알려진 평문"은 대체 어디서 오는가

이 공격을 이론이 아니라 실전에서 쓸모 있게 만드는 함정은, 많은 파일이 전체가 다 비밀은 아니라는 점입니다. 표준 템플릿으로 만든 계약서는 온라인에 돌아다니는 같은 템플릿의 다른 사본들과 상용구 조항을 그대로 공유합니다. PDF, Word 문서, Excel 파일 — 이런 형식들은 실제 내용이 나오기 전에 고정된 구조적 바이트로 파일을 시작하며, 같은 소프트웨어로 만들어진 PDF나 오피스 문서들은 그 구조 중 상당 부분을 그대로 공유하는 경우가 많습니다. badoption.eu 예시의 DLL처럼 설치 프로그램이나 시스템 파일 폴더는 누구나 다운로드할 수 있는 공개된 미암호화 사본과 바이트 단위로 정확히 대조할 수 있습니다. 이 중 어느 것도 공격자가 여러분의 비밀번호나 내용을 알아야 하는 게 아닙니다 — 안에 어떤 종류의 파일이 들어 있을지 짐작하고, 그 일부와 충분히 일치하는 미암호화 사본을 찾아내기만(혹은 이미 가지고 있기만) 하면 됩니다.

파일을 보낸다는 것은 압축파일뿐 아니라 주소창도 믿는다는 것

완벽하게 암호화된 파일이라도 "이메일로 보내줘"의 나머지 절반 — 올바른 받은편지함에 도달하는가 — 은 해결해주지 않습니다. 영국 정보위원회(ICO)가 공개한 자체 사고 데이터를 Beyond Encryption이 분석한 결과, "잘못된 수신자에게 이메일로 전송된 데이터"는 2023년 ICO에 보고된 사고 유형 중 단연 가장 흔한 유형이었습니다 — 그해 총 11,074건의 보고된 사고 중 1,744건, 전체의 16%였고, 같은 해 피싱의 932건(약 8%)의 거의 두 배였습니다. 같은 분석에 따르면 이 패턴은 2024년 1분기까지도 이어져, 잘못된 수신자에게 보낸 이메일이 539건으로 여전히 가장 흔한 사고 유형이었습니다. 연락처 목록에서 자동완성이 엉뚱한 "김OO"을 채워 넣는 것, 전체 답장이 의도한 그룹 밖으로 나가는 것, 배포 목록에 남아 있던 오래된 주소 하나 — 어느 것도 특이한 일이 아닙니다. 규제기관 자체 수치에 따르면 이것이 데이터 유출이 시작되는 가장 흔한 경로이며, 피싱을 비롯해 추적된 다른 모든 원인보다도 앞섭니다. 그리고 이는 암호화가 특히 잘 막아주는 종류의 실수이기도 합니다 — 파일 자체가 올바른 패스프레이즈 없이는 열리지 않는다면, 엉뚱한 사람에게 보낸 메시지는 "이거 지워주세요"라는 후속 연락 정도로 끝나지, 서명된 계약서나 신분증 스캔본이 낯선 사람에게 노출되는 사고로 번지지는 않습니다. 다만 이 방어가 실제로 작동하려면, 첨부파일 안의 암호화가 정확히 앞서 설명한 그 공격을 버텨내는 종류여야 합니다.

보내기 전에 실제로 버텨주는 것

종합하면, 이메일로 보내려는 파일을 암호화할 때 실질적인 기준은 "비밀번호를 물어보는가"가 아니라, 그 프롬프트 뒤의 알고리즘이 ZipCrypto처럼 알려진 구조적 결함을 가진 것인지, 아니면 무작위 대입을 느리게 만들도록 설계된 비밀번호 스트레칭 함수 위에서 동작하는 현대적인 인증 암호(AES-256-GCM, 혹은 ChaCha20-Poly1305 같은 동급 방식)인지입니다. 압축 도구를 쓴다면 기본 "비밀번호 추가" 체크박스를 그냥 믿기보다 AES-256 옵션을 의도적으로 선택해야 하고, 애초에 지금 쓰는 도구가 그런 선택지를 제공하는지부터 확인해야 합니다 — 가장 단순한 도구들 중 상당수는 그 선택지 자체가 없습니다. 그리고 비밀번호 보호가 애초에 파일을 올바른 사람에게 보내는 것을 대신해줄 수는 없다는 것도 기억해야 합니다 — ICO 자체 수치가 보여주듯, 첫 번째 층이 미끄러지는 것은 "혹시"가 아니라 "언젠가"의 문제이며, 비밀번호 보호는 그때를 위한 두 번째 층입니다.

NearSeal이 여기서 하는 역할

이것이 바로 NearSeal이 메우려는 빈틈이며, NearSeal이 실제로 주장하는 것과 주장하지 않는 것을 정확히 구분해둘 가치가 있습니다. NearSeal은 전적으로 브라우저 안에서 동작합니다 — 파일도 패스프레이즈도 기기를 벗어나지 않고, 둘 중 어느 쪽도 업로드 단계를 신뢰할 필요가 없습니다. 암호화 자체는 두 가지 형식 중에서 고를 수 있고, 어느 쪽도 ZipCrypto가 아닙니다: 기본 NearSeal 형식은 PBKDF2-SHA256으로 2²⁰회 반복해 키를 유도하고 AES-256-GCM으로 암호화하며, 원하면 공개 age-encryption.org 형식(키 유도에 scrypt, 암호화에 ChaCha20-Poly1305)을 선택해 이 사이트뿐 아니라 실제 age나 rage CLI로도 열리게 할 수 있습니다. 둘 다 현대적인 인증 암호이고 그 앞에 의도적으로 느린 키 유도 단계를 두고 있습니다 — 앞서 설명한 known-plaintext 기법은 ZipCrypto의 스트림 암호 설계 자체에 있는 결함을 노리는 것이며, 그런 결함은 NearSeal이 만드는 두 형식 어디에도 존재하지 않습니다. NearSeal이 할 수 없는 일은 파일이 엉뚱한 사람에게 전달되는 것을 막는 것입니다 — 어떤 암호화 도구도 워크플로의 그 부분을 고쳐줄 수는 없습니다. NearSeal이 할 수 있는 일은, 그 실수가 실제로 일어났을 때 낯선 사람의 받은편지함에 도착하는 것이 몇 초 만에 무료로 뚫리는 체크박스 수준의 헛된 안심이 아니라, 지금도 꾸준히 관리되는 크래킹 도구조차 열 수 없는 암호문이 되도록 하는 것입니다.