088. 블록 암호 운영 모드 (Block Cipher Modes of Operation)

⚠️ 이 문서는 AES나 DES 같은 블록 암호 알고리즘이 평문을 128비트의 네모난 블록으로 자른 뒤, 이 수많은 블록들을 어떤 순서와 조합으로 엮어서 최종 암호문을 만들어낼 것인지를 결정하는 5가지 운영 모드를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: AES 알고리즘 자체는 딱 '128비트짜리 네모난 데이터 1개'만 섞어주는 고기 분쇄기에 불과하다. 수백 메가바이트(MB)의 영화 파일을 암호화하려면, 고기를 잘라서 분쇄기에 **어떤 순서로 연속해서 집어넣을지 결정하는 조립 라인의 설계도(Mode)**가 반드시 필요하다.
  2. 가치: 아무리 강력한 AES-256을 쓰더라도 운영 모드를 가장 단순한 ECB로 설정하면 원본 데이터의 윤곽(패턴)이 그대로 암호문에 노출되어 해킹당한다. 운영 모드는 알고리즘 자체보다 보안성에 더 치명적인 영향을 미친다.
  3. 융합: 블록을 서로 쇠사슬처럼 묶어서 패턴을 지우는 CBC 모드가 전통적으로 쓰였으나, 병렬 처리가 불가능해 속도가 느렸다. 현대에는 1, 2, 3 번호표(카운터)를 붙여서 수천 개의 블록을 한 방에 암호화하는 CTR 모드나 GCM 모드로 완전히 진화하였다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

AES-128의 메뉴얼을 보면 "128비트(16바이트) 평문을 넣으면 128비트 암호문이 나온다"라고 적혀 있다. 문제는 내가 암호화하고 싶은 파일이 16바이트짜리 문자열이 아니라, 10기가바이트(GB)짜리 거대한 동영상 파일일 때 발생한다.

수많은 암호 초보 개발자들은 10GB짜리 파일을 16바이트씩 깍둑썰기로 수억 개의 네모난 블록으로 자른 뒤, 첫 번째 블록을 AES 믹서기에 넣고, 두 번째 블록을 또 넣고 돌리는 식의 가장 멍청한 코딩을 한다. 이것이 바로 ECB (Electronic Codebook) 모드다. 이렇게 자른 블록들을 독립적으로 암호화하면, 똑같은 내용이 담긴 원본 블록은 무조건 똑같이 생긴 쓰레기 블록으로 튀어나온다. (패턴 노출)

이 치명적 문제를 해결하기 위해, 학자들은 자른 블록들을 쇠사슬처럼 엮거나 무작위 난수를 섞어주는 **5가지 운영 모드(Mode of Operation)**를 발명했다.

📢 섹션 요약 비유: AES가 네모난 햄버거 패티를 구워내는 '가스레인지'라면, 운영 모드는 이 수백 개의 패티들을 층층이 쌓을지, 옆으로 펼칠지, 아니면 소스를 바르고 쌓을지를 결정하는 '포장 기계의 설계도'입니다.

Ⅱ. 5대 블록 암호 운영 모드 심층 해부

1. ECB (Electronic Codebook) - 전자 코드북 모드

  • 원리: 평문 블록을 각각 독립적으로 암호화한다.
  • 치명적 단점: 평문 블록 1번과 3번이 AAAA로 내용이 같다면, 암호문 1번과 3번도 똑같이 Z@&%로 나온다. 리눅스 마스코트 펭귄(Tux) 그림을 ECB로 암호화하면, 색깔은 깨지지만 펭귄의 둥근 윤곽선은 암호문 사진에 고스란히 남는다. (Pattern Leakage)
  • 실무 판정: 절대 사용 금지. (단, 아주 짧은 16바이트짜리 PIN 번호 하나만 암호화할 땐 쓸 수 있다.)

2. CBC (Cipher Block Chaining) - 암호 블록 연쇄 모드 [상세 내용은 089 문서 참조]

  • 원리: 2번 평문 블록을 암호화하기 전에, 1번에서 막 튀어나온 1번 암호문 블록을 가져와 평문과 비벼버린(XOR) 뒤에 AES 믹서기에 넣는다. 블록들을 쇠사슬(Chain)처럼 엮어버린다.
  • 장점: 똑같은 평문이 들어와도 이전 블록의 영향을 받아 완전히 다른 암호문이 나온다. 펭귄 윤곽선이 완벽히 사라진다.
  • 단점: 1번 믹서기가 끝나야 2번 믹서기를 돌릴 수 있으므로(직렬 병목), 다중 코어 CPU에서 속도를 낼 수가 없다.

3. CFB (Cipher Feedback) - 암호 피드백 모드

  • 원리: 블록 암호를 마치 **스트림 암호(1비트씩 암호화)**처럼 쓰게 만들어주는 마법. 평문을 믹서기에 넣는 게 아니라, 이전 암호문을 믹서기에 넣고 갈아서 나온 즙을 현재 평문과 엑스오어(XOR)하여 현재 암호문을 만든다.
  • 특징: 통신 중에 1비트만 사라져도 에러가 폭풍처럼 번져 전체가 망가지는 특성(동기화 오류)이 있어 잘 안 쓰인다.

4. OFB (Output Feedback) - 출력 피드백 모드

  • 원리: CFB와 비슷하지만, 암호문을 다음 믹서기에 넣는 게 아니라 믹서기에서 나온 순수한 '즙(난수)' 자체를 계속 믹서기에 뱅글뱅글 돌려 거대한 난수표를 쫙 뽑아낸다. 나중에 평문은 그 난수표에 엑스오어만 한다.
  • 장점: 통신 중에 암호문 1비트가 깨져도 딱 그 1비트만 깨지고 복호화가 되므로 에러가 번지지 않는다. 영상 스트리밍(음성, 비디오)에 적합했다.

5. CTR (Counter) - 카운터 모드 [상세 내용은 090 문서 참조]

  • 원리: 1번, 2번, 3번이라는 일련번호(Counter)에 암호키를 섞어 믹서기에 돌려 거대한 난수(Keystream)를 만든다.
  • 장점 (현대 암호의 왕): 블록끼리 사슬처럼 묶여있지 않고(No Chaining), 1번을 암호화할 때 100번 블록을 동시에 암호화할 수 있다. CPU 코어 8개를 모두 갈궈서 **병렬 처리(초고속)**가 가능하다. 오늘날 TLS 1.3의 절대 표준 모드다.
┌──────────────────────────────────────────────────────────────────────────────┐
│           최악의 모드(ECB)와 표준 모드(CBC)의 펭귄 그림 암호화 비교          │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│ [ 원본 평문 (펭귄 픽셀들) ]                                                  │
│   하양 하양 까망 까망                                                        │
│   하양 까망 까망 하양                                                        │
│                                                                              │
│ ❌ [ ECB 모드 암호화 결과 ] (독립적 처리)                                    │
│   '하양' -> 무조건 '초록' / '까망' -> 무조건 '빨강' 으로 변환 됨             │
│   초록 초록 빨강 빨강   (오! 색깔은 깨졌지만...)                             │
│   초록 빨강 빨강 초록   (앗! 멀리서 보니 펭귄 모양 윤곽이 그대로 보임!)      │
│   * 결론: 패턴 노출로 완벽한 해킹 대상.                                      │
│                                                                              │
│ 🛡️ [ CBC 모드 암호화 결과 ] (쇠사슬로 엮음)                                  │
│   1번 '하양' -> '초록'으로 변환                                              │
│   2번 '하양'을 암호화할 때 1번의 '초록' 찌꺼기를 섞어버림 -> '파랑' 나옴     │
│   파랑 노랑 보라 회색   (색깔도 다르고 규칙도 없음!)                         │
│   주황 검정 핑크 연두   (원래 모양이 아예 박살 나서 TV 노이즈 화면처럼 됨!)  │
│   * 결론: 혼돈과 확산의 극대화. 안전함.                                      │
└──────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 암호학 교과서에 영원히 박제된 가장 유명한 예시인 '리눅스 턱스(Tux) 펭귄 암호화' 원리다. 암호화를 한다는 것은 정보의 엔트로피(무질서도)를 극한으로 끌어올려 지지직거리는 TV 노이즈 화면처럼 만드는 것이다. ECB는 무질서도를 만들지 못해 실패했고, 나머지 모드들(CBC, CTR 등)은 이전 데이터의 찌꺼기나 카운터 난수를 버무려 완벽한 무질서를 창조해 낸다.

  • 📢 섹션 요약 비유: 편지를 조각내서 보낼 때, "사과"라는 단어가 나올 때마다 똑같이 "바나나"로 번역하는 게 ECB입니다. 도둑이 "이 문서에는 바나나가 엄청 많네? 이건 사과에 대한 이야기군!" 하고 눈치챕니다. 하지만 CBC는 첫 번째 "사과"는 "바나나"로, 두 번째 "사과"는 "포도"로, 세 번째는 "딸기"로 번역기를 계속 바꿔버려서 도둑의 정신을 빼놓습니다.

Ⅲ. 초기화 벡터 (IV, Initialization Vector)의 필수성

ECB를 제외한 모든 모드(CBC, CFB, OFB, CTR)는 암호화를 시작할 때 맨 처음 믹서기에 넣어줄 **랜덤한 난수 조각(IV 또는 Nonce)**이 무조건 하나 필요하다. (상세 내용은 차후 문서들에서 다룸)

  • IV의 존재 이유: 똑같은 내용의 파일(예: 안녕하세요.txt)을 어제 암호화하고 오늘 또 암호화했을 때, 똑같은 암호문이 나오면 안 된다. 파일 내용은 같지만 어제는 IV로 123을 넣고 오늘은 999를 넣고 돌리기 시작하면, 쇠사슬 효과에 의해 최종 암호문은 어제와 오늘 완전히 다른 쓰레기 문자로 튀어나온다. (재전송 공격 방어)
  • 보안 수칙: IV는 비밀키가 아니므로 해커에게 평문으로 노출되어도 상관없다. 하지만 절대, 똑같은 키에 똑같은 IV를 두 번 재사용(Reuse)해서는 안 된다. 만약 재사용하면 암호문끼리 XOR 하여 평문이 까발려지는 대참사가 발생한다.

Ⅳ. 결론

"칼이 아무리 날카로워도, 검술이 엉망이면 전쟁에서 진다." AES 알고리즘이 천재가 벼려낸 날카로운 칼(Sword)이라면, 운영 모드는 그 칼을 휘두르는 검술(Swordsmanship)이다. 초보 개발자가 "AES-256을 썼으니 우리 회사는 안전하다"라고 큰소리치더라도, 그 옆에 ECB 모드를 선언해 놓았다면 그 회사의 시스템은 단 하루 만에 해커의 놀이터로 전락할 것이다. 현대 실무에서는 병렬 처리가 안 되는 CBC를 버리고, 초고속 병렬 암호화의 황제인 CTR(카운터) 모드와 여기에 인증까지 얹은 GCM 모드로 대통합을 이룬 상태다.

📌 관련 개념 맵

  • 사용하는 엔진 (알고리즘): AES, DES, ARIA 등 모든 블록 암호
  • 최악의 안티패턴: ECB (Electronic Codebook)
  • 전통적인 안정성 모드: CBC (Cipher Block Chaining)
  • 현대 클라우드/웹 통신 표준: CTR (Counter) 모드 기반의 GCM

👶 어린이를 위한 3줄 비유 설명

  1. 거대한 돼지고기 덩어리를 소시지로 만들 때, 그냥 깍둑썰기로 잘라서 기계에 넣으면(ECB 모드) 원래 돼지의 모양이 살짝 보여서 들킬 수 있어요.
  2. 그래서 똑똑한 요리사는 1번 고기를 갈아 만든 국물을 2번 고기에 붓고, 2번 국물을 3번 고기에 부어가면서 줄줄이 사슬처럼 섞어버렸죠(CBC 모드).
  3. 이렇게 섞는 방법들(운영 모드)을 잘 선택해야만, 원래 돼지고기가 어떻게 생겼는지 도둑이 절대 눈치채지 못하는 완벽한 소시지(암호문)가 만들어진답니다!