HTTPS 연결, 스마트폰 저장소, Wi-Fi 비밀번호, 암호화 ZIP 파일——현대 암호화 시나리오의 핵심에는 모두 같은 알고리즘이 있습니다: AES(Advanced Encryption Standard). 2001년 NIST가 표준화한 이 대칭 암호화는 오늘날에도 깨지지 않은 실용적 암호화의 기반입니다. AES의 동작 방식과 올바른 사용법은 개발자와 보안 엔지니어에게 필수적인 지식입니다.
1. AES의 탄생
1997년 NIST는 DES(Data Encryption Standard)의 후계자를 찾는 공개 경쟁을 시작했습니다. DES의 56비트 키는 1999년 22시간 만에 무차별 대입으로 해독되어 더 이상 쓸 수 없었습니다. 5년간의 전 세계 암호학자 공개 검증을 거쳐, 2001년 NIST는 벨기에 암호학자 Joan Daemen과 Vincent Rijmen이 설계한 Rijndael 알고리즘을 선정해 AES(FIPS PUB 197)로 발표했습니다.
AES는 대칭 암호화: 암호화와 복호화에 같은 키를 사용합니다. RSA는 비대칭 암호화: 공개키로 암호화하고 개인키로 복호화합니다. HTTPS는 둘의 조합입니다——RSA/ECDH로 AES 세션 키를 안전하게 교환하고, 실제 데이터 전송은 AES로 처리합니다.
2. 키 길이
AES는 세 가지 키 길이를 지원합니다：
| 키 길이 | 라운드 수 | 보안 수준 | 주요 용도 |
|---|---|---|---|
| AES-128 | 10 | 128비트 | 일반 앱, TLS |
| AES-192 | 12 | 192비트 | 거의 사용 안 함 |
| AES-256 | 14 | 256비트 | 정부 기밀, 고보안 요구 사항 |
AES-128은 대부분의 응용 프로그램에 충분합니다——무차별 대입에는 2¹²⁸번의 시도가 필요해 현재 컴퓨팅 능력으로는 사실상 불가능합니다. AES-256은 양자 컴퓨터 대비(Grover 알고리즘으로 유효 키 길이가 절반으로 줄어, 256비트→128비트로 여전히 안전)와 규정 준수(미국 정부 TOP SECRET)에 사용됩니다.
3. AES 동작 원리
AES는 128비트(16바이트) 블록 단위로 데이터를 처리합니다. 키 길이에 따라 라운드 수가 결정되며, 각 라운드에서 4×4 바이트 상태 행렬에 네 가지 변환이 적용됩니다：
- SubBytes(바이트 치환): 각 바이트를 고정 S-Box로 치환해 비선형성 제공
- ShiftRows(행 이동): 각 행을 서로 다른 바이트 수만큼 순환 좌이동해 열 전체로 데이터 확산
- MixColumns(열 혼합): 각 열에 GF(2⁸) 곱셈을 적용해 바이트 간 의존성 생성(마지막 라운드 제외)
- AddRoundKey(라운드 키 추가): 현재 상태와 마스터 키에서 파생된 라운드 키를 XOR
4. 암호화 모드: 가장 중요한 선택
AES 자체는 단일 128비트 블록을 암호화하는 방법만 정의합니다. 임의 길이의 데이터에는 '암호화 모드'가 필요합니다. 이 선택이 키 길이보다 더 중요합니다.
4.1 ECB(전자 코드북 모드) — 절대 사용 금지
ECB는 각 블록을 독립적으로 암호화합니다. 치명적 약점: 동일한 평문 블록이 동일한 암호문 블록을 생성해 원본 데이터의 패턴이 보존됩니다.
ECB로 펭귄 이미지를 암호화해도 색상이 같은 픽셀 영역이 동일한 암호문을 생성하므로 암호화 후에도 펭귄 윤곽이 보입니다. ECB는 기밀성이 필요한 어떤 상황에서도 사용해서는 안 됩니다.
4.2 CBC(암호문 블록 체이닝 모드) — 레거시 표준
CBC는 각 평문 블록을 암호화 전에 이전 암호문 블록과 XOR하고, 첫 번째 블록에는 무작위 생성된 IV(초기화 벡터)를 사용합니다. 패딩이 필요하고 무결성 검증을 제공하지 않아 Padding Oracle 공격에 취약합니다.
4.3 GCM(갈루아/카운터 모드) — 현대 표준
GCM = CTR 암호화 + GHASH 인증. Authentication Tag(인증 태그)를 자동 생성해 변조를 감지합니다.
- AEAD(인증 암호화): 기밀성과 무결성을 한 번에 보장
- 패딩 불필요, 완전한 병렬 처리 가능
- TLS 1.3에서 AES-256-GCM이 주요 암호 스위트로 사용됨
| 모드 | 패딩 필요 | 무결성 검증 | 병렬 처리 | 권장도 |
|---|---|---|---|---|
| ECB | 필요 | 없음 | 가능 | ❌ 절대 사용 금지 |
| CBC | 필요 | 없음 | 복호화만 | ⚠️ 레거시 호환만 |
| CTR | 불필요 | 없음 | 가능 | ✅ MAC 병행 사용 가능 |
| GCM | 불필요 | ✅ 내장 | 가능 | ✅✅ 현대의 첫 번째 선택 |
5. IV와 Nonce: 절대 재사용 금지
- 매번 암호화할 때 서로 다른 IV/Nonce를 사용해야 합니다——재사용은 보안을 심각하게 약화시킵니다
- IV/Nonce는 기밀이 아니므로 암호문과 함께 평문으로 전송할 수 있습니다
- GCM Nonce 재사용은 치명적: 공격자가 인증 키를 복원해 전체 암호화 체계를 깨뜨릴 수 있습니다
6. 코드 예시
# PHP (OpenSSL, AES-256-GCM)
$key = random_bytes(32);
$nonce = random_bytes(12);
$ciphertext = openssl_encrypt(
$plaintext, 'aes-256-gcm', $key,
OPENSSL_RAW_DATA, $nonce, $tag
);
# Python (cryptography 라이브러리, AES-256-GCM)
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
key = os.urandom(32)
nonce = os.urandom(12)
aesgcm = AESGCM(key)
ciphertext = aesgcm.encrypt(nonce, plaintext, None)
# Node.js (내장 crypto, AES-256-GCM)
const crypto = require('crypto')
const key = crypto.randomBytes(32)
const nonce = crypto.randomBytes(12)
const cipher = crypto.createCipheriv('aes-256-gcm', key, nonce)
const encrypted = Buffer.concat([cipher.update(plaintext), cipher.final()])
const tag = cipher.getAuthTag()7. 요약
AES는 현대 암호학의 기반입니다: 20년 이상의 공개 검증에도 깨지지 않았습니다. 하지만 알고리즘 자체는 일부분에 불과합니다——올바른 사용이 실제 보안을 제공합니다. GCM 모드를 사용하고(ECB나 단독 CBC는 피함), 매번 무작위 Nonce를 생성하고, KDF로 키를 파생시키세요(비밀번호를 직접 사용하지 않음). 이 세 가지를 지키면 AES는 애플리케이션에 산업 수준의 암호화 보호를 제공합니다.