클라우드 스토리지, 파일 공유 플랫폼, “안전하다”는 업로드 서비스들. 이것들에는 공통점이 하나 있어요. 파일이 다른 누군가의 서버를 거쳐간다는 거예요. 서비스 제공자의 암호화 방식, 키 관리 방법, 직원들의 윤리 의식, 그리고 데이터 제출 요청에 어떻게 대응하는지까지 믿어야 해요. 한 번도 만난 적 없는 회사에 그 많은 걸 맡기는 셈이죠.
그렇다면 파일이 내 기기를 떠나기 전에 암호화가 완료된다면 어떨까요? 브라우저 안에서, 서버는 평문을 절대 볼 수 없는 방식으로요.
바로 그게 hat.sh가 하는 일이에요.
hat.sh가 실제로 하는 것
hat.sh는 브라우저 기반 파일 암호화 도구예요. 파일을 페이지에 드래그하고 비밀번호(또는 공개 키)를 입력하면 암호화된 .enc 파일이 나와요. 복호화는 반대로 하면 돼요. .enc 파일을 같은 페이지에 드래그하고 비밀번호를 입력하면 원본 파일이 돌아와요. 모든 처리는 JavaScript로 로컬에서 이루어지고, 파일 내용이 네트워크로 전송되는 일은 없어요. 백엔드도 없고, 데이터베이스도 없어요.
암호화 방식은 AES-256-GCM이에요. Signal, WhatsApp, 그리고 대부분의 현대 TLS 연결에서 사용하는 알고리즘이죠. 인증 암호화 방식이라서 파일이 중간에 변조되면 복호화가 명확하게 실패해요. 암호화된 파일을 살짝 바꿔서 hat.sh가 받아들이게 할 수는 없어요.
hat.sh는 두 가지 모드를 지원해요:
- 비밀번호 기반 암호화: 비밀번호를 설정하면 도구가 PBKDF2로 암호화 키를 유도해요. 비밀번호를 가진 사람이라면 누구든 복호화할 수 있어요.
- 공개 키 암호화: 키 쌍을 생성하고 공개 키를 공유하면, 누구든 당신만 개인 키로 열 수 있는 파일을 암호화할 수 있어요. X25519 키 교환과 AES-256-GCM을 결합한 방식이에요.
공개 키 모드는 팀 작업에 특히 유용해요. 예를 들어 기자가 공개 키를 게시하면, 제보자는 hat.sh로 문서를 암호화해서 보낼 수 있어요. 보내는 쪽에서는 별도 설정이 전혀 필요 없어요.
로그인 없음, 업로드 없음, 계정 없음
이 도구의 프라이버시 구조는 놀랍도록 깔끔해요. 소스 코드는 GitHub에 공개되어 있고 MIT 라이선스예요. 브라우저에서 어떤 JavaScript가 실행되는지 직접 읽어볼 수 있어요. 텔레메트리도 없고, 파일 메타데이터를 포함한 분석 요청도 없고, 공격받을 수 있는 서버 측 구성 요소도 없어요.
일반적인 “안전한” 파일 공유 서비스와 비교해보면:
| 기능 | 일반 암호화 업로드 서비스 | hat.sh |
|---|---|---|
| 파일이 서버로 전송됨 | 예 | 아니오 |
| 계정 필요 | 대부분 | 절대 없음 |
| 서버가 평문 접근 가능 | 구현에 따라 다름 | 아니오 |
| 소스 코드 감사 가능 | 드물게 | 예 (MIT) |
| 오프라인 동작 | 아니오 | 예 (첫 로드 이후) |
VirusTotal 같은 도구는 설계상 파일을 외부 서버로 보내요. 그게 목적이니까요. hat.sh는 정반대예요. 파일 내용이 아무 데도 가지 않는 게 핵심이에요.
hat.sh가 필요한 순간
프리랜서 회계사가 세금 서류를 고객에게 보내야 한다고 생각해봐요. 이메일은 평문이에요. 대부분의 파일 공유 링크는 만료되거나 인덱싱돼요. 간단한 방법이 필요해요. 웹페이지를 열고, 공유 비밀번호로 파일을 암호화하고, 결과를 보내는 것만으로요.
또는 저장소에서 자격 증명을 교체하는 개발자를 생각해봐요. .env 파일을 팀원에게 딱 한 번 안전하게 공유해야 해요. 단 한 번의 전송을 위해 GPG 키 인프라를 구축하고 싶지는 않죠. hat.sh를 쓰면 일회용 비밀번호로 암호화하고, .enc 파일을 Slack, Discord, 이메일로 보내면 돼요. 비밀번호 없이는 암호화된 파일은 아무 의미가 없어요.
보안 연구자에게도 공개 키 모드는 실질적인 가치가 있어요. 웹사이트에 공개 키를 게시해두면 누구든 암호화 파일을 보낼 수 있어요. 받는 쪽에서는 아무것도 설치할 필요가 없어요. PGP 키 서버도, GPG 클라이언트도, Web of Trust의 복잡한 구조도 필요 없어요.
클라이언트 사이드 암호화의 기술적 솔직함
클라이언트 사이드 암호화에는 솔직하게 인정해야 할 한계가 있어요. 웹사이트 자체가 침해되면, 악성 JavaScript가 암호화 전에 비밀번호나 파일을 빼낼 수 있어요. 이건 브라우저 기반 암호화 도구가 본질적으로 안고 있는 긴장이에요.
hat.sh는 몇 가지 방법으로 이를 다뤄요. 첫째, 오픈 소스 코드 덕분에 누구든 JavaScript를 감사할 수 있어요. 둘째, 저장소를 다운로드해서 hat.sh를 완전한 에어갭 환경에서 로컬로 실행할 수 있어요. 셋째, 매우 높은 보안 요건이 있는 사용자를 위해 셀프 호스팅용 Docker 설정도 제공해요.
대부분의 사용 사례——민감한 문서를 동료에게 보내거나, 클라우드에 올리기 전에 백업을 암호화하거나, 설정 파일을 보호하는 것——에서 CDN 침해는 위협 모델에 포함되지 않아요. 브라우저 기반 암호화는 파일을 평문으로 보내는 것보다 실질적으로 훨씬 나은 보안을 제공해요.
브라우저가 암호화를 어떻게 처리하는지 궁금하다면 Web Crypto API 명세를 참고하세요. hat.sh가 내부에서 사용하는 기본 요소들이 문서화되어 있어요. 커스텀 구현이 아니라 브라우저의 네이티브 기능이에요. 암호화 연산은 해석 실행되는 JavaScript가 아니라 최적화된 C++ 코드로 실행된다는 의미예요.
hat.sh와 비슷한 노로그인 도구 비교
CyberChef를 알고 있을 수도 있어요. 이것도 완전히 브라우저에서 실행되고 AES 암호화를 처리할 수 있어요. 하지만 CyberChef는 인코딩, 압축, 해싱을 포함한 수백 가지 작업을 다루는 범용 데이터 변환 도구예요. 그 폭넓은 기능이 강점이지만, 기술적이지 않은 사용자에게는 복잡하게 느껴질 수 있어요.
hat.sh는 딱 한 가지에 집중해요. 파일을 안전하게 전송하거나 저장할 수 있도록 암호화하는 것이요. 인터페이스가 충분히 단순해서 AES가 뭔지 모르는 사람한테 URL을 던져줘도 1분 안에 파악해요. 단순함 자체가 기능이에요.
Wormhole은 관련되어 있지만 다른 문제를 해결해요. 엔드투엔드 암호화로 P2P 파일 전송을 지원하지만, 양쪽이 동시에 온라인이어야 하고 파일은 릴레이 서버를 거쳐요. hat.sh는 정적인 암호화 파일을 생성하기 때문에 어떤 채널로든 비동기로 보낼 수 있어요.
시작하기
hat.sh를 처음 사용하는 데 걸리는 시간은 약 30초예요:
- hat.sh로 이동해요
- 파일을 페이지에 드래그하거나 클릭해서 찾아봐요
- “Password” 모드를 선택하고 강력한 패스프레이즈를 입력해요
- Encrypt를 클릭하면
.enc파일이 다운로드돼요 .enc파일은 아무 채널로나 보내고, 비밀번호는 따로 공유해요
복호화하려면:
- hat.sh로 이동해요
.enc파일을 페이지에 드래그해요- 비밀번호를 입력해요
- 원본 파일이 자동으로 다운로드돼요
계정 없음, 설치 없음, 제3자 신뢰 없음. 암호화된 파일은 그냥 바이트 덩어리예요. Dropbox에 저장하거나, 이메일로 보내거나, 공개적으로 게시해도 돼요. 비밀번호 없이는 아무 의미가 없는 데이터예요.
프라이버시 도구에는 흔히 트레이드오프가 있어요. 강한 보안에는 고통스러운 복잡성이 따르거나(GPG가 그 예), 사용이 편리하면 데이터가 남의 서버로 가야 해요. hat.sh는 다른 방향을 선택했어요. 잘 설계되고 투명하며 오픈 소스인 웹 앱이라면 둘 다 가능하다는 것을요. 브라우저가 더 강력해지고 Web Crypto API가 성숙해질수록, 이 패턴을 따르는 도구가 늘어날 거예요. 서버는 코드만 전달하고, 민감한 모든 처리는 내 기기에서 이루어지는 방향으로요.