브라우저에서 AES-256 암호화 — 서버를 믿지 않고 텍스트를 보호하는 방법

몇 년 전, 같이 작업하던 동료에게 레거시 시스템의 접속 정보를 보내야 했습니다. 운영 환경 비밀 키가 아니라 내부 테스트 도구의 관리자 비밀번호였습니다. 채팅이나 이메일에 평문으로 보내기엔 찜찜하지만, 이것 하나 때문에 시크릿 관리 시스템을 구축하기엔 과한 상황이었습니다.

당시 해결책은 7-Zip으로 파일을 압축하고 암호화해서 보내는 것이었습니다. 번거로웠지만 효과는 있었습니다. 제가 실제로 원했던 것은 훨씬 간단했습니다 — 텍스트 문자열을 받아 비밀번호로 암호화하고, 수신자가 같은 비밀번호로 복호화할 수 있는 뭔가.

그게 바로 Text Encrypt & Decrypt 도구가 하는 일입니다. 이전에는 서버 사이드 코드나 네이티브 암호화 라이브러리로만 가능했던 암호화를 브라우저에서 구현합니다. 보안은 장식품 수준이 아닙니다 — 기밀 정보를 보호하는 데 실제로 쓰이는 동일한 알고리즘입니다.

AES-256-GCM이 의미하는 것

수학 없이 알고리즘 이름을 설명하겠습니다. 용어를 알면 실제로 무엇을 얻는지 이해하는 데 도움이 됩니다.

AES는 고급 암호화 표준(Advanced Encryption Standard)입니다. 동일한 키로 암호화하고 복호화하는 대칭 블록 암호입니다. 미국 국립표준기술연구소(NIST)가 국제 공모전을 거쳐 2001년에 선택했으며 기존의 DES 표준을 대체했습니다. 전 세계적으로 지배적인 암호화 알고리즘입니다.

256은 비트 단위의 키 크기입니다. AES는 128비트, 192비트, 256비트 키를 지원합니다. 256비트가 가장 강력합니다. 가능한 256비트 키의 수는 2²⁵⁶ — 대략 1.16 × 10⁷⁷개입니다. 관측 가능한 우주의 원자 수가 10⁸⁰개 정도입니다. 무차별 대입으로 256비트 키를 찾는 것은 현실적으로 불가능합니다.

GCM은 갈루아/카운터 모드(Galois/Counter Mode)의 약자입니다. AES가 128비트 블록보다 긴 데이터를 처리하는 방식입니다. GCM은 인증 암호화 방식입니다 — 데이터를 암호화할 뿐만 아니라 암호문이 변조되지 않았음을 검증하는 인증 태그도 생성합니다. 누군가 암호화된 출력의 비트를 뒤집으면 복호화가 자동으로 실패합니다. 변조된 암호문이 조용히 잘못된 평문을 생성하지 않습니다. 중요한 특성입니다.

CBC(암호 블록 체이닝)가 가장 흔한 대안이지만 GCM이 현대적 권고사항입니다. AES-256-GCM을 보면 신중하게 선택된 암호화를 보고 있는 것입니다.

비밀번호 문제: PBKDF2가 필요한 이유

AES-256은 256비트 키를 받습니다. 여러분의 비밀번호는 256비트가 아닙니다 — 아마도 8-30자의 대소문자와 숫자 조합일 텐데, 키 공간이 훨씬 작습니다. 비밀번호를 그대로 AES에 넣을 수 없습니다.

PBKDF2(비밀번호 기반 키 파생 함수 2)가 다리 역할을 합니다. 비밀번호와 무작위 솔트(동일한 비밀번호가 동일한 키를 생성하지 않도록 암호화마다 생성되는 고유값)를 받아, 해시 함수를 수만 번 반복 적용합니다. 결과는 AES에 적합한 256비트 키입니다.

"수만 번 반복"은 의도적입니다. PBKDF2는 느리도록 설계되었습니다. 암호문을 확보한 누군가가 사전의 모든 단어로 비밀번호를 무차별 대입하려 하면, 각 시도마다 원래 키 파생에 사용된 것과 같은 반복 횟수만큼 PBKDF2를 실행해야 합니다. 10만 번 반복을 사용한 경우, 초당 100만 개의 비밀번호를 시도하는 기계도 10만 개 단어 사전을 소진하는 데 17분이 걸립니다. 약한 비밀번호는 여전히 크랙 가능하지만 공격 비용이 훨씬 높아집니다.

솔트는 같은 비밀번호 "hello123"으로 서로 다른 메시지를 암호화해도 다른 암호문 출력이 나오도록 보장합니다.

Web Crypto API가 여기서 하는 역할

브라우저의 Web Crypto API(window.crypto.subtle)는 JavaScript가 아닌 브라우저의 C++ 엔진에서 네이티브로 실행되는 암호화 작업을 제공합니다. 이것이 중요한 이유:

1. 성능이 더 좋습니다. 네이티브 암호화는 JavaScript 구현보다 훨씬 빠릅니다.
2. 보안이 더 강합니다. 브라우저 벤더가 구현하고 감사한 알고리즘입니다. JavaScript 구현은 미묘한 버그가 있을 수 있습니다.
3. 아무것도 브라우저 밖으로 나가지 않습니다. HTTP 요청이 없습니다. 암호화는 여러분의 기기에서만 일어납니다.

Text Encrypt & Decrypt 도구는 crypto.subtle.importKey, crypto.subtle.deriveKey(PBKDF2용), crypto.subtle.encrypt/decrypt를 사용합니다. 이것들은 비밀번호 관리자와 종단 간 암호화 메시징 애플리케이션에서 사용하는 것과 동일한 API입니다.

도구 사용 방법

Text Encrypt & Decrypt 도구를 열면 두 개의 주요 섹션이 있습니다: 암호화(Encrypt)와 복호화(Decrypt).

암호화하려면:

1. 입력 필드에 텍스트를 붙여넣습니다.
2. 비밀번호를 입력합니다. 의미 있는 길이를 선택하세요 — 16자 이상이 8자짜리보다 PBKDF2 파생 키 재료로 훨씬 강합니다.
3. 암호화를 클릭합니다. 출력 필드에 암호문이 나타납니다 — 무작위 문자처럼 보이는 긴 문자열(Base64 인코딩)입니다.
4. 암호문을 복사합니다.

복호화하려면:

1. 복호화 입력 필드에 암호문을 붙여넣습니다.
2. 암호화에 사용한 동일한 비밀번호를 입력합니다.
3. 복호화를 클릭합니다. 비밀번호가 맞으면 원래 평문이 나타납니다.

비밀번호가 틀리면 오류와 함께 복호화가 실패합니다 — 잘못된 출력을 조용히 생성하지 않습니다. 인증 암호화의 올바른 동작입니다.

도구는 아무것도 저장하지 않습니다. 계정도, 로그도, 서버 호출도 없습니다. 탭을 닫으면 데이터는 사라집니다.

클라이언트 사이드 암호화가 실제로 적합한 경우

모든 상황에 맞는 도구가 아닙니다. 하지만 분명히 적합한 경우들이 있습니다.

불안전한 채널로 민감한 텍스트 공유하기

누군가에게 자격 증명, API 키, 비밀 메모, 민감한 설정을 보내야 합니다. 이메일은 종단 간 암호화가 되지 않습니다. Slack과 Teams는 전송 중 암호화되지만 서버 관리자는 읽을 수 있습니다. SMS는 더 나쁩니다.

보내기 전에 텍스트를 암호화하면 암호문을 전달하는 채널이 안전할 필요가 없습니다. 이메일로 암호화된 블록을 보내고 비밀번호는 별도로 문자로 보낼 수 있습니다. 이메일을 가로채는 사람은 비밀번호 없이는 쓸모없는 문자열만 얻습니다.

완벽한 해결책은 아닙니다 — 비밀번호 채널이 신뢰할 수 있어야 하고, 매우 약한 비밀번호는 여전히 크랙 가능합니다. 하지만 평문보다 훨씬 낫고, 별도의 인프라가 필요 없습니다.

클라우드 서비스에 저장하기 전 노트 암호화

Notion, 옵시디언 Sync, Apple 메모, 구글 킵을 사용합니다. 이 서비스들은 데이터에 접근할 수 있습니다 — 서버가 처리하고 저장합니다. 어떤 제3자도 읽지 못하게 하고 싶은 노트가 있다면 — 의료 정보, 재무 세부 사항, 일기 — 클라이언트 사이드에서 암호화한 후 저장하는 것이 올바른 모델입니다.

노트를 암호화하고 암호문을 클라우드 서비스에 저장합니다. 서비스는 암호문을 봅니다. 읽을 때는 여러분만 아는 비밀번호로 복호화합니다.

마찰이 있습니다 — 먼저 복호화하지 않고는 암호화된 노트를 전문 검색할 수 없고, 비밀번호를 잃으면 노트도 영구적으로 잃습니다. 이 트레이드오프를 이해한 후 이 워크플로를 선택해야 합니다.

개인 데이터 백업

공유 드라이브, 클라우드 스토리지 버킷, 또는 다른 사람 손에 들어갈 수 있는 USB에 백업한다면, 저장 전 민감한 파일을 암호화하는 것이 좋습니다. 단일 텍스트 블록 — 보관하는 비밀번호, 복구 코드, 개인 키 — 에 대해서는 전체 암호화 아카이브보다 텍스트 암호화 도구가 더 빠릅니다.

개발자 워크플로: 설정 파일의 시크릿

가끔 개발자가 환경 변수나 시크릿 관리자를 사용할 수 없는 환경 때문에 저장소에 시크릿을 커밋해야 하는 경우가 있습니다. 이상적이지 않지만 발생합니다. 커밋 전 값을 암호화하고, README에 복호화 단계를 문서화하며, 비밀번호는 팀 비밀번호 관리자에 별도 저장하는 것이 평문 시크릿보다 낫습니다.

이 접근 방식은 적절한 시크릿 관리의 대안이 아닙니다. 하지만 제약된 상황에서 아무것도 안 하는 것보다는 낫습니다.

클라이언트 사이드 암호화가 보호하지 못하는 것

보안 도구를 책임감 있게 사용하려면 한계를 정직하게 알아야 합니다.

약한 비밀번호. 암호화는 비밀번호만큼만 강합니다. "abc123" 같은 6자짜리 비밀번호를 쓰는 AES-256은 사전 공격에 취약합니다. 알고리즘의 수학은 건전합니다; PBKDF2는 약한 입력 재료로 할 수 있는 것에 한계가 있습니다. 길고 무작위한 비밀번호 문구를 사용하세요.

기기 자체의 침해. 악성 소프트웨어가 키로거 기능이 있거나 클립보드를 읽을 수 있다면 암호화 단계는 무의미합니다 — 공격자가 암호화 전 평문을 가로채거나 입력하는 비밀번호를 캡처합니다. 클라이언트 사이드 암호화는 전송 중 가로채기와 무단 서버 접근을 막습니다. 기기가 침해된 경우엔 도움이 안 됩니다.

브라우저 확장 프로그램. 브라우저에서 모든 확장 프로그램은 잠재적으로 페이지 내용에 접근할 수 있습니다. 악의적인 확장 프로그램은 복사하기 전에 DOM에서 복호화된 텍스트를 읽을 수 있습니다. 진짜 민감한 정보를 암호화한다면 실행 중인 확장 프로그램을 인지하세요.

비밀번호 분실. 복구 메커니즘이 없습니다. 계정도, 서버도, 비밀번호 재설정 방법도 없습니다. 무언가를 암호화하는 데 사용한 비밀번호를 잊으면 암호문은 복구 불가능합니다. 장기 보관이 필요한 것을 암호화하기 전에 비밀번호를 어딘가 안전하게 기록해두세요.

왜 RSA나 GPG가 아닌가

RSA(비대칭 암호화)나 GPG를 쓰지 않는 이유가 궁금할 수 있습니다. 간단하게 말하면 AES는 대량 데이터 암호화에 더 빠르고, 공유 비밀번호 시나리오에 더 단순합니다. RSA와 GPG는 비대칭 시나리오 — 키를 먼저 공유하지 않고 누군가에게 무언가를 암호화하고 싶을 때 — 를 위해 설계되었습니다. "내가 암호화하고 당신이 복호화"하는 공유 비밀번호 워크플로에는 대칭 암호화가 올바른 모델입니다.

도구의 AES-256-GCM 사용은 여러 면에서 더 나은 선택입니다:

• AES-256-GCM이 AES-256-CBC보다 나은 이유: GCM이 인증을 제공하지만 CBC는 그렇지 않습니다.
• PBKDF2가 직접 해시보다 나은 이유: PBKDF2의 계산 비용이 무차별 대입 공격을 훨씬 어렵게 만듭니다.
• 이것은 자체 제작 암호화가 아닙니다 — 전 세계 암호학자들이 검토한 공개 표준입니다.

관련 도구

Password Generator — 암호화에 사용할 비밀번호 문구를 생성합니다. 스스로 생각해낸 단어보다 진정한 무작위성이 필요합니다.

Password Strength Checker — 암호화에 비밀번호 문구를 사용하기 전 실제로 얼마나 강한지 확인하세요. 여기서 엔트로피가 대부분의 상황보다 더 중요합니다.

Hash Generator — 텍스트에서 SHA-256, MD5 등 해시를 생성합니다. 암호화와 관련되지만 다릅니다 — 해시는 단방향이고 키가 필요 없습니다.

Base64 Encoder — 암호화된 출력은 일반적으로 Base64 인코딩됩니다. 암호화와 별도로 인코딩을 이해하거나 조작해야 한다면 Base64 도구가 처리합니다.

FAQ

AES-256 암호화가 무엇인가요? 256비트 키를 사용하는 고급 암호화 표준입니다. 정부, 금융 기관, 보안 애플리케이션에서 사용하는 대칭 암호입니다. 256비트 키 공간은 무차별 대입 공격이 계산적으로 불가능할 만큼 큽니다.

클라이언트 사이드 암호화가 실제로 안전한가요? 올바르게 구현되면 네. 브라우저의 Web Crypto API는 서버 사이드 라이브러리와 동일한 암호화 기본 요소를 제공합니다. 보안은 주로 비밀번호 강도에 달려 있습니다. 서버가 절대 데이터를 보지 않는 것이 장점입니다.

비밀번호를 잊으면 어떻게 되나요? 암호화 키가 비밀번호에서 파생됩니다. 비밀번호 없이는 키를 재구성할 수 없고, 키 없이는 암호문을 복호화할 수 없습니다. 서버 측 복구 메커니즘이 없습니다. 이것이 클라이언트 사이드 암호화의 트레이드오프입니다 — 최대한의 프라이버시는 복구 방법이 없음을 의미합니다.

암호화된 텍스트를 어떻게 안전하게 공유하나요? 암호문은 이메일이나 채팅 등 일반 채널로 보내고, 비밀번호는 전화, 다른 앱, 또는 직접 만나서 별도로 전달하세요. 암호문과 비밀번호를 분리 보관하면 어느 하나만 가로채도 평문 복원이 불가능합니다.

약한 비밀번호를 사용하면 얼마나 위험한가요? PBKDF2가 무차별 대입을 더 어렵게 만들지만, "123456"이나 짧은 단어 같은 매우 약한 비밀번호는 여전히 크랙 가능합니다. 16자 이상의 무작위 비밀번호 문구를 사용하세요. Password Generator가 강한 비밀번호 생성에 도움이 됩니다.

마치며

클라이언트 사이드 AES-256-GCM 암호화는 만능이 아닙니다. 침해된 기기를 막지 못하고, 약한 비밀번호를 선택하면 효과가 줄어들며, 비밀번호를 잃으면 복구가 불가능합니다. 이 한계들은 이해할 가치가 있습니다.

하지만 설계된 사용 사례 — 불신뢰 채널로 민감한 텍스트 공유, 클라우드 저장 전 노트 암호화, 시크릿 아카이브 — 에서는 잘 구현된 암호학적으로 견고한 옵션입니다. Text Encrypt & Decrypt 도구는 실제 보안 애플리케이션을 보호하는 동일한 알고리즘을 사용하며, 데이터가 브라우저를 떠나지 않고 완전히 여러분의 기기에서 실행됩니다.

접근성과 진정한 보안의 조합이 이 도구를 쓸 만한 이유입니다.