AES 암호화/복호화

AES-128, AES-192, AES-256(FIPS 197)으로 GCM(인증형 암호화), CBC, CTR, ECB 모드에서 암호화하거나 복호화합니다. 키는 원시 hex 또는 Base64 바이트이거나 PBKDF2-HMAC-SHA256으로 암호에서 유도됩니다. GCM은 AAD를 지원하고 인증 태그를 따로 표시합니다. CBC/CTR/ECB 출력은 OpenSSL enc 호환입니다. 해시는 해시 생성기, 키 기반 MAC은 HMAC 생성기, 레거시 암호는 이 제품군의 레거시 암호 페이지를 보세요.
완전히 로컬에서 동작합니다 — 키와 평문은 탭 밖으로 나가지 않습니다. 파일은 200 MB까지.
여기에 입력한 모든 것은 이 탭 안에만 있습니다 — 하지만 그것이 “프로덕션 비밀에 안전”하다는 뜻은 아닙니다. 브라우저 메모리, 확장 프로그램, 엿보는 사람이 붙여넣는 내용을 볼 수 있습니다. 배우고, 검증하고, 상호 운용하는 데 쓰세요. 실 고객 데이터를 다루는 데는 쓰지 마세요.
방향: 모드: 출력:
GCM = 12바이트 논스와 128비트 인증 태그를 쓰는 AES-GCM(AEAD: 기밀성 + 무결성). 보안이 목표라면 기본 선택입니다.
hex는 공백, 콜론, 0x 접두사를 허용합니다.
같은 키 아래에서 GCM이나 CTR의 논스를 재사용하지 마세요.
태그 길이:
매개변수 줄은 정확한 키 판독 방식, IV, AAD 크기, 태그를 기록합니다. 복사해서 붙여넣은 결과를 언제나 다른 컴퓨터에서 재현할 수 있습니다.
어떤 모드를 골라야 하나요?
GCM이 기본 답입니다: 암호화 및 인증을 함께 수행합니다 — 태그 줄 덕분에 변조가 감지됩니다(태그 바이트 하나를 뒤집고 복호화해 보면 페이지가 거부합니다). CBC는 블록 패턴을 숨기지만 무결성은 없습니다. 써야 한다면 HMAC과 짝지으세요(HMAC 생성기 참고). CTR은 AES를 스트림 암호로 바꿉니다 — 패딩은 없지만 같은 키 아래 논스 재사용은 CTR과 GCM 모두에서 치명적입니다. ECB는 호환성과 학습용으로만 있습니다: 동일한 평문 블록은 동일한 암호문 블록이 됩니다(유명한 ECB 펭귄).
OpenSSL 상호 운용 — 이 페이지의 CBC와 CTR 출력(PKCS#7 패딩, 원시 키)은 openssl enc 명령줄과 왕복됩니다:
openssl enc -aes-256-cbc -K <64-hex-key> -iv <32-hex-iv> -in msg.txt -out msg.enc
openssl enc -d -aes-256-cbc -K <key> -iv <iv> -in msg.enc -out msg.txt
-aes-128-cbc, -aes-192-cbc, -aes-256-ctr(16바이트 IV = 초기 카운터 블록)에서도 동일합니다. 단 openssl enc은 GCM을 지원하지 않습니다 — 인증형 암호화에는 이 페이지나 OpenSSL 3.3+의 openssl aesgcm을 쓰세요.
중국 국가 암호가 필요하신가요?
SM4(GB/T 32907-2016) — 중국 상용 암호에서 지정된 블록 암호로, AES와 같은 128비트 블록과 키 크기를 쓰지만 독자적인 키 스케줄과 S-박스를 가집니다 — 는 자체 페이지에서 ECB와 CBC 모드로 동작합니다: SM4 암호화/복호화. SM 제품군의 나머지도 그곳에 있습니다: SM3(해시), SM2(공개 키), SM9(ID 기반 암호).
자체 테스트
페이지 엔진을 독립적인 기준값에 대해 구동합니다: 네 모드의 기지 응답 벡터(독립 네이티브 구현으로 생성), AAD 유무별 GCM 태그 벡터, WebCrypto 엔진과 순수 JS AES 엔진의 교차 검증, GCM 왕복, 부정 테스트(변조된 태그, 잘못된 키는 실패해야 함). 아무것도 전송되지 않습니다.
AES 암호화 처음부터 설명
한 문장으로: AES는 세계 표준 블록 암호입니다 — 128, 192, 256비트 키 아래 16바이트 블록을 섞습니다 — 그리고 어떤 모드(GCM, CBC, CTR, ECB)로 구동하느냐가 블록 연결 방식, IV의 역할, 변조 적발 가능 여부를 결정합니다. 이유가 없다면 GCM을 고르세요.
AES 자체란 무엇인가(FIPS 197)

블록 암호. AES(Rijndael 설계, NIST가 2001년 FIPS 197으로 표준화)는 한 번에 정확히 16바이트를 암호화합니다. 키 길이 — 16, 24, 32바이트 — 가 AES-128/-192/-256과 내부 라운드 수(10, 12, 14)를 결정합니다. 각 라운드는 치환 테이블, 행 이동, 열 혼합을 통해 키에서 유도된 라운드 키를 블록과 섞습니다. 암호 자체를 깨는 실용적 공격은 없습니다: 실세계 실패는 거의 언제나 모드, IV, 키 관리 실수이며, 이 페이지의 나머지가 바로 그것을 다룹니다.

왜 모드가 필요한가? 메시지가 정확히 16바이트인 경우는 드물기 때문입니다. 모드가 블록 암호화들을 접착합니다: ECB는 블록을 그냥 독립적으로 암호화하고, CBC는 각 블록을 이전 암호문과 XOR하고, CTR은 카운터를 암호화해 데이터와 스트림 암호처럼 XOR하고, GCM은 CTR 위에 인증 태그를 더합니다. AES는 그대로입니다 — 모드가 보장을 좌우합니다.

키와 암호. AES 키는 16, 24, 32바이트의 무작위 바이트입니다. 사람 암호는 그렇지 않습니다. 이 페이지의 암호 옵션은 PBKDF2-HMAC-SHA256(기본 600,000 반복, OWASP 2023 기준선 — KDF 세부사항은 HMAC 생성기 참고)으로 올바른 키를 유도합니다. 암호 문자열을 AES 키로 직접 쓰지 마세요: 엔트로피는 길이의 극히 일부입니다.

네 모드 비교
모드IV / 논스무결성비고
GCM12바이트, 메시지마다 유일있음 — 96..128비트 태그AEAD: 어디서나 권장 기본값(TLS 1.3, SSH, 파일 형식). AAD도 지원.
CBC16바이트, 예측 불가능없음PKCS#7 패딩; 고전적이지만 MAC이 옆에 필요. 패딩 오라클 버그가 CBC의 고전적 함정.
CTR16바이트 초기 카운터없음패딩 없음, 스트림 방식, 임의 접근; 한 키에서 논스 재사용 시 평문 XOR 평문이 새어 나감.
ECB없음없음동일 블록 → 동일 암호문. ECB 펭귄 실험. 호환 전용.

IV 규칙 한 문단. IV는 비밀이 아닙니다 — 암호문 옆에 보내세요 — 하지만 유일성 규칙은 다릅니다: CBC는 예측 불가능한 IV를 원하고, GCM과 CTR은 같은 키에서 논스 재사용 금지만 요구합니다(GCM 논스 재사용은 더 나쁩니다: 인증 키가 새어 나갑니다). 이 페이지의 무작위 IV 버튼은 브라우저의 보안 RNG를 씁니다. 모두 0 버튼은 테스트 벡터 재현용이지 실제 메시지용이 아닙니다.

패딩. CBC와 ECB는 온전한 블록이 필요하므로 PKCS#7 패딩이 패드 길이와 같은 값을 가진 1..16바이트를 덧붙입니다. 그래서 CBC 암호문이 최대 16바이트까지 늘어나고, 잘못된 키로 복호화하면 대개 패딩 오류로 실패합니다. CTR과 GCM은 스트림 방식이라 패딩이 없습니다 — 암호문 길이가 정확히 평문 길이입니다(CTR 모드에서 샘플을 돌려 보세요: 43바이트 들어가 43바이트 나옵니다).

CFB와 OFB(나머지 두 고전 모드)는 이 페이지에 없습니다: CTR처럼 스트림 방식이지만 CTR보다 나은 점이 없고, 주로 오래된 프로토콜에 남아 있습니다.

GCM이 더하는 것(AEAD, 태그, AAD)

인증형 암호화. GCM = CTR 암호화 + 암호문·IV·AAD에 대한 GHASH 인증자. 출력 태그는 모든 것의 지문입니다: 암호문, IV, AAD의 비트 하나만 바꿔도 태그가 더 이상 맞지 않아, 수신자가 메시지가 온전하고 키 보유자에게서 왔음을 증명할 수 있습니다. CBC+HMAC은 올바르게 조립해야(encrypt-then-MAC) 같은 효과를 냅니다 — GCM은 구조적으로 처음부터 옳습니다.

AAD. 추가 인증 데이터는 평문으로 전달되지만 태그가 보호합니다: 프로토콜 헤더, 파일 이름, 알고리즘 식별자. 수신자는 동일한 AAD 바이트를 제공해야 합니다. 아니면 태그 검사가 실패합니다 — 그것이 요점입니다.

태그 길이. 기본 128비트 태그가 권장입니다. 더 짧은 태그(96..120비트)는 크기를 위해 위조 내성을 희생합니다. 96비트 미만에서는 GCM의 보안 증명이 빠르게 악화되므로 이 페이지는 거기서 멈춥니다.

논스 재앙. 같은 키 아래 12바이트 GCM 논스를 재사용하면 두 메시지 평문의 XOR과 인증 하위 키가 새어 나갑니다 — 이후 그 키의 모든 미래 메시지에 대해 위조가 가능해집니다. 유일성을 보장할 수 없는 시스템은 논스 오용 내성 변형(AES-GCM-SIV, RFC 8452)을 씁니다.

기준값 — 이 페이지에서 재현해 보세요

첫 행은 유명한 FIPS 197 단일 블록 예제이고, 나머지는 독립 네이티브 구현(Node.js의 OpenSSL)으로 생성해 이 페이지의 엔진으로 재검증한 것입니다. 키, IV, 입력을 페이지에 붙여넣어 각 행을 재현해 보세요.

사례입력기대 출력
AES-128 단일 블록(FIPS 197 방식)key 000102..0f, plaintext 00112233..ff69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCMkey 000102..0f, IV 606162..6b, plaintext 0011..ef ×2ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM, 같되 AAD deadbeefkey 000102..1fct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBCkey 000102..1f, IV 101112..1f, plaintext 0011..ef ×20e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR(위 CBC와 같은 입력)43-byte plaintext → 43-byte ciphertexte9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c
흔한 실수
  • IV가 필요 없다는 이유로 ECB 쓰기. 그 편함이 함정입니다: 블록 패딨이 그대로 암호문에 새어 나갑니다(비트맵을 암호화해도 그림이 보입니다). ECB는 단일 블록이나 정확히 16바이트 무작위 키에만 acceptable 합니다 — 실전에서는 선택해서 쓰면 안 됩니다.
  • 논스/IV 재사용. 한 키 아래 GCM이나 CTR에서는 모든 것을 한 번에 무너뜨리는 유일한 실수입니다. 카운터 기반 시스템(이 페이지의 무작위 IV 버튼)은 그것을 불가능하게 만들려고 존재합니다.
  • IV를 비밀로 취급하기. 아닙니다. 암호문 옆에 저장하거나 전송하세요. 숨겨서 얻는 것은 없고 재사용의 유혹만 생깁니다.
  • 암호를 키로 쓰기. "hunter2hunter2hunter2hunter2"는 32바이트이지만 256비트 엔트로피가 아닙니다 — 패딩 붙은 사전 단어입니다. PBKDF2(이 페이지 내장)로 유도하거나 무작위 키를 생성하세요.
  • CBC가 변조를 적발한다고 가정하기. CBC 암호문의 비트를 뒤집으면 복호화는 조용히 오염된 평문으로 “성공”합니다. GCM의 태그(또는 명시적 HMAC)만이 변조를 보이게 만듭니다.
  • GCM 암호문을 같은지 비교하기. 무작위 논스에서는 같은 평문도 매번 다르게 암호화됩니다 — 그것이 기능입니다. 결정적 암호화는 별개의 특수 도구입니다.
FAQ

AES-128은 여전히 안전한가요, 256이 필요한가요? 둘 다 현실적 공격자에게 안전합니다. 알려진 최선의 공격도 안전 마진의 극히 일부만 깎습니다. AES-256은 주로 장기 비밀과 양자 후 편안함(Grover 알고리즘이 키 강도를 절반으로 깎아 AES-256이 약 128비트 등가로 남음)을 위해 중요합니다.

왜 openssl enc은 GCM을 못 하나요? enc 명령은 AEAD 이전의 것이어서 태그를 실을 방법이 없습니다. OpenSSL 3.3이 전용 aesgcm 명령을 추가했습니다. 이 페이지의 GCM 출력은 태그를 별도 줄에 두어 둘 다 명시적으로 옮길 수 있게 합니다.

키 래핑(AES-KW)이란? 다른 키를 고정 64비트 청크로 암호화하고 자체 무결성 검사를 하는 특수 모드입니다. 입출력이 메시지 모양이 아니라 키 모양이라 여기서는 제공하지 않습니다 — 오용이 보통입니다.

왜 CTR 암호문은 평문과 길이가 같은데 CBC는 더 길죠? CTR과 GCM은 스트림 방식(패딩 없음)이고 CBC/ECB는 PKCS#7으로 온전한 16바이트 블록에 맞춥니다. 길이 차이는 설계이지 버그가 아닙니다.

다른 곳에서 암호화한 것을 복호화할 수 있나요? 네, 정확한 모드, 키, IV(GCM이면 태그까지)를 알면 됩니다. 이 페이지의 출력 줄은 도구 사이에 매개변수를 옮길 수 있도록 모두 정확히 기록합니다 — 위의 OpenSSL 박스가 해당 명령줄을 보여줍니다.