AES-256-GCM - 현대 대칭 암호화의 표준

AES란 무엇인가

AES(Advanced Encryption Standard)는 2001년 NIST가 공식 채택한 대칭키 암호화 알고리즘이다.

AES는 키 길이에 따라 세 가지 변형이 있다:

종류	키 길이	라운드 수
AES-128	128비트	10
AES-192	192비트	12
AES-256	256비트	14

AES-256은 $2^{256}$가지의 키 조합이 존재한다. 이 숫자는 우주에 존재하는 원자의 수($\approx 2^{266}$)와 비슷한 규모로, 현존하는 어떤 컴퓨터로도 brute-force가 불가능하다.

AES는 Block Cipher다

AES는 데이터를 128비트(16바이트) 단위의 블록으로 잘라서 암호화한다. 하지만 현실의 데이터는 16바이트보다 큰 경우가 대부분이다. 여러 블록을 어떤 방식으로 처리할 것인가를 정하는 것이 바로 운용 모드(Mode of Operation)이다.

GCM 모드 - 암호화 + 무결성을 한 번에

GCM(Galois/Counter Mode)은 AES의 운용 모드 중 하나다. 단순히 데이터를 암호화하는 것을 넘어, AEAD(Authenticated Encryption with Associated Data)를 제공한다.

AEAD가 제공하는 두 가지:

• 기밀성(Confidentiality): 키 없이는 내용을 읽을 수 없다
• 무결성(Integrity): 암호문이 중간에 변조되었는지 검증할 수 있다

GCM은 내부적으로 CTR(Counter) 모드로 암호화를 수행하면서, 동시에 Galois Field 연산으로 인증 태그(Authentication Tag)를 생성한다. 복호화 시 이 태그를 검증하여, 데이터가 한 비트라도 변조되었으면 복호화 자체를 거부한다.

다른 모드와의 비교

모드	기밀성	무결성	비고
ECB	O	X	블록마다 독립 암호화, 패턴 노출 위험
CBC	O	X	IV 필요, 무결성은 별도 구현 필요
CTR	O	X	카운터 기반, 병렬 처리 가능
GCM	O	O	CTR + Galois 인증, AEAD 지원

CBC 같은 모드는 암호화만 해주기 때문에, 무결성 검증이 필요하면 HMAC 등을 별도로 붙여야 한다. GCM은 이걸 한 번에 처리하므로 구현이 간결하고 실수할 여지가 적다.

IV(Initialization Vector)의 역할

AES-GCM을 처음 접할 때 가장 헷갈리는 부분이 IV다. 암호화할 때마다 랜덤한 IV를 생성해야 하는데, 그러면 복호화할 때는 어떻게 하는 걸까?

IV가 필요한 이유

만약 IV 없이 같은 키로 같은 데이터를 암호화하면, 매번 동일한 암호문이 나온다. 이건 치명적이다:

• "Yes"를 100번 암호화하면 100개의 동일한 암호문이 생긴다
• 공격자는 암호문의 패턴만으로 원본을 추측할 수 있다
• 레인보우 테이블 공격이나 패턴 분석에 취약해진다

IV를 매번 다르게 하면, 동일한 평문이라도 완전히 다른 암호문이 나온다. Key + IV 조합이 실질적인 암호화 파라미터인 셈이다.

IV는 비밀이 아니다

여기서 중요한 포인트 - IV는 공개해도 안전하다. 비유하자면:

• Key: 집을 여는 진짜 열쇠 (절대 공개 금지)
• IV: 열쇠를 꽂기 전에 돌리는 다이얼 번호 (공개되어도 열쇠 없이는 의미 없음)

그래서 실무에서 IV는 암호문과 함께 대놓고 저장하거나 전송한다:

• 방법 1 - 암호문 앞에 붙이기: [IV (12바이트)] + [암호문] 형태로 하나의 데이터 덩어리를 만든다. 가장 일반적인 방식이다.
• 방법 2 - 별도 필드: DB에 ciphertext 컬럼과 iv 컬럼을 따로 둔다.

복호화하는 쪽은 앞 12바이트를 잘라내서 IV로 쓰고, 나머지를 암호문으로 처리한다.

암호화: Key + Random IV + 평문 → [IV | 암호문 | Auth Tag]
복호화: Key + IV(앞 12바이트 추출) + 암호문 → 평문

IV 충돌과 Birthday Paradox

그러면 IV를 매번 랜덤 생성하면 우연히 같은 값이 나올 수도 있지 않을까? GCM 표준 IV는 96비트(12바이트)인데, UUID(128비트)처럼 사실상 충돌이 없다고 봐도 될까?

결론부터 말하면 - 일반적인 규모에서는 안전하지만, 대규모 시스템이라면 무시할 수 없다.

생일 역설 (Birthday Paradox)

$2^{96}$이라는 숫자는 크지만, 암호학에서는 생일 역설을 고려해야 한다. 이는 “전체 경우의 수의 제곱근 정도만 모여도 충돌 확률이 급격히 올라간다”는 법칙이다.

비교 대상	전체 공간	충돌 확률 50% 도달 시점
96비트 IV	$2^{96}$	$\approx 2^{48}$번
128비트 랜덤 값	$2^{128}$	$\approx 2^{64}$번

UUID가 IV보다 약 $2^{32}$(43억) 배 더 넓은 공간을 가진다.

NIST의 가이드라인

NIST SP 800-38D는 명확하게 제한을 두고 있다:

NIST SP 800-38D

하나의 동일한 키로 무작위 96비트 IV를 사용할 경우, 암호화 횟수는 $2^{32}$(약 42억 번)를 넘지 않아야 한다.

$2^{32}$번이면 꽤 많아 보이지만, 초당 수만 건의 트래픽이 발생하는 대규모 백엔드나 수년간 쌓이는 로그 데이터를 생각하면 도달 불가능한 수치가 아니다.

Nonce Reuse의 재앙 - Forbidden Attack

다른 모드에서 IV가 충돌하면 해당 블록의 데이터가 노출될 가능성이 생기는 정도다. 하지만 GCM에서의 IV 충돌(Nonce Reuse)은 차원이 다른 재앙을 초래한다.

동일한 Key와 IV 조합이 두 번 사용되면:

1. 인증 키(H-Key) 노출: 수학적으로 인증 태그를 생성하는 내부 키를 역산할 수 있다
2. 무결성 완전 파괴: 공격자가 암호문을 마음대로 수정해도 복호화 과정에서 “정상”으로 판정된다
3. 평문 XOR 노출: 두 암호문의 XOR로 두 평문의 XOR이 드러나, 평문 복원 가능성이 생긴다

이를 암호학계에서는 Forbidden Attack이라 부른다. GCM의 강점인 인증 기능이 완전히 무력화되는 것이다.

GCM에서 Nonce Reuse는 단순 데이터 유출이 아니라, 암호 시스템 자체의 붕괴다.

실무 대응 전략

Forbidden Attack의 위험성 때문에, 실무에서는 IV 충돌을 원천적으로 방지하는 전략을 사용한다.

카운터 기반 IV (Deterministic IV)

랜덤 대신 0, 1, 2, ... 처럼 순차적으로 증가하는 카운터를 IV로 사용한다. 충돌이 구조적으로 불가능하므로 키 하나당 $2^{96}$번까지 안전하게 사용할 수 있다. NIST가 가장 권장하는 방식이다.

Key Rotation

암호화 횟수가 일정 수준($2^{32}$ 등)에 도달하면 키 자체를 교체한다. 랜덤 IV를 쓰더라도 키가 바뀌면 IV 공간이 리셋되므로, 충돌 확률이 다시 0에서 시작한다.

규모별 판단 기준

시스템 규모	랜덤 IV 사용	권장 전략
로컬 앱, 소규모 서비스	안전	랜덤 IV로 충분
중규모 백엔드	주의	Key Rotation 병행
대규모 트래픽, 금융/인프라	위험	카운터 IV 또는 적극적 Key Rotation

보안 수준 정리

AES-256-GCM은 현재 사실상의 표준(de facto standard) 대칭 암호화 알고리즘이다.

표준 채택 현황:

• TLS 1.3의 기본 cipher suite (TLS_AES_256_GCM_SHA384)
• IPsec, SSH, WPA3 등 주요 보안 프로토콜에서 사용
• AWS, GCP 등 클라우드 서비스의 기본 암호화 방식

Brute-force 내성:

• $2^{256}$가지 키 조합 - 현존 기술로 돌파 불가능
• 양자 컴퓨터의 Grover 알고리즘을 적용해도 유효 보안 강도가 $2^{128}$로, 여전히 안전한 수준

올바르게 구현했을 때:

• 기밀성과 무결성을 동시에 보장
• 하드웨어 가속(AES-NI) 지원으로 성능 부담 최소
• 알고리즘 자체의 취약점은 현재까지 발견되지 않음

핵심 정리

AES-256-GCM은 알고리즘 자체는 완벽에 가깝다. 실무에서의 보안 사고는 대부분 구현 실수 - 특히 IV 재사용, 키 관리 부실, 인증 태그 미검증 - 에서 발생한다. “좋은 알고리즘을 고르는 것”보다 “올바르게 사용하는 것”이 더 중요하다.