AES 암호화 도구

AES(Advanced Encryption Standard)는 현재 전 세계에서 가장 널리 사용되는 대칭 암호화 알고리즘으로, NSA에 의해 극비 정보 보호에 승인되었습니다. AES는 벨기에 암호학자 Joan Daemen과 Vincent Rijmen가 설계한 Rijndael 암호에서 발전하여 2001년 NIST에 의해 공식 발표되었으며, 더 이상 안전하지 않은 DES 알고리즘의 대체재가 되었습니다. AES는 고정 블록 크기 128비트(16바이트)의 블록 암호화를 사용하며, 128, 192, 256비트의 세 가지 키 길이를 지원하여 AES-128, AES-192, AES-256의 세 가지 보안 수준에 대응합니다. 키가 길수록 보안은 높아지지만 암복호화 속도는 약간 저하됩니다. 대칭 암호화 알고리즘으로서 AES는 암호화와 복호화에 동일한 키를 사용하므로 비대칭 암호화 알고리즘보다 훨씬 효율적입니다. AES의 응용 범위는 매우 넓습니다. 네트워크 보안에서는 TLS/SSL 프로토콜이 웹 브라우징과 이메일 전송을 보호하기 위해 AES를 사용하고, 스토리지 보안에서는 BitLocker, FileVault 등의 디스크 암호화 도구가 사용자 데이터 암호화에 AES를 채택하며, 데이터베이스 보안에서는 많은 시스템이 AES 열 수준 암호화를 지원하고, IoT에서는 기기 간 안전한 통신에 널리 사용됩니다. 이 도구는 AES의 모든 6가지 암호화 모드(ECB, CBC, CFB, OFB, CTR, GCM)와 5가지 패딩 방식을 지원하여 다양한 암호화 요구를 충족합니다.

AES(Advanced Encryption Standard)는 NIST가 1997년 15개 후보로 시작한 5년간의 공개 대회를 거쳐 2001년 11월 FIPS 197로 발표되었습니다. 우승작은 벨기에 암호학자 Joan Daemen과 Vincent Rijmen가 설계한 Rijndael로, Twofish, Serpent, RC6, Mars 등의 결선 진출작을 제쳤습니다. AES는 DES(FIPS 46, 2005년 폐지)를 대체하여 현재 전 세계에서 가장 널리 배포된 대칭 블록 암호입니다: TLS 1.2/1.3, IPsec, BitLocker, FileVault, OpenSSL의 기본 aes-256-gcm, Linux 커널의 dm-crypt, Apple의 CryptoKit, Android의 Keystore 등에 내장되어 있습니다. NSA는 2003년 AES-256을 극비(TOP SECRET) 정보 보호에 승인(suite A)하여 AES는 미국 최고 등급 분류에 처음으로 사용 승인된 공개 암호가 되었습니다. 블록 크기는 128비트(16바이트)로 고정이며, 키 크기는 128, 192, 256비트로 각각 10, 12, 14라운드를 수행합니다. 한 라운드(마지막 제외)는 4×4 바이트 상태에 대해 4가지 연산을 수행합니다: SubBytes는 고정된 16×16 S-Box를 적용합니다(0x63 = 01100011은 행 6열 3에 위치 — S-Box는 GF(2^8)에서의 곱셈 역원에 아핀 변환을 더해 대수 구조를 파괴하는 방식으로 구성됩니다); ShiftRows는 행 0을 0, 행 1을 1, 행 2를 2, 행 3을 3바이트씩 회전합니다; MixColumns는 각 열을 GF(2^8) 위의 고정 순환 MDS 행렬(행렬 형태의 다항식 0x03 * x)로 곱합니다; AddRoundKey는 라운드 서브키와 XOR합니다. 마지막 라운드에서는 MixColumns를 건너뜁니다. 라운드 키는 Rijndael 키 스케줄에서 생성됩니다: 128비트 라운드 키 11/13/15개를 RotWord(1바이트 좌측 회전), SubWord(S-Box 적용), GF(2^8) 위에서의 Rcon[i] = [0x01, 0x02, 0x04, ..., 0x80, 0x1b, 0x36] ×2^(i-1) XOR으로 생성합니다. 이 페이지의 aes-js 라이브러리는 4단계를 모두 순수 JavaScript로 수행하며 OpenSSL의 libcrypto와 바이트 수준으로 호환됩니다. 5가지 블록 모드를 지원합니다. ECB는 16바이트 블록을 독립적으로 암호화합니다: 동일한 평문 블록이 동일한 암호문 블록을 생성하여 구조가 누출됩니다(유명한 ECB 펭귄 이미지가 암호화 후에도 픽셀 패턴이 유지되어 윤곽이 살아남습니다). CBC는 각 평문 블록을 암호화 전에 이전 암호문 블록과 XOR하며, 첫 번째 블록은 IV와 XOR합니다. CTR은 AES를 스트림 암호로 변환합니다 — 증가하는 카운터(nonce || counter, 128비트 블록의 각 64비트 절반)를 암호화하고 키스트림을 평문과 XOR하여 임의 접근과 병렬 암호화를 지원합니다. GCM은 CTR에 GHASH(GF(2^128) 위의 유니버설 해시 인증자)를 더한 것으로, 16바이트 인증 태그를 암호문 뒤에 붙입니다. GCM은 TLS 1.3(RFC 8446)과 대부분의 최신 API(Node crypto.createCipheriv('aes-256-gcm', ...))에서 기본 AEAD입니다. CFB와 OFB는 호환성을 위해 유지되는 구형 스트림 암호 모드입니다. IV 함정은 프로덕션에서 가장 흔한 버그입니다. 96비트(12바이트) IV를 사용하는 GCM은 NIST 권장 구성(RFC 5288, NIST SP 800-38D §5.2.1.1)입니다: 12바이트 IV는 카운터로 취급되며 GHASH는 J0 = IV || 0x00000001에 대해 계산됩니다. CTR 모드에서 같은 키로 IV를 재사용하면 평문 XOR이 유출됩니다(C1 XOR C2 = P1 XOR P2 — 단일 선택 평문 공격으로 두 메시지 모두 복구 가능). GCM에서 IV를 재사용하면 더 심각합니다: 공격자가 인증 서브키 H를 복구하여 임의 메시지의 태그를 위조할 수 있습니다(이 공격은 Joux 2006에서 제시되었으며, NIST가 무작위 96비트 IV를 엄격한 고유성 없이 사용하는 것을 금지한 이유입니다). 이 페이지는 GCM에 대해 crypto.getRandomValues(new Uint8Array(12))로 12바이트 IV를, CBC/CFB/OFB에 대해 16바이트 IV를 생성하며, 무작위 키 버튼도 동일한 CSPRNG를 사용하므로 매번 암호화할 때마다 새로운 자료로 시작합니다. 이 도구는 AES 암호화·복호화를 모두 브라우저 내에서 aes-js(순수 JavaScript AES 구현)로 수행합니다. Web Crypto / SubtleCrypto 대체 경로는 없으며, 페이로드 크기와 무관하게 모든 연산이 aes-js를 통해 처리됩니다.

• AES는 FIPS 197(2001)로, 15개 후보가 참가한 NIST 공개 대회에서 선정되었습니다. Rijndael이 Twofish, Serpent, RC6, Mars를 제쳤습니다. 블록 크기는 항상 128비트이며, 키 크기 128/192/256비트는 각각 10/12/14라운드를 수행합니다. 이 페이지는 aes-js의 AES_128, AES_192, AES_256 생성자를 통해 세 가지를 모두 지원합니다.
• 4단계 라운드 함수: SubBytes(GF(2^8) 역원에 아핀 변환을 더한 256바이트 S-Box), ShiftRows(행을 0/1/2/3바이트씩 이동), MixColumns(GF(2^8) 위의 0x03 다항식을 사용한 MDS 행렬 곱셈), AddRoundKey(라운드 키와 XOR). 마지막 라운드에서는 MixColumns를 건너뜁니다. 같은 알고리즘, 같은 키 = 같은 암호문 — AES는 결정론적입니다.
• ECB는 동일한 평문 블록이 동일한 암호문 블록을 생성하므로 안전하지 않습니다(유명한 'ECB 펭귄' 이미지가 윤곽을 유지합니다). CBC는 안전한 클래식 모드이고, CTR은 병렬성을 추가하며, GCM은 인증을 추가하여 TLS 1.3의 기본값입니다(RFC 8446). CFB와 OFB는 레거시 호환성을 위해 유지되는 스트림 암호 모드입니다.
• PKCS#7 패딩: 1바이트 부족 시 0x0f 15바이트 + 0x10 1바이트; 2바이트 부족 시 0x0e 14바이트 + 0x0f 2바이트 등. 마지막 바이트 값이 패딩 길이를 나타내므로 패딩 제거는 모호하지 않습니다. 스트림 모드(CTR/CFB/OFB/GCM)는 패딩을 완전히 생략합니다. ZeroPadding은 데이터가 0x00으로 끝나면 모호해지므로 사용하지 마세요.
• GCM은 AEAD입니다: 암호문에 16바이트 인증 태그가 붙으며, H = AES_K(0^128)를 사용하여 GF(2^128) 위의 GHASH로 계산됩니다. AAD(추가 인증 데이터)는 암호화하지 않고 헤더만 인증합니다. 96비트 IV(RFC 5288)는 카운터로 취급되며, 128비트 IV는 GHASH를 거쳐 J0를 유도합니다 — 동일한 보안, 약간 느림.
• IV 재사용은 치명적입니다. CTR IV 재사용은 P1 XOR P2를 유출합니다(two-time pad). GCM IV 재사용(Joux 2006)은 공격자가 H를 복구하여 태그를 위조할 수 있게 합니다. 이 페이지는 crypto.getRandomValues(CSPRNG)로 IV를 생성하며, 세션 내에서 재사용하지 않고, IV를 암호문 앞에 붙여 복호화 측이 별도 상태 없이도 복구할 수 있게 합니다.
• AES 키 생성: 이 도구의 무작위 키 버튼은 브라우저의 `crypto.getRandomValues`(CSPRNG)를 사용합니다. AES 라운드 연산은 순수 JavaScript 구현인 aes-js를 통해 수행되며, 동일한 키·IV·패딩 설정에서 OpenSSL libcrypto와 바이트 단위로 일치합니다.
• 사이드 채널 현실: 순수 JS AES는 상수 시간이 아닙니다(S-Box 배열 인덱싱이 타이밍을 누출). Web Crypto의 AES는 네이티브 코드에서 상수 시간으로 동작합니다. 고신뢰 워크로드(HSM, 서버 측 KDF)에는 네이티브 경로를 선호하세요. 브라우저 내 학습 도구로서는 aes-js가 적합합니다 — 입력이 이미 페이지 메모리에 있기 때문입니다. 마이그레이션 경로: 해시는 SHA-1 → SHA-256, 암호는 DES → AES, 모드는 ECB → GCM.