「암호를 걸었다」는 「압축 파일 전체를 잠갔다」가 아닙니다
암호 걸린 ZIP은 열쇠 없는 상자처럼 보이기 쉽습니다. 파일을 가진 사람도 암호가 없으면 속을 못 본다고 생각합니다. 형식은 그보다 잘게 나뉩니다. ZIP은 먼저 디렉터리가 있고, 그다음 파일이 줄줄이 붙습니다. 암호화 플래그는 각 파일의 로컬 헤더와 중앙 디렉터리에 붙습니다. .zip 파일 전체에는 붙지 않습니다. 암호를 걸었다는 말은, 적어도 한 항목의 압축 데이터 흐름이 어떤 알고리즘으로 덮였다는 뜻입니다. 디렉터리를 못 읽는다는 뜻이 아닙니다. 모든 항목이 같은 알고리즘, 같은 암호를 썼다는 뜻도 아닙니다.
한국 사무실에서는 오래전부터 『압축해서 보내고, 비밀번호는 다음 메일이나 카카오톡으로』가 쓰여 왔습니다. 상대가 알집이나 반디집, 파일 탐색기에서 더블클릭만 되면 충분하다는 판단입니다. 급여 대장, 신분증 스캔, SSH 비밀 키, 데이터베이스 덤프, 가리지 않은 고객 표는 지금 연 폴더 밖으로 평문 단서를 더 남겨도 되는 내용이 아닙니다. 물을 것은 『이 압축 프로그램이 똑똑한가』가 아닙니다. 『이번 한 번의 묶음이, 나가면 안 되는 내용을 평문 파일명, 평문 항목, 약한 암호 흐름으로 넘기지 않았는가』입니다. 앞 글은 가까운 다른 넘김을 썼습니다. 암호화하지 않은 파일을 클라우드에 올리면 사업자, 동기화 클라이언트, 콘텐츠 해시에 원문이 남을 수 있습니다. 먼저 암호 걸린 ZIP을 만든 뒤 올리는 일은, 질문을 『클라우드가 파일을 볼 수 있는가』에서 『이 컨테이너는 어느 층을 잠갔는가』로 옮길 뿐입니다.
이 글은 PKWARE의 APPNOTE.TXT 6.3.10(2022년 11월 1일), WinZip AES 규격 AE-1 / AE-2, 그리고 7-Zip이 7z 형식의 AES-256을 설명한 문장에 둡니다. 층이 공개문으로 확인되고, 이 기기의 목록과 맞추기 쉽기 때문입니다. 사내 정책, 웹의 『암호화 압축』, 옛 화면은 한 층을 더 겹칩니다. 도구를 바꾸면 그 버전의 암호화 옵션과 Method를 다시 보세요. 아래 ZipCrypto 문장을, 이미 AES-256을 고른 압축이나 「파일 이름 암호화」를 켠 압축에 그대로 붙이지 마세요.
전통 암호화, AES 확장, 파일명 암호화는 서로 다른 세 층입니다
『ZIP이 암호화되었는가』를 예/아니오로 물으면 적어도 세 층이 빠집니다. 첫째는 전통 PKWARE 암호화입니다. 화면에는 ZipCrypto나 Zip 2.0으로 나오는 경우가 많습니다. APPNOTE 제6절은 대상을 좁게 적습니다. PKZIP이 암호화하는 것은 압축한 뒤의 데이터 흐름입니다. 암호화된 각 파일은 데이터 영역 앞에 12바이트 암호화 헤더를 둡니다. 32비트 키 셋이 암호로 초기화되고, ZIP이 원래 쓰는 CRC-32로 갱신됩니다. 확장자는 여전히 .zip입니다. 파일 탐색기나 옛 압축 프로그램은 암호 칸을 띄우는 경우가 많습니다. 호환은 좋습니다. 강도는 다른 질문입니다.
둘째는 같은 ZIP 컨테이너에 나중에 더해진 AES입니다. WinZip은 기본 구조를 바꾸지 않고 한 가지만 더합니다. 압축 메서드를 십진 99로 두고, 로컬 헤더와 중앙 디렉터리 양쪽에 11바이트 추가 필드 0x9901을 넣습니다. 공급자 식별은 ASCII AE입니다. 강도 바이트 0x01 / 0x02 / 0x03은 128, 192, 256비트 키에 대응합니다. 진짜 압축 메서드(예를 들어 Deflate의 8)는 이 추가 필드로 옮깁니다. AES를 모르는 옛 도구는 암호문을 평문으로 푸는 대신 『지원하지 않는 압축 메서드 99』를 내는 경우가 많습니다. 이 층이 지키는 것은 파일 내용입니다. 기본값으로는 중앙 디렉터리의 파일명을 암호문으로 바꾸지 않습니다.
셋째는 『디렉터리까지 덮는』 층입니다. ZIP의 Strong Encryption은 중앙 디렉터리 암호화를 선택 사항으로 적고, general purpose bit 6, bit 13 같은 깃발이 필요합니다. 전통 ZipCrypto에는 이 층이 없습니다. 7z 형식은 다른 길을 갑니다. 7-Zip 형식 페이지는 AES-256을 쓰고, 암호에서 SHA-256 기반 함수로 키를 만들며, 많은 반복으로 전수 탐색 비용을 올린다고 적습니다. 명령줄의 -mhe=on이 파일명을 암호화합니다. 이를 켜지 않으면 내용이 AES여도 목록이 먼저 이름을 냅니다. 7-Zip 한국어 화면은 「파일 이름 암호화」입니다. ZIP 형식으로 두면 이 칸이 기대한 대로 먹지 않는 경우가 많습니다. 이름까지 가리려면 압축 형식을 7z로 바꾼 뒤 켜세요. 한국에서 많이 쓰는 반디집 도움말도 ZIP·LHA는 파일명 암호화를 제공하지 않고, 파일명까지 숨기려면 7Z에서 「파일명 암호화」를 켜라고 적습니다.
| 층 | 대개 잠그는 것 | 기본으로 아직 보이기 쉬운 것 | 그 자리에서 알아보는 법 |
|---|---|---|---|
| ZipCrypto / 전통 PKWARE | 그 파일의 압축 데이터 흐름 | 파일명, 암호화하지 않은 항목, 압축 구조 | 7z l -slt의 Method에 ZipCrypto |
| WinZip AES (AE-1 / AE-2) | 그 파일의 내용 (AES + HMAC) | 파일명. 같은 압축의 암호화하지 않은 다른 항목 | 압축 메서드 99, 추가 필드 0x9901, Method에 AES- |
| 7z + 파일명 암호화 | 내용과 디렉터리 헤더 | -mhe=on이 꺼져 있으면 이름이 먼저 나올 수 있음 |
7-Zip의 「파일 이름 암호화」, 또는 -mhe=on |
제품 페이지나 오른쪽 클릭의 「AES-256」은 내용 알고리즘만 답합니다. 파일명이 평문 헤더에 있는지, 암호 없는 항목이 섞였는지는 답하지 않습니다. 확인할 때는 먼저 Method와 파일 목록을 보고, 그다음 암호 길이를 보세요.
ZipCrypto: 규격 스스로 약하다고 적으며, 알려진 평문 연구선을 막지 못합니다
전통 암호화가 약하다는 말은 거리의 소문이 아닙니다. 형식을 정의한 쪽이 이미 한 단 내려 놓았습니다. APPNOTE 6.0.1은 이 형식을 considered weak by today's standards라고 쓰고, 낮은 보안 요구 또는 더 옛 ZIP 프로그램과의 호환에 한정하라고 권합니다. 같은 절에 골격도 있습니다. 키 초깃값은 305419896, 591751049, 878082192의 32비트 정수 셋입니다. update_keys는 암호의 각 바이트마다 CRC-32를 부릅니다. 데이터 영역 앞의 12바이트 암호화 헤더가 키를 더 섞고, 끝의 1바이트 또는 2바이트를 CRC 상위와 대조해 암호가 맞아 보이는지 봅니다. 이는 스트림 암호입니다. AES-GCM처럼 인증 태그를 다는 블록 모드가 아닙니다.
규격은 12바이트 헤더의 목적을 『데이터에 대한 평문 공격을 무효로 만들기 위해서』라고도 적습니다. 공개 연구는 다른 길을 갔습니다. 1994년 Eli Biham과 Paul C. Kocher는 A Known Plaintext Attack on the PKZIP Stream Cipher를 내고, 알려진 평문 한 줄이 있으면 내부 상태를 되돌릴 수 있음을 보였습니다. Michael Stay의 2002년 ZIP Attacks with Reduced Known Plaintext는 필요한 평문 양을 더 낮췄습니다. 압축 파일에는 예측하기 쉬운 앞머리가 자주 붙습니다. PDF의 %PDF, Office 문서의 고정 헤더, XML 선언, PNG 서명입니다. 공격 절차는 이 글의 범위 밖입니다. 결론에 남길 요점은, 약점은 알고리즘에 있고 『암호가 6자라서』가 아니다입니다. 암호를 길게 해도 『전통 암호화는 규격이 약하다고 적었고, 알려진 평문 연구선이 있다』는 문장은 바뀌지 않습니다.
호환이, 아직 남아 있는 이유입니다. Windows 파일 탐색기는 보통 ZIP을 만들고 열 수 있지만, ZIP에 암호를 거는 기본 화면은 없습니다. Microsoft Q&A의 독립 자문 답변은, 암호를 걸려면 7-Zip 같은 다른 도구가 필요하고, 그런 도구가 만든 ZipCrypto 압축에는 탐색기가 입력칸을 띄우는 경우가 많다고 적습니다. 상대가 더블클릭만 하면 된다는 이유로 ZipCrypto를 기본으로 남겨 두는 소프트웨어는 적지 않습니다. 얻는 것은 『상대는 프로그램을 설치하지 않아도 된다』입니다. 치르는 것은 규격이 이미 인정한 약한 암호화입니다. 7-Zip은 ZIP을 AES-256으로 쓸 수 있습니다. 바꾼 뒤, ZipCrypto만 아는 시스템 압축 해제는 열지 못할 수 있습니다. 호환과 강도 사이의 선택이지, 『둘 다 암호화라고 쓰여 있으니 같다』가 아닙니다.
파일명, CRC, 암호화하지 않은 항목: 암호문 흐름에 들어가지 않은 것은 평문으로 남습니다
내용 층을 AES로 바꿔도 ZIP은 기본값으로 『목록을 볼 수 있는 컨테이너』입니다. 로컬 헤더와 중앙 디렉터리의 FileName은 평문 칸입니다. general purpose bit 0이 뜻하는 것은 이 항목의 데이터 흐름이 암호화되었다는 것뿐입니다. bit 11은 파일명이 UTF-8이라는 뜻이지, 파일명이 암호화되었다는 뜻이 아닙니다. 2004년 Tadayoshi Kohno의 WinZip 암호화 방식 분석은 형식 사실을 셋, 평이한 문장으로 적습니다. 암호화된 파일의 메타데이터는 새고, 파일명은 인증되지 않으며, 같은 압축에 암호화된 파일과 암호화하지 않은 파일을 동시에 둘 수 있다. 구현 결함이 아니라 컨테이너가 허용하는 모양입니다.
WinZip 자신의 AES 설명은 섞인 압축을 정식으로 허용합니다. ZIP 안 파일을 모두 암호화하라는 요구는 없습니다. 암호화된 파일이 같은 방법, 같은 암호를 쓰라는 요구도 없습니다. 하나의 압축은 암호화하지 않은 파일과 Zip 2.0, AES-128, AES-192, AES-256을 마음대로 조합할 수 있습니다. 폴더 항목은 용량을 줄이려면 암호화하지 않는 편이 낫다고까지 적혀 있습니다. 실무의 결과는 이렇습니다. 급여-2026-09.xlsx와 readme.txt를 같은 압축에 넣으면, 표만 암호를 묻고 설명문과 디렉터리 이름은 파일을 가진 사람이면 읽습니다. 받는 사람, 메일 중계, 드라이브 미리보기, 동기화 클라이언트가 먼저 보는 것은 이 목록인 경우가 많습니다. 푼 뒤의 칸이 아닙니다. 한국의 『비밀번호 따로 보내기』도 이 층은 고치지 않습니다. 다음 메일이나 카카오톡에서 암호를 숨겨도, 첫 첨부 헤더는 이미 이름을 내놓았습니다.
평문 헤더에는 크기와 검사값도 있습니다. WinZip은 AE-1이 암호화하지 않은 내용의 CRC를 ZIP 헤더에 두고, AE-2는 CRC를 0으로 두고 10바이트 인증 코드로 완전성을 본다고 적습니다. FAQ의 이유는, 4바이트 이하 파일에서는 CRC 자체가 원문 추정을 도우며 어떤 암호화를 썼는지와 무관하다는 것입니다. WinZip 11부터 대부분의 파일은 완전성 확인을 늘리려고 AE-1로 돌아갑니다. 다만 압축하지 않은 크기가 20바이트 미만인 파일과, 스스로 검사를 가진 BZIP2는 AE-2로 두고 CRC를 넣지 않습니다. 키 유도는 PBKDF2(RFC 2898), 반복 1000회, 의사난수 함수는 HMAC-SHA1입니다. 규격은 HMAC-SHA1 출력이 160비트라고도 적습니다. 따라서 192 / 256비트 AES의 실효 탐색 공간을 이론 키 길이 그대로 읽을 수는 없습니다. 이 숫자를 『깨뜨릴』 필요는 없습니다. 공개 규격에 이미 적혀 있습니다.
그 자리에서 확인하기: 원문을 풀지 말고, 먼저 Method와 파일명을 보세요
『암호를 걸었으니 안전하다』는 구호는 그 자체로 증명이 되지 않습니다. 확인은 이 기기에서 끝나는 몇 걸음으로 나누고, 각 걸음은 질문 하나에만 답하세요. 실제 급여표, 인증서, 비밀 키로 실험하지 마세요.
지금 쓰는 신분증 스캔, 운영 키, 살아 있는 직원 표를 『어떤 모양인지』 보려고 묶지 마세요. 버려도 되는 카나리아를 준비하세요. 예는 파일명 canary-payroll-20260905.txt, 본문은 한 번만 쓰는 표식입니다. 확인하는 것은 디렉터리와 Method이지, 진짜를 한 번 더 압축하는 일이 아닙니다.
- 메모장으로 카나리아 텍스트를 쓰고, 파일명은 일부러 업무처럼 보이게 하세요. 예는
canary-payroll-20260905.txt입니다. 무작위 암호가 필요하면 비밀번호 생성기에서 6–128자를 뽑으세요(기본 16. 8 미만은 약하다고 나옵니다). 이 문자열은 압축 암호로만 쓰고, 새 로그인 비밀번호로는 쓰지 마세요. - 평소 보내는 방식으로 ZIP을 하나 만드세요. 기본이 ZipCrypto인 프로그램도, AES-256을 손으로 고르는 프로그램도 있습니다. 주제를 숨기려고 파일명을 바꾸지 마세요. 7z를 하나 더 만들어 「파일 이름 암호화」를 켠 것과 끈 것을 견주세요.
- 아직 암호를 넣지 마세요. 7-Zip으로 열거나 터미널에서
7z l -slt canary.zip을 실행합니다. 목록에 이미canary-payroll-20260905.txt가 나오는지 보세요. 다음으로Method =줄을 찾습니다.ZipCrypto면 전통 암호화,AES-256이면 내용 층의 AES입니다. 본문을 풀지 않아도 이 두 항목이 읽히면, 그것들은 『먼저 암호를 넣어야 하는』 층에 있지 않습니다. - 7z도 같은 방식으로 목록을 냅니다. 파일명 암호화가 꺼져 있으면 이름은 아직 나오는 경우가 많습니다.
-mhe=on을 켜면 암호를 넣기 전까지 카나리아 이름이 나오면 안 됩니다. 셋째 층이 있는지의 대조이지, 『7z는 ZIP보다 반드시 신비하다』가 아닙니다. 차이는 디렉터리 헤더가 덮였는지입니다. - 카나리아 압축을 평소 쓰는 드라이브나 메일 임시보관함에 두세요(다른 사람에게는 보내지 마세요). 미리보기나 웹 화면이 안쪽 파일명을 내는지 보세요. 앞 글은 암호화하지 않은 파일의 즉시 업로드와 미리보기가 원문을 본다고 썼습니다. 여기서는 내용이 잠겨 있어도 디렉터리 이름이 먼저 색인될 수 있습니다. 끝나면 카나리아 압축과 원본을 지우고 휴지통도 보세요.
첫 확인의 세부, 곧 이 기기가 평문 본문을 압축 프로그램에 넘겼는가는 브라우저에서 암호화할 때, 평문이 나가지 않았는지 직접 확인하는 법과 다릅니다. 압축 프로그램은 묶기 위해 거의 반드시 이 기기에서 원문을 읽습니다. 이 글이 확인하는 것은 『묶은 뒤, 암호문 흐름에 들어가지 않은 것은 아직 무엇인가』입니다. 카나리아 파일명이 암호를 넣기 전에 7z l -slt나 드라이브 미리보기에 나오면, 신뢰 경계는 『상대는 암호를 모른다』보다 큽니다. Method가 아직 ZipCrypto면 산 것은 호환이지, 규격이 말하는 강한 암호화가 아닙니다.
열자마자 쓰는 파일 암호화로 「파일 전체 암호문」과 「압축 암호」를 나누세요
원하는 것이 『먼저 이 기기에서 파일 전체를 암호문으로 만든 뒤, 메일인지 드라이브인지는 나중에 정한다』라면 가입은 필요 없습니다. 파일을 MakePwd에 넘길 필요도 없습니다. 파일 암호화를 열고, 지금 탭에서 AES-256-GCM을 조각마다 걸어 .lock 또는 .enc를 받으세요. 암호는 PBKDF2-HMAC-SHA256, 100,000회로 늘리고, 파일마다 독립 salt를 씁니다. 단일 파일은 5 GB까지입니다. 파일, 암호, 평문은 업무 데이터로 올리지 않습니다. 모든 도구는 열자마자 쓰며, 계정이 없고, 이 문자열을 맡아 두는 비밀번호 보관함도 없습니다.
파일 암호화가 답하는 것은 『이 바이트가 브라우저를 떠나기 전에 암호문이 되었는가』입니다. 『ZIP은 기본으로 파일명을 잠그는가』에는 답하지 않습니다. 내려받기 이름은 스스로 정할 수 있으므로, 급여명세서-2026.xlsx.zip처럼 주제를 광고하는 이름을 낼 필요는 없습니다. .lock 머리에는 원래 파일명이 남을 수 있으니, 이름 자체가 민감하면 암호화하기 전에 바꾸세요. 암호문은 드라이브나 메일을 지나갈 수 있습니다. 암호는 다른 경로로 보내세요. 예는 일회용 링크입니다. 키는 URL의 # 프래그먼트에 있고, HTTP와 함께 서버로 가지 않습니다. 만들기와 읽기 모두 공개이며, 서버가 잠시 두는 것은 암호문뿐입니다. 무작위 암호가 필요하면 비밀번호 생성기에서 6–128자를 뽑아 그 페이지에서만 복사하세요. 암호화하지 않고 클라우드에 올린 뒤 사업자가 아직 무엇을 보는지는 앞 글입니다. 이 글은 『암호 걸린 ZIP 뒤에 아직 무엇이 남는가』만 결론의 선으로 내립니다.
자주 묻는 질문
ZIP에 암호를 걸면 압축 파일 전체가 암호화됩니까?
아닙니다. PKWARE APPNOTE는 암호화 플래그를 각 파일의 general purpose bit 0에 둡니다. 덮는 것은 그 항목의 압축 데이터 흐름이지, 컨테이너 전체가 아닙니다. 파일명은 로컬 헤더와 중앙 디렉터리에 있습니다. WinZip의 AES 설명은 같은 ZIP에 암호화하지 않은 항목과 Zip 2.0, AES-128, AES-192, AES-256을 섞을 수 있고, 암호도 달라도 된다고 적습니다.
ZipCrypto와 AES-256 ZIP은 무엇이 다릅니까?
ZipCrypto는 APPNOTE 제6절의 전통 PKWARE 암호화입니다. 32비트 키가 셋, 12바이트 암호화 헤더, CRC-32로 키를 갱신합니다. 규격 스스로 오늘날 기준으로는 약하다고 쓰고, 낮은 보안 요구 또는 옛 ZIP 프로그램과의 호환에 한정하라고 권합니다. WinZip AES는 추가 필드 0x9901, 압축 메서드 99, salt, 암호 검증값, HMAC-SHA1 인증 코드를 씁니다. 확장자는 둘 다 .zip이므로 봐야 할 것은 Method이지 접미사가 아닙니다.
암호를 넣지 않아도 안에 어떤 파일이 있는지 보입니까?
전통 ZIP과 파일명 암호화를 켜지 않은 압축에서는 대개 보입니다. 7-Zip의 7z l -slt는 평문을 풀지 않고 파일명과 Method를 냅니다. 7z 형식은 -mhe=on으로 파일명을 암호화할 수 있습니다. 그 층이 디렉터리 헤더까지 덮습니다. Windows 파일 탐색기에는 ZIP에 암호를 거는 기본 화면이 없습니다.
암호 걸린 ZIP과 MakePwd 파일 암호화는 같은 것입니까?
아닙니다. 압축 암호가 답하는 것은 그 컨테이너가 어떤 ZIP 암호화를 썼는가입니다. 파일 암호화는 지금 탭에서 AES-256-GCM으로 파일 전체를 암호화하고, .lock / .enc를 쓰며, 단일 파일은 5 GB까지이고, 파일과 암호는 올리지 않으며, 열자마자 씁니다. 암호는 다른 경로로 보내세요. 예는 일회용 링크의 # 프래그먼트입니다.
다음에 압축을 만들기 전에 기억할 세 가지
첫째, 『암호를 걸었다』는 적어도 한 파일의 데이터 흐름이 어떤 ZIP 암호화로 덮였다는 뜻입니다. 압축 디렉터리를 못 읽는다는 뜻이 아닙니다. 모든 항목이 암호화되었다는 뜻도 아닙니다. 둘째, ZipCrypto(규격이 약하다고 쓰고, 알려진 평문 연구선이 있음), WinZip AES(내용은 더 강함. 파일명은 기본으로 평문 헤더), 7z의 파일명 암호화는 서로 다른 세 경계입니다. 확장자가 .zip인지 .7z인지만으로는 지금 있는 층을 알 수 없습니다. 셋째, 한 번만 쓰는 카나리아와 7z l -slt로 Method와, 암호를 넣기 전에 나오는 이름을 확인하세요. 실제 표로 실험하지 마세요.
암호화하지 않고 클라우드에 올린 뒤 사업자가 아직 무엇을 보는지를 이어 묻는다면 암호화하지 않은 파일을 클라우드 드라이브에 올리면, 사업자·동기화 클라이언트·콘텐츠 해시가 아직 볼 수 있는 것을 읽으세요. 암호화 과정 자체가 평문을 이 기기 밖으로 보내지 않았는지를 그 자리에서 보려면 브라우저에서 암호화할 때, 평문이 나가지 않았는지 직접 확인하는 법이 있습니다. 암호를 따로 보내고 메일 본문에 두고 싶지 않으면 URL의 # 뒤에 키를 두기 좋은 이유, 그리고 이 보호가 깨지는 순간을 읽으세요. 이 글이 다루는 것은 『암호 걸린 ZIP을 보낸 뒤, 기본 암호화·파일명·암호화하지 않은 항목이 아직 무엇을 남기는가』를 결론에 적을 수 있는 범위로 내리는 일뿐입니다.