파일을 클라우드에 넣기 전에, 평문은 누가 읽을 수 있고 암호는 어느 길로 보내야 하는가

인증서 묶음, 내보낸 직원 명단, 비밀키가 들어 있는 설정. 마지막은 개인 구글 드라이브, 네이버 마이박스, 회사 공유 폴더로 가는 일이 많습니다. 올리기 화면에는 「전송 암호화」「보관 암호화」「금고」가 적혀 있습니다. 이 말들이 가리키는 것은 사업자 자신의 회선과 디스크입니다. 「당신 말고는 아무도 열지 못한다」가 아닙니다. 다른 글에서 Network로 평문이 올라가지 않았는지 확인하는 순서를 적었습니다. 문구는 증거가 되지 않습니다. 이 글은 장면을 하나로 좁힙니다. 파일이 이 컴퓨터를 떠나 남의 저장소에 들어갈 때, 평문을 누가 읽을 수 있는지, 암호는 어느 길로 보낼지를 먼저 가릅니다.

「온라인 파일 암호화」기능 목록이 아닙니다. 어떤 클라우드를 고를지의 비교도 아닙니다. 질문은 세 가지뿐입니다. 나가기 전에 평문이 암호문으로 바뀌었는가. 올린 뒤 사업자나 다음에 받는 사람이 그대로 열 수 있는가. 암호를 .lock / .enc와 같은 메일·같은 카카오톡에 묶지 않았는가. MyPassGen의 파일 암호화는 이 경계에서 동작합니다. 브라우저에서 AES-256-GCM으로 계산한 뒤 결과를 받습니다. 파일과 암호는 업무 데이터로 올리지 않습니다. 가입은 필요 없습니다. 아래 대조표와, 그 자리에서 반복할 수 있는 단계로 경계를 봅니다.

「암호화됨」이 가리키는 층은 대개 다르다

HTTPS가 막는 것은 경로 위의 엿듣는 사람입니다. 파일이 드라이브 서버에 도착한 뒤, 사업자는 평문 그대로, 또는 스스로 풀 수 있는 암호문으로 디스크에 둡니다. 많은 제품이 이 사업자 보관 키의 보관 암호화를 「파일이 암호화되어 있습니다」라고 씁니다. 운영자에게는 디스크가 반출됐을 때의 대비가 됩니다. 「저장소 쪽에 주민등록증 스캔을 보여주고 싶지 않다」에는 부족합니다.

클라이언트가 먼저 암호화한 뒤 올리는 것은 다른 층입니다. 브라우저나 이 기기의 프로그램이, 당신이 가진 암호에서 키를 만들고, 클라우드에 남는 것은 암호문뿐입니다. rclone Crypt, 일부 동기화 도구, 탭 안의 Web Crypto가 이 층에 속합니다. 이들이 답하는 것은 「보관 쪽이 쓸 수 있는 평문을 갖지 않는다」입니다. 암호가 약한 것, 암호와 파일을 같은 길로 보내는 것, 파일 이름이 이미 내용을 말하는 것은 따로 남습니다.

개인정보 보호법 제24조는 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호를 고유식별정보로 두고, 처리를 원칙적으로 제한합니다. 암호화하지 않은 신분증 스캔을 개인 드라이브에 올린 뒤 단톡으로 돌리면, 식별할 수 있는 상태가 그대로 제3자의 저장소로 나갑니다. 먼저 암호화해도 가명처리나 익명처리가 되지 않습니다. 「이 파일을 기기에서 내보내도 되는가」는 별개의 판단입니다.

평문을 손에 넣는 사람은 누구인가

같은 certs.zip을 클라우드에 둘 때, 이미 세 갈래로 나뉩니다. 차이는 화면 문구가 아닙니다. 키가 누구 손에 있는지, 평문이 브라우저를 먼저 떠났는지입니다.

「보관 쪽에 본문을 보여주고 싶지 않다」에 답하는 것은 세 번째뿐입니다. 암호화가 업로드보다 먼저 끝나야 하고, 키를 그 저장 서버에 넘기지 않아야 합니다. 앞글에서도 적었습니다. Web Crypto API가 보장하는 것은 계산이 이 기기에서 돌 수 있다는 점입니다. 페이지가 먼저 올리고 나중에 암호화하는 것은 막지 않습니다. 그래서 「이 기기에서 먼저 암호화했다」는 트래픽으로 확인하고, 홍보 문장으로 확인하지 않습니다.

이 단계에서 AES-256-GCM이 하는 일

MyPassGen 초판은 AES-256-GCM만 씁니다. NIST SP 800-38D는 GCM을 인증 암호화로 둡니다. 암호문이 바뀌면 복호화는 실패해야 합니다. 깨진 본문을 「아마 이것이다」로 읽는 여지를 주지 않습니다. RFC 5116의 AEAD_AES_256_GCM은 키 32바이트, nonce 12바이트, 인증 태그 16바이트입니다. MDN의 AesGcmParams도 IV를 96비트로 두고, 같은 키에서는 암호화할 때마다 새 IV가 필요하다고 합니다. IV 자체는 비밀이 아닙니다. 암호문과 같이 두어도 됩니다.

암호를 AES 키로 그대로 쓰지 않습니다. 이 사이트의 파일 암호화는 PBKDF2, 반복 100,000회, SHA-256, 소금 16바이트로 256비트 키를 만듭니다. 소금은 파일 헤더에 써서, 복호화할 때 같은 계산을 다시 합니다. RFC 8018은 NIST SP 800-132를 인용해, 반복 횟수는 기다릴 수 있는 범위에서 크게 잡으라고 합니다. OWASP가 「서버에 남기는 비밀번호 해시」에 권하는 PBKDF2-HMAC-SHA256은 현재 최소 600,000회입니다. 하는 일이 다릅니다. 파일 암호의 첫 방어선은 여전히 충분히 긴 난수 암호입니다. 반복이 막는 것은 오프라인 추측입니다. 드라이브 메모에 적은 123456은 막지 못합니다.

암호는 암호문과 다른 길로

가장 흔한 실패는 알고리즘을 잘못 고른 것이 아닙니다. backup.lock과 「암호는 여름에 사번」을 같은 카카오톡, 같은 메일, 같은 드라이브 폴더의 readme.txt에 두는 일입니다. 저장소 쪽이나 그 방에 있는 사람이 두 조각을 동시에 갖습니다. 이 기기에서 암호화한 의미가 사라집니다.

나누는 방법은 단순합니다. 암호문은 드라이브나 메일 첨부. 암호는 다른 길—직접 말하기, 전화, 또는 일회용 링크(키는 URL # 뒤. 읽기 페이지에 가입은 필요 없습니다). 파일 이름, 압축 주석, 「나만 볼 수 있다」고 적었지만 같은 클라우드 계정에 있는 메모에는 쓰지 않습니다.

암호 자체는 비밀번호 생성으로 이 기기에서 만듭니다. 랜덤 모드는 6–128자, 기본 16. 8자 미만은 약하다고 보면 됩니다. 잊은 암호는 되돌릴 수 없습니다. 서버 쪽 평문 백업도, 「보안 질문」도 없습니다. 저장소가 본문을 보지 않는 대가이며, 빠진 기능이 아닙니다.

.lock을 열어도 보이는 것

암호문은 「파일 전체가 알아볼 수 없는 잡음이 된다」가 아닙니다. 공개해도 되는 컨테이너 헤더에는 메타데이터가 남는 일이 많습니다. MyPassGen 기본 출력은 .lock이고 .enc도 고를 수 있습니다. 형식은 같고 확장자만 다릅니다. 다른 도구 습관에 맞추기 위해서입니다. 헤더는 네 바이트 CSLK로 시작하고, 이어서 버전, 16바이트 소금, 덩어리 크기, 그리고 원래 파일 이름과 MIME 유형의 평문이 옵니다. 본문은 약 1 MB씩 AES-GCM합니다. 덩어리마다 12바이트 IV와 16바이트 태그를 갖습니다.

그래서 주민등록증_스캔.pdf를 주민등록증_스캔.pdf.lock으로 만들어 올리면, 드라이브 목록과 파일 헤더가 둘 다 「이것은 신분증 스캔이다」라고 말합니다. 암호화가 지키는 것은 본문 바이트이지 이름이 아닙니다. 이름이 민감하면, 의미 없는 이름으로 바꾼 뒤 암호화합니다. 올린 .lock에도 읽히는 제목을 붙이지 않습니다.

파일 하나 한도는 5 GB입니다. 암호화할 때는 Blob.slice로 약 1 MB를 잘라 crypto.subtle.encrypt에 넘깁니다. Web Crypto의 encrypt()는 한 번에 BufferSource 하나만 받습니다. 큰 파일을 한 번에 넣으면 탭 메모리가 먼저 찹니다. 자르기는 「평문 전체를 한 번에 API에 주지 않기」위한 처리입니다. 결과는 이 기기에서 이어 붙여 받습니다. 복호화의 현재 구현은 .lock 전체를 먼저 읽습니다. 큰 파일일수록 메모리를 더 씁니다. 작업 관리자에서 볼 수 있는 사실이며, 구호가 아닙니다.

그 자리에서 확인하기

아래 단계는 어떤 브랜드의 약속에도 기대지 않습니다. 버려도 되는 작은 텍스트로 합니다. 실제 신분증으로 연습하지 마세요.

1. 수십 바이트짜리 probe.txt를 만들고, 당신만 아는 시험 문장, 예를 들어 orange-lake-7을 씁니다. 실제 암호나 주민등록번호는 쓰지 않습니다.
2. 개발자 도구 Network를 열고 「로그 보존」을 켭니다. 파일 암호화 페이지에서 그 파일을 고르고, 암호를 넣은 뒤 암호화를 시작합니다.
3. Fetch / XHR을 한 줄씩 봅니다. 요청 줄과 요청 본문에 orange-lake-7도, 방금 넣은 암호도 나오면 안 됩니다. 분석 전송도 원문을 가져가면 안 됩니다. 나와도 되는 것은 스크립트, 스타일, 파일 본문과 무관한 통계입니다.
4. 받은 .lock 또는 .enc를 16진 뷰어로 봅니다. 헤더 앞 네 바이트는 43 53 4C 4B(ASCII CSLK)여야 합니다. 더 가면 원래 이름 probe.txt의 평문은 보입니다. 시험 문장 자체는 보이지 않습니다.
5. 그 암호문을 같은 페이지에 다시 놓습니다. 맞는 암호면 시험 문장이 돌아옵니다. 암호를 한 글자만 바꾸면 복호화는 실패해야 합니다. 깨진 본문이 나오면 안 됩니다.
6. 그다음에야 .lock을 드라이브에 올립니다. 암호는 다른 메시지로 보냅니다. 클라우드 미리 보기로 돌아갑니다. 암호를 넣지 않으면 원문이 열리지 않아야 합니다.

MyPassGen의 파일 암호화는 이 경계에서 동작합니다. AES-256-GCM, PBKDF2 100,000회, 파일 하나 5 GB까지, 출력은 .lock / .enc. 계산은 지금 탭에서 끝납니다. 계정을 만들지 않습니다. 믿을 대상은 여전히 Network와 파일 헤더이지, 화면의 「올리지 않습니다」다섯 글자가 아닙니다.

짧은 비밀은 파일로 만들지 않는다

API 키 한 줄, 복구 코드, 데이터베이스 비밀번호를 먼저 파일로 만들어 암호화할 필요는 없습니다. 파일 전체 흐름은 인증서 묶음, 내보낸 표, 디스크 이미지 조각에 맞습니다. 짧은 글은 일회용 링크가 맞습니다. 평문 한도는 32 KB. 서버가 잠시 두는 것은 암호문뿐입니다. 키는 # 뒤에 둡니다. 열람 횟수와 TTL을 정할 수 있습니다. 만들기와 읽기 모두 로그인하지 않습니다.

설명 문서를 밖으로 낼 때는 링크와 본문이 다른 공정입니다. utm_source가 붙은 주소는 지워도 되는 파라미터로 처리합니다. 티켓의 휴대폰, 주민등록번호는 반드시 가려야 할 항목으로 처리합니다. 암호화 파일이 답하는 것은 「저장소 쪽이 본문을 열지 못한다」입니다. 「이야기할 때 번호를 통째로 넣지 않는다」가 아닙니다.

흔한 오해

「클라우드가 암호화라고 썼으니 나만 본다.」사업자가 키를 갖거나 맡는 구조에서는 운영, 법령에 따른 제출, 계정 탈취 뒤에도 쓸 수 있는 파일이 남습니다. 이 기기에서 먼저 암호화해야 「풀 수 있는 사람」이 암호를 가진 사람으로 줄어듭니다.

「HTTPS가 처음부터 끝까지 지킨다.」HTTPS는 사업자 입구에서 끝납니다. 디스크에 떨어진 뒤의 보호 범위는 상대가 정합니다. 줄이려는 것은 떨어진 그 사본 안의 평문입니다.

「확장자를 .lock으로 바꾸면 암호화다.」인증 암호화를 거치지 않은 이름 바꾸기는 메모장에서 원문을 검색합니다. 헤더에는 약속한 매직이 있어야 하고, 본문은 열리지 않아야 합니다. 접미어만 바꾸는 것은 하지 않은 것과 같습니다.

「암호를 잊으면 고객센터가 되돌려 준다.」제로 지식 보관에는 서버 쪽 암호 사본이 없습니다. 바닥글에도 「암호화 암호를 재설정하는」메일함은 두지 않습니다. 암호는 당신의 비밀번호 관리자, 또는 당신이 통제하는 다른 길에만 둡니다.

어디서부터 하면 되나

오늘 올려야 하는 그 파일부터 합니다. 버려도 되는 작은 파일로 앞 절의 여섯 단계를 통과합니다. Network에 원문이 없고, 헤더가 CSLK이며, 틀린 암호로는 풀리지 않는지 확인한 뒤에 실제 파일을 암호화합니다. 이름이 민감하면 먼저 바꿉니다.

암호문은 드라이브에 올리거나 메일에 붙입니다. 암호는 직접 말하거나, 전화하거나, 일회용 링크를 하나 만듭니다. 같은 폴더의 텍스트에 암호를 적지 않습니다. 여기까지 하면 제목의 질문에 답할 수 있습니다. 저장소 쪽은 평문을 가지면 안 됩니다. 암호는 암호문과 같은 길을 가면 안 됩니다. 헤더에는 원래 이름이 남을 수 있고, 그 이름은 따로 다룹니다.

자주 묻는 질문

클라우드 「금고」와 이 기기에서 먼저 암호화하는 차이는 무엇인가?

금고는 사업자가 키를 갖거나 맡는 경우가 많습니다. 같은 계정으로 로그인하면 엽니다. 이 기기에서 먼저 암호화하면 저장소 쪽은 암호 없이 본문을 풀지 못합니다. 계정이 탈취돼도, 암호가 없는 사람은 암호문만 받을 수 있습니다.

암호를 잊으면 복호화할 수 있는가?

없습니다. 서버 쪽 평문이나 암호 백업이 없습니다. 충분히 긴 난수 암호를 쓰고, 당신의 비밀번호 관리자에 따로 둡니다. 「저장소 쪽이 본문을 보지 못한다」의 대칭 대가입니다.

.lock과 .enc는 무엇이 다른가?

이 사이트에서는 같은 컨테이너이고 확장자만 다릅니다. 복호화할 때 두 접미어 모두 페이지에 놓으면 됩니다. 다른 프로그램의 .enc가 같은 헤더로 읽힌다고 가정하지 마세요.

암호화에 가입이 필요한가? 파일이 올라가는가?

가입은 필요 없습니다. 대신 계산해 주는 사이트에 원본을 넘길 때 로그 위험이 생깁니다. 로컬로 처리할 때 파일과 암호는 지금 탭에 남습니다. 확인할 것은 Network에 파일 본문이나 암호가 나갔는지, .lock에서 시험 문장 원문을 검색할 수 있는지입니다.