클라우드에 올리기 전, 압축파일 비밀번호가 막는 범위와 그것이 기기 AES-256-GCM이 아닌 이유

검색 의도를 한 문장으로 먼저 답하기

클라우드에 올리기 전 ZIP에 비밀번호를 거는 일과, 이 기기의 AES-GCM은 지키는 층이 다릅니다. 전자는 파일을 ZIP 용기에 넣고 용기 안 파일 내용에 자물쇠를 겁니다. 용기 자신의 디렉터리, 곧 파일 이름, 날짜, 크기는 ZIP 설계상 목록용입니다. 후자는 브라우저 Web Crypto API로 바이트에 AES-256-GCM을 걸고, 암호문을 내려받은 뒤 올립니다. 복호화 비밀번호가 없으면 클라우드에 남는 것은 난수에 가까운 데이터입니다.

이 글은 개발자, 운영, 그리고 백업을 클라우드에 두기 전에 「비밀번호를 걸었다」와 「상대가 내용을 못 본다」를 나누고 싶은 사람을 위한 것입니다. 파일 암호화 사용 설명을 대신하지 않으며, .lock을 만드는 클릭 순서도 반복하지 않습니다. 가져가야 할 것은 ZipCrypto와 ZIP-AES가 각각 막는 범위, 클라우드 기본 암호의 키 위치, 기기 암호화 후 파일 머리에 남는 것, Network와 16진 덤프로 그 자리에서 대조하는 방법입니다.

「비밀번호를 걸었다」와 「클라우드가 내용을 못 본다」는 다른 문장입니다

일상어의 「이 파일은 암호화됐다」는 세 일을 한 문장으로 접습니다. 첫째는 전송 암호화입니다. 브라우저와 클라우드 사이는 HTTPS이므로, 경로의 구경꾼은 원문을 읽기 어렵습니다. 둘째는 사업자의 저장 시 암호화입니다. 디스크 위 블록을 사업자 키로 감싸므로, 매체가 반출됐을 때 바로 읽기 어려워집니다. 셋째는 당신이 키를 가진 클라이언트 측 암호화입니다. 올리기 전에 내용은 이미 암호문이며, 비밀번호가 없으면 사업자는 열지 못합니다.

압축파일 비밀번호는 이 세 층 밖에 있는 네 번째 습관입니다. 이 기기에서 비밀번호 달린 용기를 만든 뒤, 그 용기를 평범한 파일로 올립니다. 클라우드의 처리는 암호화하지 않은 .zip과 본질적으로 같습니다. 파일 이름으로 색인을 만들고, 해시로 동일 여부를 판단하며, 정책이 있으면 바이러스나 민감 정보를 훑습니다. 안이 ZipCrypto이거나 디렉터리가 평문이면, 검사 프로그램은 「비밀번호를 맞히기」 전에 파일 이름을 읽습니다. 내용까지 들어갈 여지도 있습니다.

한국 사무실에서는 암호 걸린 압축파일을 메일로 보내고, 다음 메일이나 카카오톡으로 비밀번호를 보내는 방식이 오래 쓰였습니다. 자리를 메일에서 네이버 마이박스, Google 드라이브, OneDrive로 옮긴다고 키의 위치는 바뀌지 않습니다. 「비밀번호를 걸었다」가 받쳐 주는 결론은 좁습니다. 압축을 풀지 않는 사람, 비밀번호가 없는 사람은 내용을 열기 어렵다, 까지입니다. 「직원이 못 본다」「법령 제출에서 원문이 안 나온다」「파일 이름이 색인에 안 들어간다」는 여기서 말할 수 없습니다. 뒤의 문장을 관찰할 수 있는 사실로 만들려면 층을 바꾸세요. 이 기기에서 인증 암호화를 끝내고, 암호문만 올립니다.

ZipCrypto가 진지한 상대를 막지 못하는 이유

ZIP의 전통 암호는 Zip 2.0 또는 ZipCrypto로 불립니다. WinZip 자신의 설명은 솔직합니다. 이 형식은 상대적으로 약하고, 전용 복원 도구를 가진 사람을 막는 전제로 쓸 수 없습니다. 중요한 요구가 있으면 AES로 바꾸라고 적혀 있습니다. WinZip 암호화 설명에 있으며, 게시판 소문이 아닙니다.

약한 것은 알고리즘이지, 비밀번호 길이가 아닙니다. 1994년 Eli Biham과 Paul Kocher는 PKZIP 스트림 암호에 대한 알려진 평문 공격을 보였습니다. 십여 바이트 정도의 평문과 대응하는 암호문이 맞으면, 암호기의 내부 상태 셋을 역산해 파일 전체의 키 스트림을 복원할 수 있습니다. 이 단계에서 비밀번호 길이는 등장하지 않습니다. 상대가 복제하는 것은 자물쇠 심이지, 열쇠를 하나씩 넣어 보는 일이 아닙니다. 공개 구현(예를 들어 bkcrack)은 이 논문을 실행 가능한 프로그램으로 만들어 두었습니다. 「저장(Store)이며 ZipCrypto」인 압축파일에서 특히 직접적입니다.

알려진 평문은 어디서 오나. PDF는 %PDF로 시작합니다. Office 문서, 많은 이미지, 안에 들어 있는 ZIP에도 고정 매직 넘버가 있습니다. 형식이 공개된 계약서를 ZipCrypto에 넣고 그대로 올리면, 암호문과 거의 확정된 원문 표본을 동시에 넘기는 셈입니다. 공격 재현 절차를 적을 필요는 없습니다. 탐색기에서 「압축(zip) 폴더로 보내기」에 비밀번호만 더한 것을 AES-256-GCM과 같은 일로 보는 습관을 끊으면 됩니다.

Windows 기본 압축, 클라우드 화면의 「암호화 압축」, 오래된 배치, 알집·반디집의 호환 기본값은 ZipCrypto를 고르기 쉽습니다. 거의 모든 압축 해제 프로그램이 읽기 때문입니다. 만든 뒤 속성을 보세요. ZipCrypto / Zip 2.0이라고 적혀 있으면 백업 방안으로 쓰지 마세요. AES라고 적혀 있으면 다음 절입니다. 내용 계층은 강해집니다. 디렉터리 계층은 대개 아직 평문입니다.

AES ZIP이어도 디렉터리 정보는 평문으로 남습니다

WinZip은 9.0부터 AES-128 / AES-256(AE-1 / AE-2)을 제공합니다. 키는 비밀번호에서 PBKDF2로 유도하고, 솔트는 8 또는 16바이트, 반복 횟수는 1000입니다. ZipCrypto보다 한 자릿수 강하지만, 「브라우저의 AES-256-GCM」과 같은 포장은 아닙니다. WinZip AES는 내용을 암호화한 뒤 인증합니다(AES-CTR + HMAC). NIST의 GCM이 아닙니다. 1000회 반복은 지금 흔히 보는 십만 회급 비밀번호 유도보다 분명히 적습니다.

놓치기 쉬운 것은 디렉터리입니다. WinZip은 분명히 적습니다. 암호화가 걸리는 것은 압축파일 내부 파일의 내용입니다. 파일 이름, 날짜, 크기, 속성, 압축률은 암호화되지 않은 디렉터리에 있어, ZIP을 받은 사람은 비밀번호 없이 목록을 볼 수 있습니다. 공식은 「암호화 ZIP을 열어도 파일 이름이 보인다」는 설명을 따로 두었고, 이름을 한 겹 가리려면 「암호화하지 않은 ZIP을 만든 뒤 그 ZIP을 두 번째 암호화 ZIP에 넣으라」고 권합니다. 근거는 WinZip의 파일 이름 가시성 설명입니다.

7-Zip의 .7z에는 「파일 이름도 암호화」가 있습니다. 그것은 다른 제품의 선택이며, ZIP 기본 동작과 섞지 마세요. 탐색기에서 「비밀번호가 필요합니다」가 나와도, 말할 수 있는 것은 압축 해제에 비밀번호가 필요하다는 점뿐입니다. 반디집이나 다른 프로그램으로 같은 파일을 열면 목록이 바로 나옵니다. 주민등록증_뒷면.jpg, 급여대장-2026.xlsx, 고객명단.csv. 클라우드의 동일 파일 판정, 미리보기, 정책 스캔이 읽는 것은 이 층입니다. AES ZIP은 Windows 기본으로는 열리지 않는 경우가 많아, 호환을 위해 ZipCrypto로 되돌리는 운영도 남아 있습니다. 열리지 않는 것과 디렉터리가 숨겨진 것은 같은 말이 아닙니다.

클라우드의 「암호화됨」은 대개 사업자가 키를 가집니다

ZIP이든 원문이든 그대로 드라이브에 두면, 화면에는 전송 암호화, 저장 시 암호화, AES-256이 나옵니다. 이 문장들은 동시에 참일 수 있습니다. 답하지 않는 것은 「복호화 키를 누가 가지는가」입니다. Google의 Drive 설명은 이렇게 나뉩니다. 올린 파일, Docs / Sheets / Slides에서 만든 파일은 기본으로 전송 중과 저장 시 AES-256으로 암호화됩니다. 「Google이 열지 못하는」 상태로 만들려면 Workspace 관리자가 클라이언트 측 암호화를 켜고, 사용자가 직장 또는 학교 계정으로 본인 확인을 마쳐야 합니다. 개인이 「내 드라이브」로 끌어다 놓은 일반 파일은 기본 경로이며, 클라이언트 측 암호화가 아닙니다. 근거는 Drive 파일 암호화 설명입니다.

Google Cloud의 기본 저장 시 암호화는 더 직접적입니다. 키는 Google이 소유하고 관리합니다. 디스크 위 데이터 암호화 키(DEK)는 키 암호화 키(KEK)로 한 겹 더 감싸고, 복호화는 사업자의 키 서비스에서 일어납니다. 근거는 Google Cloud 기본 저장 시 암호화입니다. Workspace 백서 역시 「Google이 관리하는 키」와 「클라이언트 측 암호화 후 Google은 읽지 못함」을 나눕니다. 네이버 마이박스, 카카오, 사내 NAS의 규정 스캔, 동일 해시 판정, 문서 미리보기도 「서버가 파일 바이트를 읽을 수 있다, 적어도 평문 해시는 읽을 수 있다」는 전제 위에 있습니다. 손에서 ZIP에 비밀번호를 걸었다고 영지식으로 바뀌지 않습니다.

따라서 클라우드 자물쇠 아이콘이 지키는 것은 「디스크가 옮겨졌을 때」와 「경로의 구경꾼」입니다. 「이 회사에 넘긴 뒤에도 상대가 못 본다」가 아닙니다. 뒤의 문장을 관찰할 수 있는 사실로 만들려면, 올리기 전에 읽을 수 있는 원문을 잃어야 합니다.

기기 AES-256-GCM이 실제로 지키는 층

AES-GCM은 인증 암호화입니다. 같은 연산으로 기밀과 무결성을 함께 다룹니다. 암호문이 바뀌었거나, 잘렸거나, 비밀번호가 다르면 복호화는 실패해야 합니다. 「난수처럼 보이는 잘못된 평문」을 내놓아서는 안 됩니다. NIST SP 800-38D는 상호운용을 쉽게 하려고 IV를 96비트(12바이트)로 제한하는 구현을 권합니다. 태그 길이는 128비트(16바이트)가 흔합니다. 같은 키에서 IV를 재사용하면 안 됩니다. 기밀과 인증이 함께 무너집니다.

브라우저에서 올바른 경로는 crypto.subtle.encrypt이고, 알고리즘 이름은 AES-GCM입니다. MDN은 SubtleCrypto.encrypt가 보안 컨텍스트에서만 쓸 수 있다고 적습니다. 운영 환경은 HTTPS입니다. 비밀번호를 256비트 키로 바로 쓰면 안 됩니다. PBKDF2 같은 함수로 솔트를 더하고 여러 번 반복한 뒤 유도합니다. RFC 2898이 PBKDF2를 정의합니다. 반복 횟수는 「비밀번호 하나를 시험하는 계산 시간」을 정합니다. 1000회와 100000회는 같은 자릿수가 아닙니다.

파일 장면은 보이는 동작으로 줄일 수 있습니다. 파일 선택기로 이 기기의 파일을 고르고, 스크립트가 덩어리마다 메모리에 읽어, 각 덩어리를 새 난수 IV로 AES-256-GCM한 뒤, 브라우저가 암호문을 내려받게 합니다. 받는 파일은 이 기기가 조립한 것이며 서버 영수증이 아닙니다. 단일 파일 상한을 5 GB로 적는다면, 그것은 브라우저 안 스트림 처리 능력입니다. 원격이 5 GB 원문을 받았다는 뜻이 아닙니다.

FastPwd의 파일 암호화는 이 경계로 구현합니다. AES-256-GCM, Web Crypto. 비밀번호는 PBKDF2-HMAC-SHA256, 100000회, 16바이트 솔트로 256비트 키를 유도합니다. 기본은 1 MB마다, 각 덩어리는 12바이트 IV + 암호문 + 16바이트 태그. 단일 파일은 5 GB까지. 출력은 .lock / .enc, 매직은 CSLK. 모든 도구는 열어 바로 사용하며 계정과 비밀번호 보관함이 없습니다. 비밀번호를 잊으면 복구할 수 없습니다. 한 번도 올리지 않았기 때문입니다. 약속은 아직 약속입니다. 다음에서 점검 항목으로 바꿉니다. 파일 머리에 암호화되지 않은 부분도 포함합니다.

암호화 후 증명할 수 있는 것과, 파일 머리에 남는 것

기기 암호화가 받쳐 주는 결론도 좁습니다. 먼저 적으면 오판을 한 번 줄입니다. 받쳐 주는 것은, 이번 작업에서 파일 내용이 덩어리마다 인증 태그가 붙은 암호문이 된 것, 비밀번호가 없으면 복호화가 실패해야 하는 것, Network에서 카나리아가 없으면 관찰한 HTTP 업무 데이터로 원문과 비밀번호가 나가지 않은 것입니다.

받쳐 주지 않는 것은, 클라우드가 어떤 메타데이터도 못 본다는 것, 확장 프로그램이 클립보드를 읽지 않았다는 것, 비밀번호가 충분히 강하다는 것, 상대가 암호문을 받은 뒤 오프라인으로 비밀번호를 시험하지 않는다는 것입니다. FastPwd Lock v1의 파일 머리에는 원래 파일 이름과 MIME이 평문으로 들어갑니다. 복호화 후 이름을 되돌리기 위해서입니다. 주민등록증_뒷면.lock을 올리거나, 머리에 아직 주민등록증_뒷면.jpg가 있으면, 클라우드와 16진 뷰어를 연 사람 모두 그 몇 글자를 읽습니다. 암호화하는 것은 내용 덩어리이지, 용기가 밖으로 내거는 표가 아닙니다.

그 자리에서 대조하기: Network, 파일 머리, 오프라인

슬로건은 증거가 되지 않습니다. 버려도 되는 작은 파일을 준비하세요. 본문은 canary-fp-20260904-zip-vs-gcm, 파일 이름은 canary-fp-20260904.txt로 합니다. 비밀번호는 일회용 긴 문장으로 하고, 실제 비밀번호를 재사용하지 마세요.

1. 대조군을 먼저 만듭니다. 같은 파일을 비밀번호 달린 ZIP으로 만들고, 압축 프로그램에서 비밀번호를 넣지 않고 엽니다. 파일 이름이 보이는지, 속성이 ZipCrypto인지 AES인지를 적습니다. 이것이 압축파일 비밀번호의 실제 범위입니다.
2. 다음으로 브라우저에서 기기 암호화를 합니다. 개발자 도구의 Network를 열고 Preserve log를 켠 뒤, 필터는 All로 둡니다. 암호화가 끝나면 카나리아를 검색창에 붙입니다. 요청 줄, 본문, 접속 분석에 원문이나 비밀번호가 나오면 안 됩니다.
3. 16진 뷰어로 내려받은 .lock을 엽니다. 앞 4바이트는 CSLK(43 53 4C 4B)여야 합니다. 그 뒤에 솔트, 덩어리 크기, 남겨 둔 원래 파일 이름이 읽힙니다. 내용 영역에 카나리아 그 문장이 다시 나오면 안 됩니다.
4. 페이지 로드가 끝난 뒤 Network에서 Offline을 켜거나 시스템 네트워크를 끊고, 다른 버려도 되는 작은 파일을 암호화합니다. .lock을 여전히 내려받을 수 있으면, 이번 암호화/복호화는 실시간 API에 의존하지 않습니다. 오프라인을 통과한 뒤, 온라인에서도 같은 카나리아로 한 번 더 검색하세요.

비밀번호와 암호문을 같은 경로로 보내지 마세요. 클라우드에 올리는 것은 .lock, 비밀번호는 열람 후 파기로 나눕니다. 이 기기에서 AES-256-GCM으로 암호화하고, 서버는 암호문만 잠시 두며, 키는 링크의 # 뒤에 붙고, 형태는 s.html?id={id}#{key}입니다. 완전한 열람 후 파기 링크와 암호문을 같은 클라우드 폴더에 두면, 열쇠를 상자에 붙인 것과 같습니다.

암호화처럼 보이지만 실제로 막지 못한 세 경우

첫째는 웹판 「암호화 압축」입니다. 업로드가 끝난 뒤 사업자가 압축을 만들거나, 서버에서 「추출 코드」를 거는 경우가 있습니다. 추출 코드가 막는 것은 공유 링크를 누르지 않는 사람입니다. 서버가 이미 원문을 가진 것은 막지 못합니다. 대조 방법은 암호화가 「파일을 고르기 전」에 일어났는지, 「진행 막대가 끝난 뒤」에 일어났는지입니다. 후자는 기기 AES-GCM이 아닙니다.

둘째는 Office나 PDF 자체의 열기 비밀번호입니다. 지키는 것은 해당 뷰어의 열기 흐름입니다. 파일 형식 안에는 구조화된 칸이 많이 남습니다. 클라우드 미리보기, 전문 검색, 변환 서비스는 「열 때 비밀번호를 띄우는」 층을 우회하는 경우가 있습니다. 파일 전체의 인증 암호화와 같은 일로 보지 마세요.

셋째는 확장자만 바꾸는 일입니다. .xlsx를 .bin으로 바꿔 올려도, 동일 판정과 일부 스캔은 내용 해시로 움직이고, 파일 머리의 매직 넘버는 남습니다. 확장자는 암호학이 아닙니다. 기기 암호화 뒤 내용 영역의 매직은 사라져야 합니다. 16진 덤프에 아직 PK, %PDF, 또는 xlsx의 평문 특징이 보이면 이번은 통과가 아닙니다.

자주 묻는 질문

ZIP에 AES-256 비밀번호를 걸면, 클라우드에 올려도 안전한가요?

내용 계층은 ZipCrypto보다 강합니다. 다만 ZIP 디렉터리의 파일 이름, 날짜, 크기는 기본값으로 평문입니다. 클라우드와 ZIP을 받은 사람 모두 목록을 볼 수 있습니다. 브라우저의 AES-256-GCM도 아닙니다. WinZip AES는 다른 포장이고, PBKDF2 반복은 1000회입니다. 클라우드에 암호문만 남기려면 이 기기에서 내용 전체를 먼저 암호화한 뒤 올리세요.

클라우드에 「전송 암호화 / 저장 시 암호화」가 있으면 충분한가요?

대부분 사업자가 키를 가진 기본 암호화입니다. TLS는 전송 경로를 지키고, 저장 시 암호화는 디스크가 반출된 상황을 지킵니다. 사업자, 키를 가진 운영, 법령에 따른 제출에서는 원문을 열 여지가 남습니다. Google 드라이브에서 「Google이 열지 못한다」를 사실로 쓰려면 Workspace 관리자가 클라이언트 측 암호화를 켜야 합니다. 개인이 파일을 끌어다 놓는 기본 경로가 아닙니다.

FastPwd의 .lock을 올린 뒤, 클라우드는 원래 파일 이름을 보나요?

확장자는 보입니다. 파일 머리에서도 원래 파일 이름과 MIME을 읽을 수 있습니다. 암호화하는 것은 1 MB 단위의 내용이지, 용기 전체의 메타데이터가 아닙니다. 올리기 전에 원본을 의미 없는 이름으로 바꾼 뒤 암호화하세요. 비밀번호와 암호문을 같은 공유에 두지 마세요.

FastPwd에서 암호화할 때 파일과 비밀번호가 업로드되나요?

제품 설명상 암호화와 복호화는 지금 연 탭의 Web Crypto에서 끝나고, 파일과 비밀번호는 업무 데이터로 나가지 않으며 접속 분석에도 쓰지 않습니다. 접속 통계가 기록하는 것은 「암호화를 했다」 같은 이벤트 이름입니다. 카나리아로 Network를 검색해 요청 줄과 본문에 원문이나 비밀번호가 나오면 안 됩니다. localhost는 기본으로 접속 통계를 보내지 않습니다. 운영 도메인에서 한 번 더 재면 실제 사용에 가까워집니다.

같은 버려도 되는 파일을, 열어 바로 사용하는 도구로 한 번 대조하기

계산 경계를 적어 둔 페이지로 연습하고 싶다면 FastPwd의 파일 암호화를 열면 됩니다. 가입은 필요 없습니다. 위의 카나리아 작은 파일을 고르고, 비밀번호는 일회용 긴 문장으로 하세요. 약하다고 판단되면 페이지가 먼저 확인한 뒤 진행합니다. 암호화 후 .lock을 내려받으세요. 동시에 Network를 보세요. 정적 자원과, 있을 수 있는 접속 통계는 보여도 됩니다. 원본 파일이나 비밀번호가 업무 칸으로 보이면 안 됩니다.

비밀번호는 먼저 비밀번호 생성기에서 이 기기로 만들 수 있습니다. 무작위 모드는 6–128자, 기본값은 16자. 8자 미만이면 보안이 낮다고 알려 줍니다. 생성도 올리지 않습니다. 동료에게 비밀번호를 넘겨야 하면 열람 후 파기로 나누고, 클라우드 메모란에 쓰지 마세요. 짧은 기밀이나 일회용 키를 .lock의 전송 통로로 쓰지 마세요. 파일 암호화가 푸는 것은 파일 전체의 백업과 인수인계입니다. 채팅 한 줄의 비밀이 아닙니다.

다음에 올리기 전 셋을 기억하세요. 첫째, 압축파일 비밀번호가 막는 것은 압축 해제이지 디렉터리가 아니며, ZipCrypto의 알려진 평문 공격도 아닙니다. 둘째, 클라우드 기본 암호의 키는 대개 사업자 손에 있습니다. 셋째, 기기 AES-256-GCM이 지키는 것은 내용 덩어리입니다. 파일 머리와 확장자는 아직 샐 수 있으니 Network와 16진 덤프로 직접 한 번 보세요. 반복할 수 있는 관찰만 팀의 백업 안내에 적을 가치가 있습니다.

더 읽을거리

「로컬 암호화, 올리지 않음」은 증거가 되지 않습니다. 카나리아로 Network를 검색하는 방법은 브라우저 로컬 암호화에서 원문이 이 기기를 떠나지 않았는지 확인하는 방법에 있습니다. 비밀번호만 받는 쪽에 넘길 때 해시 뒤가 기본으로 HTTP에 들어가지 않는 이유는 URL 해시 뒤에 키를 두는 이유, 그리고 그 보호가 깨질 때에 있습니다. 티켓 본문의 번호를 이 기기를 떠나기 전에 가리려면 티켓과 로그를 AI에 붙이기 전에, 어떤 항목이 이 기기를 떠나는지 먼저 확인하는 방법을 보세요.