먼저 결론입니다. 로컬 암호화에서 바로 확인할 수 있는 부분은 「이번 HTTP가 평문, 비밀번호, 프래그먼트 키를 업무 데이터로 보냈는가」입니다. 확장 프로그램이 클립보드를 읽지 않았다는 증명도, 다음 버전 동작이 같다는 증명도 아닙니다. 아래는 반복할 수 있는 절차이지, 새로운 형용사가 아닙니다.
검색 의도를 한 문장으로 먼저 답하기
브라우저 로컬 암호화란, 암호화와 복호화가 지금 보고 있는 탭에서 일어난다는 뜻입니다. 스크립트는 브라우저가 제공하는 Web Crypto API를 호출하고, AES-GCM 계열 알고리즘을 이 기기에서 끝냅니다. 평문과 키는 기본적으로 HTTP 본문으로 브라우저를 떠나지 않습니다. 확인 방법은 홍보 문장을 읽는 것이 아니라, 개발자 도구의 Network를 열고 카나리아로 검색한 뒤, 필요하면 오프라인으로 다시 재는 것입니다.
이 글은 개발자, 운영, 그리고 파일이나 비밀번호를 「온라인 도구」에 맡기기 전에 직접 한 번 보고 싶은 사람을 위한 것입니다. 파일 암호화 박스 사용 설명을 대신하지 않으며, 홈의 제품 정의도 반복하지 않습니다. 가져가야 할 것은 어떤 사이트에도 다시 쓸 수 있는 확인 절차입니다.
슬로건은 스스로를 증명하지 못합니다. 트래픽은 관찰할 수 있습니다
많은 페이지에 로컬 계산, 업로드 없음, 종단 간이라고 적혀 있습니다. 이 말은 정말로 이 기기에서 계산을 끝내는 도구에도, 「원문을 먼저 POST하고 서버가 대신 암호화하는」 업로드 페이지에도 찍을 수 있습니다. 문장 자체에는 검사 비트가 없습니다.
바로 볼 수 있는 것은 지금 연 탭이 보낸 메서드, 주소, 쿼리 문자열, 요청 본문입니다. Chrome의 Network 패널이 이를 나열합니다. 방금 고른 파일 이름, 방금 입력한 비밀번호, 자신만 아는 실험 원문이 그 자리에 나오면, 이른바 로컬 암호화는 이번 작업에서 성립하지 않습니다.
반대로 패널에 평문이 없다는 것은, 관찰한 요청이 그 필드를 가져가지 않았다는 뜻일 뿐입니다. 메모리에 평문이 없었다는 증명도, 브라우저 확장이 입력란을 읽지 않았다는 증명도 아닙니다. 홍보를 한 번의 반복 가능한 관찰로 줄이는 가치는 이미 충분합니다. 동료에게 「카나리아를 검색했고, 요청 줄과 body는 깨끗했다」고 말하면 되고, 공식 문구를 전달할 필요는 없습니다.
실제 키, 신분증 번호, 마스킹하지 않은 표로 실험하지 마세요. 버려도 되는 작은 파일을 준비하고, 비밀번호는 일회용 긴 문장으로 하세요. 확인하는 것은 트래픽이지, 개인정보를 다시 드러내는 일이 아닙니다.
「로컬」이 가리키는 계산 계층
「브라우저 로컬」은 「이 도메인이 안전해 보인다」가 아니라, 「암호 연산이 지금 문서의 스크립트 환경에서 일어난다」는 뜻입니다. AES-256-GCM의 흔한 올바른 경로는 crypto.subtle.encrypt입니다. 키 유도, 암호화, 인증 태그는 모두 브라우저 자체 API를 거칩니다. MDN은 SubtleCrypto.encrypt가 보안 컨텍스트에서만 쓸 수 있다고 적습니다. 운영 환경은 HTTPS입니다. 일반 HTTP 페이지에서 crypto.subtle은 종종 undefined입니다.
AES-GCM을 고른 이유는 이름이 멋있어서가 아닙니다. 무결성 검사가 있는 인증 암호화입니다. 암호문이 바뀌거나 키를 잘못 쓰면 복호화가 실패하며, 「깨진 글자처럼 보이는 잘못된 평문」을 내놓지 않습니다. IV는 흔히 12바이트(96비트)로, NIST SP 800-38D의 GCM 권고와 같습니다. 암호화할 때마다 새 난수 IV를 써야 같은 평문도 다른 암호문이 됩니다.
파일 흐름은 더 구체적인 동작으로 쓸 수 있습니다. 파일 선택기로 이 기기의 파일을 고르고, 스크립트가 덩어리 단위로 메모리에 읽어 암호화한 뒤, 브라우저가 암호문을 내려받게 합니다. 받은 .lock 또는 .enc는 이 기기가 만든 결과 파일이며 서버 영수증이 아닙니다. 단일 파일 상한이 5 GB라면, 브라우저에서 스트리밍 처리할 수 있는 능력을 말한 것이지, 원격이 5 GB 원문을 받았다는 뜻이 아닙니다.
「업무 업로드」와 「페이지가 원래 보내는 요청」도 나누세요. 열어 바로 사용하는 도구 사이트도 스타일, 스크립트, 글꼴을 불러오고, 본문 없는 접속 분석을 보낼 수 있습니다. 이런 요청이 있다고 해서 「파일이 업로드됐다」고 단정하면 안 됩니다. 다만 분석의 query나 body에 방금 입력한 비밀번호, 검사한 비밀번호, 세척 전 원문이 나오면 이야기는 다릅니다.
FastPwd는 이 경계를 확인할 수 있는 문장으로 적습니다. 비밀번호 생성, 비밀번호 검사, 개인정보 세척, 파일 암호화/복호화의 평문과 키는 기본적으로 브라우저를 떠나지 않습니다. 열람 후 파기(Burn-Link)는 암호문만 나가게 하고, 복호화 키는 URL의 # 프래그먼트에 둡니다. 파일 암호화 박스는 1 MB씩 나누고, PBKDF2(100000회, SHA-256)로 비밀번호에서 AES-256 키를 유도해 .lock / .enc를 출력합니다. 모든 도구는 열어 바로 사용하며 계정과 비밀번호 보관함이 없습니다. 약속은 어디까지나 약속입니다. 아래에서는 Network로 점검 항목으로 바꿉니다.
Network로 카나리아 검사하기
먼저 실제 업무에 나오지 않을 표시를 준비하세요. 파일 이름은 canary-fp-20260825.bin, 비밀번호는 무작위 긴 문장, 본문에는 이번 실험에만 있는 한 줄을 쓰세요. 카나리아의 역할은 검색입니다. Network 필터에 붙여넣고, 적중하면 실패입니다.
개발자 도구를 열고 Network로 전환한 뒤 Preserve log를 켜세요. 필터는 먼저 All로 두고, 처음부터 XHR만 남기지 마세요. 취소되거나 4xx를 받은 요청도 이미 평문을 실었을 수 있습니다. 그런 다음 한 번의 작업을 끝까지 하세요. 파일을 고르고, 비밀번호를 넣고, 암호화 또는 생성을 누릅니다. 끝난 뒤에도 패널을 먼저 닫지 마세요.
- 필터에 카나리아 문자열을 붙여넣으세요. 빨간 적중이 나오면 그 요청을 읽고 멈추세요. 「로컬처럼 느껴진다」는 판단으로 돌아갈 필요는 없습니다.
- 적중이 없으면 Fetch / XHR을 하나씩 열고 요청 줄, 쿼리 문자열, 요청 본문을 대조하세요. 스타일, 글꼴, 스크립트는 무시해도 됩니다.
- 접속 분석 경로는 따로 걸러 query와 body를 여세요. 페이지 제목과 경로는 나와도 됩니다. 방금 입력한 비밀번호, 검사한 비밀번호, 세척 전 원문, 파일 내용은 나오면 안 됩니다.
요청 줄 보기
전체 URL의 path와 물음표 뒤 쿼리는 한 글자씩 볼 가치가 있습니다. id 같은 조회용 필드는 나와도 됩니다. 파일 이름, 비밀번호, 검사한 비밀번호, # 뒤의 키는 나오면 안 됩니다. 주소창 전체와 요청 줄을 비교하세요. # 이후가 요청 줄에 들어갔다면, 구현이 프래그먼트를 query로 잘못 썼거나, 스크립트가 읽어 요청에 넣은 것입니다.
요청 본문 보기
POST / PUT payload가 두 번째 자리입니다. 파일 암호화가 로컬에서 끝난다고 주장한다면, 본문에 원본 파일 바이너리나 비밀번호가 있으면 안 됩니다. 열람 후 파기에 암호문 필드가 있는 것은 예상대로 밖으로 나가는 데이터입니다. 방금 입력한 원문처럼 보이지 않는지만 확인하세요. 비밀번호 검사 페이지가 검사할 비밀번호를 POST한다면, 목적이 「유출 조회」든 「강도 계산」이든 이미 이 기기를 떠난 것입니다.
접속 분석은 따로 보기
접속 분석은 자주 빠집니다. 주 API는 깨끗한데 보고에 입력란 전문이 실려 있으면, 이번 작업은 아직 「평문이 브라우저에 남았다」고 할 수 없습니다. 분석 경로를 걸러 볼 때 「분석 스크립트는 무해하다」고 가정하지 마세요. 또 다른 외부 요청일 뿐이며, 점검 방식은 업무 API와 같습니다. FastPwd의 접속 분석은 사이트 자체 tracker를 쓰고 localhost에서는 기본적으로 보내지 않습니다. 그래도 카나리아로 보고에 비밀번호나 파일 내용이 없는지 확인하세요.
Preserve log를 켜 두세요. 암호화 후 페이지가 이동하거나 새로고침될 때 체크가 꺼져 있으면, 평문을 실은 첫 요청이 이미 지워져 「패널이 비어 있다」는 가짜 결과를 얻습니다.
오프라인 재검사: 정적 자원은 업무 업로드가 아닙니다
두 번째 대조는 비용이 낮습니다. 페이지를 끝까지 불러온 뒤 Network에서 Offline을 켜거나 시스템 네트워크를 끄고, 버려도 되는 작은 파일을 암호화하세요. .lock 다운로드가 끝나면, 이번 암호화/복호화는 실시간 API에 의존하지 않은 것입니다. 이는 「브라우저 로컬 암호화」의 강한 신호이지만 유일한 신호는 아닙니다.
가짜 실패도 흔합니다. Offline에서 글꼴이나 분석 스크립트가 빨개지는 것은 암호화 실패가 아닙니다. 볼 것은 암호화 버튼 뒤에 새 업무 POST가 있는지, 결과 파일이 이미 다운로드 폴더에 있는지입니다. 가짜 통과도 있습니다. 스크립트는 평문을 큐에 넣고 다시 연결된 뒤 보낼 수 있습니다. 그러므로 오프라인을 통과한 뒤에도, 온라인에서 카나리아 검색을 하세요.
물음표는 HTTP에 들어갑니다. #는 기본적으로 들어가지 않습니다
URL에는 자주 섞이는 두 구간이 있습니다. 물음표 뒤 쿼리는 HTTP 요청 줄에 들어가며, 서버, 리버스 프록시, 접속 로그가 모두 볼 수 있습니다. # 뒤 프래그먼트는 기본적으로 브라우저가 이 기기에 남겨, 지금 페이지의 스크립트가 읽습니다. HTTP 요청 대상에는 fragment가 포함되지 않습니다. 이는 RFC 9110의 요청 대상 약속이며, URL.hash가 브라우저 쪽에만 있는 이유이기도 합니다.
따라서 일회용 암호문 링크가 키를 #에 두면, 수신자가 s.html?id={id}#{key}를 열 때 서버는 설계상 id만 보고 키는 보지 못합니다. 추가 암호 프로토콜이 아니라 브라우저의 프래그먼트 기본 동작입니다. 경계도 있습니다. 전체 주소를 티켓, 그룹 채팅, hash를 버리는 미리보기 카드에 붙이면, 키는 「HTTP에 들어가지 않음」에서 「다른 사람의 화면과 로그에 나타남」으로 바뀝니다.
확인 방법도 구체적입니다. 열람 후 파기에서 해가 없는 테스트 글을 만들고, 생성 요청 body가 암호문만인지 보세요. 열람 페이지를 열 때 문서 요청과 이후 인터페이스 URL에 id만 있는지도 보세요. 주소창 # 뒤 내용은 이 요청들에 나오면 안 됩니다. 열람 페이지는 수신자에게 공개되며 로그인은 필요 없습니다.
| 어디를 볼까 | HTTP에 들어가는가 | 통과 기준 |
|---|---|---|
| 페이지 슬로건 | 해당 없음 | 증거가 되지 않음. 대조만 하세요 |
| 요청 줄 / query | 들어감 | 카나리아 없음, 비밀번호 없음, 프래그먼트 키 없음 |
| POST body | 들어감 | 원문 없음. 열람 후 파기는 암호문만 허용 |
URL # 프래그먼트 |
기본적으로 안 들어감 | 주소창에는 있고 요청 줄에는 없음 |
| 접속 분석 | 구현에 따름 | 입력란 원문 없음 |
| Offline 후 암호화 | 새 업무 요청 없음 | 암호문은 내려받을 수 있음. 다시 연결한 뒤 카나리아 검색 |
증명할 수 있는 것과 없는 것
이번 점검이 뒷받침하는 결론은 좁습니다. 그렇게 적어 두는 편이 더 쓸모 있습니다.
뒷받침할 수 있는 것: 지금 쓰는 이 브라우저, 이 버전, 이번 작업에서 평문, 비밀번호, 프래그먼트 키는 관찰된 HTTP 업무 데이터나 분석 원문으로 탭을 떠나지 않았습니다.
뒷받침할 수 없는 것: 다른 탭이나 확장이 클립보드를 읽지 않는다. 디스크의 다운로드 폴더가 안전하다. 상대가 암호문을 받은 뒤 화면을 찍지 않는다. 비밀번호 검사가 전 웹 유출 창고를 덮는다. 검사가 로컬 엔트로피와 공개 취약 비밀번호 Top 목록만 한다면, 답할 수 있는 것은 「흔한 취약한 비밀번호처럼 보이는가」이지 「어떤 유출에도 한 번도 나오지 않았다」가 아닙니다. 전 웹 HIBP 조회가 아닙니다.
침투 테스트로도 읽지 마세요. WebSocket, Service Worker 캐시도 보지 않았고, 난독화 스크립트도 역분석하지 않았습니다. 목표는 동료에게 이렇게 설명할 수 있게 하는 것입니다. Network를 열고 카나리아로 검색했고, 요청 줄과 body는 깨끗했다. 이는 「공식 사이트가 업로드하지 않는다고 한다」를 전달하는 것보다 엔지니어 토론에 가깝습니다.
자주 묻는 질문
오프라인에서도 암호화되면 업로드하지 않았다는 증명인가요?
이번 암호화/복호화가 실시간 API에 의존하지 않았다는 것만 증명합니다. 페이지에 이미 캐시된 스크립트는 다시 연결된 뒤 요청을 보낼 수 있습니다. 그러므로 오프라인을 통과한 뒤, 온라인에서 같은 카나리아로 Network를 다시 검색하세요. 두 단계를 모두 통과해야 결론이 서습니다.
Network 패널이 비어 있으면 이번 작업은 안전한가요?
그렇지 않습니다. 필터가 Img만 남았거나, Preserve log가 꺼져 있거나, 이동 중에 요청이 지워지면 가짜 빈 화면이 됩니다. 필터를 All로 바꾼 뒤 카나리아를 검색하고, 접속 분석은 따로 여세요. 빈 패널은 관찰 실패이지 보안 증명이 아닙니다.
열람 후 파기가 암호문을 서버에 두면, 그래도 브라우저 로컬 암호화인가요?
「평문은 이 기기에서 계산을 끝낸 뒤 나간다」로 보면 됩니다. 서버가 봐야 하는 것은 암호문과 조회용 id뿐입니다. 복호화 키는 링크의 # 뒤에 있으며 기본적으로 HTTP에 들어가지 않습니다. 생성과 열람 모두 계정이 필요 없습니다. 확인할 것은 body가 원문인지, 요청 줄에 # 뒤의 키가 있는지입니다.
비밀번호 검사는 검사할 비밀번호를 전 웹 유출 창고로 보내나요?
FastPwd의 비밀번호 검사는 이 기기에서 강도를 계산하고, 내장된 공개 취약 비밀번호 목록과 대조합니다. 검사할 비밀번호는 업로드하지 않습니다. 흔한 취약한 비밀번호는 잡을 수 있지만 「전 웹에서 본 적 없다」는 증명은 아니며, Have I Been Pwned식 조회도 아닙니다. 검사할 비밀번호를 카나리아로 삼아 Network를 검색하면 이 한 줄을 확인할 수 있습니다.
같은 절차를 열어 바로 사용하는 도구에 적용하기
계산 경계를 분명히 적은 페이지로 연습하고 싶다면 FastPwd의 파일 암호화 박스부터 시작하세요. 열어 바로 사용하며 가입 불필요합니다. 실제 개인정보가 없는 작은 파일을 고르고, 비밀번호는 카나리아로 한 뒤 암호화하여 .lock을 내려받으세요. 동시에 Network를 보세요. 정적 자원과, 있을 수 있는 접속 분석은 보여도 됩니다. 원본 파일이나 비밀번호가 업무 필드로 보이면 안 됩니다. 알고리즘은 AES-256-GCM이며 Web Crypto에서 계산하고, 단일 파일은 5 GB 이하입니다.
열람 후 파기는 두 번째 연습에 맞습니다. 해가 없는 테스트 글을 만들고, 나가는 것이 암호문인지 확인하세요. 열람 페이지는 수신자에게 공개되며 링크 형태는 s.html?id={id}#{key}입니다. 개인정보 세척은 「원문이 분석에 들어가는가」를 연습하기에 맞습니다. 링크와 마스킹할 텍스트는 제품 설명대로 브라우저에 남고, 세척 결과가 충분한지는 당신이 판단합니다.
이 연습의 목적은 어떤 사이트가 「절대 안전하다」고 증명하는 것이 아니라, 같은 확인 절차에 익숙해지는 것입니다. 로컬 암호화를 내세우는 어떤 페이지에서도 절차는 같습니다. 카나리아, Preserve log, 요청 줄, 요청 본문, 접속 분석 보고, 필요하면 Offline을 한 번 더.
다음에 확인할 때는 세 가지를 기억하세요. 첫째, 트래픽을 보고 슬로건은 보지 마세요. 둘째, 암호문이 나가는 것은 받아들일 수 있고, 키와 원문은 안 됩니다. 셋째, 브라우저, 버전, 기능을 바꾼 뒤에는 카나리아 검색을 다시 하세요. 반복할 수 있는 관찰만 여러분 자신의 보안 안내에 적을 가치가 있습니다.