ECB·CBC·CTR·GCM 차이: 블록 암호 운영 모드 선택 기준

1장 블록 암호 운영 모드란 무엇인가#

AES 같은 블록 암호는 데이터를 일정한 크기의 블록 단위로 처리합니다.

하지만 실제 애플리케이션에서 다루는 데이터는 한 블록보다 훨씬 깁니다.

예를 들어 파일이나 JSON 데이터는 다음처럼 여러 블록으로 나뉠 수 있습니다.

Block 1
Block 2
Block 3
Block 4
...

이때 각 블록을 어떤 규칙으로 연결해 암호화할지를 정하는 것이 블록 암호 운영 모드입니다.

원문에서는 운영 모드를 고정 길이 블록 암호를 긴 메시지에 적용하는 규칙이라고 설명합니다. 같은 AES를 사용하더라도 ECB·CBC·CTR·GCM 중 어떤 모드를 선택하느냐에 따라 패턴 노출, 패딩, 변조 검증, Nonce 관리 조건이 달라집니다.

2장 같은 AES라도 모드가 다르면 전혀 다른 특성을 가진다#

다음 두 시스템이 있다고 하겠습니다.

시스템 A
AES-ECB

시스템 B
AES-GCM

둘 다 AES를 사용합니다.

하지만 안전성이나 운영 조건은 같지 않습니다.

flowchart TB
    AES[AES]

    ECB[ECB]
    CBC[CBC]
    CTR[CTR]
    GCM[GCM]

    AES --> ECB
    AES --> CBC
    AES --> CTR
    AES --> GCM

    ECB --> E1[패턴 노출]
    CBC --> C1[IV·패딩]
    CTR --> T1[Nonce·Counter]
    GCM --> G1[AEAD·Tag]

즉:

AES를 쓴다

라는 정보만으로는 실제 암호 설계를 평가할 수 없습니다.

3장 ECB란 무엇인가#

ECB는 블록을 각각 독립적으로 암호화하는 가장 단순한 형태의 운영 모드입니다.

개념적으로:

flowchart LR
    P1[평문 블록 1]
    P2[평문 블록 2]
    P3[평문 블록 3]

    E1[AES]
    E2[AES]
    E3[AES]

    C1[암호문 1]
    C2[암호문 2]
    C3[암호문 3]

    P1 --> E1 --> C1
    P2 --> E2 --> C2
    P3 --> E3 --> C3

각 블록이 서로 영향을 주지 않습니다.

구조는 단순하지만 중요한 문제가 있습니다.

4장 ECB의 가장 큰 문제는 반복 패턴이 드러난다는 것이다#

원문에서는 ECB를 다음과 같이 설명합니다.

같은 평문 블록은 같은 암호문 블록으로 바뀐다.

예를 들어 평문이:

AAAA
BBBB
AAAA
BBBB

와 같이 반복된다고 하겠습니다.

ECB에서는 같은 블록이 같은 암호문으로 변환되므로:

X1
X2
X1
X2

같은 반복 구조가 남을 수 있습니다.

flowchart LR
    A1[같은 평문 A]
    A2[같은 평문 A]

    E1[ECB]
    E2[ECB]

    C1[같은 암호문 X]
    C2[같은 암호문 X]

    A1 --> E1 --> C1
    A2 --> E2 --> C2

암호문 자체는 읽기 어렵지만 평문의 구조가 노출될 수 있다는 것이 문제입니다.

5장 ECB는 왜 이미지 예제로 자주 설명되는가#

ECB의 약점은 반복 패턴이 그대로 남는다는 데 있습니다.

이미지처럼 비슷한 데이터가 넓게 반복되는 경우 이런 특성이 더 쉽게 드러날 수 있습니다.

핵심은 특정 이미지 예제가 아니라 다음 원리입니다.

같은 평문 블록
↓
같은 암호문 블록
↓
데이터 구조 추정 가능

원문도 ECB의 주요 조건을 반복 패턴 노출로 정리합니다.

6장 ECB에서는 패딩도 필요하다#

블록 암호는 고정 크기 블록을 처리합니다.

입력 데이터가 블록 크기의 정확한 배수가 아니면 마지막 블록을 채워야 합니다.

이를 패딩이라고 합니다.

예를 들어 블록 크기가 개념적으로 16바이트인데 마지막 데이터가 11바이트라면:

11바이트 데이터
+
5바이트 패딩
=
16바이트

처럼 맞춥니다.

원문의 비교표에서도 ECB는 블록 길이에 맞추기 위해 패딩이 필요하다고 설명합니다.

7장 CBC란 무엇인가#

CBC는 각 평문 블록을 바로 암호화하지 않고 앞의 암호문 블록과 연결해 처리합니다.

첫 번째 블록에는 이전 암호문이 없기 때문에 IV가 필요합니다.

개념적으로:

flowchart LR
    IV[IV]
    P1[평문 1]
    X1[XOR]
    E1[AES]
    C1[암호문 1]

    P2[평문 2]
    X2[XOR]
    E2[AES]
    C2[암호문 2]

    IV --> X1
    P1 --> X1 --> E1 --> C1

    C1 --> X2
    P2 --> X2 --> E2 --> C2

각 블록이 앞 블록의 결과와 연결되기 때문에 ECB보다 반복 구조를 숨기기 쉽습니다.

8장 CBC의 IV는 왜 필요한가#

CBC에서 첫 번째 블록은 이전 암호문이 존재하지 않습니다.

그래서 초기값인 IV를 사용합니다.

원문에서는 CBC에 대해 예측 불가능한 IV가 필요하다고 설명합니다.

개념적으로:

첫 번째 평문
+
IV
↓
암호화

형태입니다.

같은 평문과 같은 키를 사용하더라도 적절한 IV를 사용하면 첫 암호문 블록이 항상 동일하게 나오지 않도록 할 수 있습니다.

9장 IV와 비밀키는 같은 것이 아니다#

IV는 암호 연산에 필요한 값이지만 일반적으로 비밀키와 같은 개념은 아닙니다.

중요한 것은 모드가 요구하는 조건을 만족하는 것입니다.

CBC에서는 원문 기준 예측 불가능한 IV가 중요한 조건입니다.

따라서:

IV
=
아무 값이나 사용

이라고 생각해서는 안 됩니다.

10장 CBC에서도 패딩이 필요하다#

CBC 역시 블록 단위로 처리하기 때문에 데이터 길이가 블록 크기에 맞지 않으면 패딩이 필요합니다.

원문의 비교표는 CBC에 대해 다음 두 조건을 강조합니다.

패딩 필요
예측 불가능한 IV 필요

문제는 여기에서 끝나지 않습니다.

패딩 처리 자체도 안전하게 구현해야 합니다.

11장 패딩 오류가 보안 문제로 이어질 수 있다#

복호화 과정에서 패딩이 올바르지 않으면 오류가 발생합니다.

이때 시스템이 오류 내용을 외부에 지나치게 자세하게 노출하면 공격자가 차이를 관찰할 수 있습니다.

원문에서도 CBC의 주요 조건으로 패딩 오류 보호를 함께 언급합니다.

즉 복호화 실패 시:

패딩 오류
MAC 오류
키 오류

같은 내부 원인을 공격자에게 그대로 구분해 노출하지 않는 설계가 중요할 수 있습니다.

12장 CBC는 암호화만으로 변조를 막아주지 않는다#

원문에서 매우 중요한 부분입니다.

CBC는 기밀성을 제공할 수 있지만:

별도의 인증 없이는 변조를 막지 못한다.

즉 암호문이 외부에서 변경되었는지를 CBC 암호화만으로 신뢰해서는 안 됩니다.

flowchart LR
    P[평문]
    ENC[CBC 암호화]
    C[암호문]
    A[공격자 변조]
    D[복호화]

    P --> ENC --> C
    C --> A --> D

암호화와 무결성 검증은 서로 다른 요구사항입니다.

13장 그래서 CBC에서는 별도의 메시지 인증이 필요할 수 있다#

원문의 비교표에서도 CBC의 메시지 인증은 별도 구성 필요로 표시됩니다.

즉:

CBC 암호화

만으로:

기밀성
+
무결성 인증

이 자동으로 완성되는 것은 아닙니다.

기존 프로토콜에서는 별도의 인증 메커니즘과 결합해 사용할 수 있지만 구현 조건이 복잡해질 수 있습니다.

14장 CTR이란 무엇인가#

CTR은 블록 암호를 이용해 키스트림을 생성하고 평문과 결합하는 방식입니다.

원문에서는 CTR을 다음처럼 설명합니다.

카운터를 암호화한 키스트림을 사용한다.

개념적으로:

flowchart LR
    CTR[Counter]
    AES[AES]
    KS[Key Stream]
    P[Plaintext]
    X[XOR]
    C[Ciphertext]

    CTR --> AES --> KS
    KS --> X
    P --> X --> C

블록 암호를 사용하지만 실제 처리 특성은 스트림 암호와 비슷하게 보일 수 있습니다.

15장 CTR에서는 패딩이 필요 없다#

원문의 비교표에서는 CTR의 패딩을 불필요로 설명합니다.

키스트림과 필요한 길이만큼 데이터를 결합할 수 있기 때문입니다.

즉 CBC처럼 마지막 블록을 정확히 맞추기 위해 별도의 패딩을 넣지 않아도 됩니다.

16장 CTR의 핵심은 카운터 입력 재사용 금지다#

CTR에서 가장 중요한 조건 중 하나입니다.

원문은 다음과 같이 설명합니다.

동일 키 아래 카운터 입력을 재사용하면 안 된다.

왜 중요한지 개념적으로 보면:

같은 Key
+
같은 Counter 입력
↓
같은 Key Stream

이 생성될 수 있기 때문입니다.

키스트림을 재사용하면 암호문 사이의 관계가 노출될 위험이 커집니다.

17장 CTR에서 키스트림 재사용이 위험한 이유#

두 메시지가 같은 키스트림을 사용한다고 가정하겠습니다.

C1 = P1 XOR K
C2 = P2 XOR K

두 암호문을 서로 XOR하면:

C1 XOR C2
=
P1 XOR P2

가 됩니다.

키스트림 K가 사라집니다.

flowchart TB
    P1[Plaintext 1]
    P2[Plaintext 2]
    K[Same Key Stream]

    C1[Ciphertext 1]
    C2[Ciphertext 2]

    P1 --> C1
    K --> C1

    P2 --> C2
    K --> C2

    C1 --> X[XOR]
    C2 --> X

    X --> R[P1 XOR P2 관계 노출]

그래서 CTR의 입력 재사용 조건은 매우 중요합니다.

18장 CTR 역시 메시지 인증을 제공하지 않는다#

CTR은 암호화 기능을 제공하지만 원문의 비교표에서는 메시지 인증을 별도 구성 필요로 설명합니다.

즉:

CTR
=
기밀성만으로 충분

하다고 생각해서는 안 됩니다.

변조 탐지까지 필요하다면 별도의 인증 구조가 필요합니다.

19장 CTR은 임의 접근에 유리할 수 있다#

CTR의 특성상 특정 위치의 카운터 값을 계산할 수 있다면 앞부분 전체를 순차적으로 처리하지 않고 원하는 위치를 처리할 수 있습니다.

이 때문에 특정 용도에서는 편리할 수 있습니다.

하지만 원문은 중요한 경고를 합니다.

CTR의 임의 접근 특성만 보고 디스크 보안 방식으로 바로 선택하면 안 된다.

디스크 암호화는 별도의 위협 모델과 전용 설계가 필요합니다.

20장 디스크 암호화에는 별도 표준을 검토한다#

원문에서는 디스크 섹터 암호화처럼 별도의 위협 모델이 필요한 경우 XTS 등 해당 분야의 표준을 검토하도록 설명합니다.

즉:

CTR이 빠르다
+
임의 접근 가능
=
디스크 암호화에 바로 사용

이라는 판단은 위험합니다.

용도별로 맞는 암호 설계를 선택해야 합니다.

21장 GCM이란 무엇인가#

GCM은 암호화와 인증을 결합하는 AEAD 방식입니다.

원문에서는 GCM을:

암호화와 인증을 결합한다.

고 설명합니다.

즉 암호화뿐 아니라 데이터가 변조되지 않았는지 검증할 수 있는 인증 태그를 함께 제공합니다.

22장 GCM의 기본 구조#

개념적으로 다음과 같이 볼 수 있습니다.

flowchart LR
    P[평문]
    N[Nonce]
    E[GCM]
    C[암호문]
    T[인증 태그]

    P --> E
    N --> E

    E --> C
    E --> T

복호화 시에는 암호문만 복호화하는 것이 아니라 태그 검증도 수행합니다.

23장 GCM에서는 패딩이 필요 없다#

원문의 비교표에 따르면 GCM은 패딩이 필요하지 않습니다.

이 점은 CBC와 비교할 때 운영상 중요한 차이입니다.

CBC
→ 패딩 필요

CTR
→ 패딩 불필요

GCM
→ 패딩 불필요

24장 GCM의 핵심은 인증 태그다#

GCM의 큰 장점은 암호화와 함께 인증 태그를 제공한다는 점입니다.

복호화 과정에서는:

Ciphertext
+
Nonce
+
Tag

를 사용해 데이터의 유효성을 확인합니다.

flowchart LR
    C[암호문]
    N[Nonce]
    T[Tag]

    V[검증·복호화]

    C --> V
    N --> V
    T --> V

    V -->|정상| P[평문]
    V -->|실패| X[폐기]

태그가 올바르지 않다면 복호화 결과를 신뢰해서는 안 됩니다.

25장 태그 검증을 빼먹으면 GCM을 제대로 사용하는 것이 아니다#

원문의 비교표는 GCM의 주요 조건으로 태그 검증을 명확히 제시합니다.

다음처럼 구현하면 문제가 됩니다.

복호화 수행
↓
태그 오류 무시
↓
평문 사용

올바른 흐름은:

복호화·인증 수행
↓
태그 검증 성공
↓
평문 사용

입니다.

26장 GCM에서도 Nonce 재사용은 매우 중요하다#

GCM은 안전한 AEAD 방식이지만 아무 조건 없이 안전한 것은 아닙니다.

원문의 비교표는 다음을 명확히 합니다.

키별 Nonce 재사용 금지
+
태그 검증

즉:

AES-GCM 사용

이라는 사실만으로 안전성이 보장되지 않습니다.

27장 같은 키와 같은 Nonce를 재사용하면 안 된다#

개념적으로:

같은 Key
+
같은 Nonce

조합이 반복되지 않도록 관리해야 합니다.

flowchart TB
    K[Key]
    N1[Nonce 1]
    N2[Nonce 2]

    M1[Message 1]
    M2[Message 2]

    G1[GCM]
    G2[GCM]

    K --> G1
    N1 --> G1
    M1 --> G1

    K --> G2
    N2 --> G2
    M2 --> G2

Nonce 관리 실패는 긴 키를 사용하는 것으로 해결되지 않습니다.

28장 ECB·CBC·CTR·GCM 비교#

원문의 비교 기준을 그대로 확장하면 다음과 같습니다.

모드 패딩 메시지 인증 핵심 주의점
ECB 필요 없음 반복 패턴 노출
CBC 필요 별도 필요 예측 불가능한 IV·패딩 처리
CTR 불필요 별도 필요 키별 카운터 입력 재사용 금지
GCM 불필요 태그 제공 키별 Nonce 재사용 금지·태그 검증

이 표만으로도 네 모드의 성격 차이를 상당 부분 이해할 수 있습니다.

29장 네 모드의 흐름을 한 번에 비교하면#

flowchart TB
    MODE[블록 암호 운영 모드]

    ECB[ECB]
    CBC[CBC]
    CTR[CTR]
    GCM[GCM]

    MODE --> ECB
    MODE --> CBC
    MODE --> CTR
    MODE --> GCM

    ECB --> E1[독립 블록]
    CBC --> C1[앞 블록 연결]
    CTR --> T1[Counter 기반 Key Stream]
    GCM --> G1[암호화 + 인증]

구조만 봐도 각 모드의 목적과 운영 조건이 다르다는 것을 알 수 있습니다.

30장 새 애플리케이션에서는 무엇을 선택해야 할까#

원문은 새 애플리케이션의 데이터 암호화에서는 라이브러리가 지원하는 AEAD를 우선 검토하라고 설명합니다.

그 이유는 암호화와 변조 검증을 따로 조립하는 것보다 실수할 여지를 줄일 수 있기 때문입니다.

즉 신규 설계에서:

암호화 알고리즘
+
별도 MAC
+
패딩
+
오류 처리

를 직접 조합하기보다 검증된 AEAD API를 우선 검토하는 방향입니다.

31장 AEAD란 무엇인가#

AEAD는 기밀성과 인증을 함께 제공하는 암호 사용 방식입니다.

간단히:

암호화
+
무결성·인증

을 함께 처리합니다.

flowchart LR
    P[Plaintext]
    AEAD[AEAD]
    C[Ciphertext]
    TAG[Authentication Tag]

    P --> AEAD
    AEAD --> C
    AEAD --> TAG

원문에서는 GCM을 대표적인 AEAD 방식으로 설명합니다.

32장 CBC가 무조건 사용할 수 없는 모드인 것은 아니다#

원문의 FAQ는 이 부분을 정확하게 구분합니다.

CBC 자체를:

무조건 안전하지 않다

라고 단정하지 않습니다.

원문에서는 인증과 IV·패딩 처리를 올바르게 결합한 프로토콜은 사용할 수 있다고 설명합니다.

문제는 올바른 구현 조건이 복잡하다는 점입니다.

33장 신규 설계에서 AEAD를 선호하는 이유#

CBC를 안전하게 사용하려면 여러 조건을 정확하게 처리해야 합니다.

IV
패딩
메시지 인증
오류 처리

반면 검증된 AEAD API를 사용하면 암호화와 인증을 하나의 사용 패턴으로 묶을 수 있습니다.

원문에서는 새로운 설계에서 AEAD API를 선택하면 실수할 여지를 줄일 수 있다고 설명합니다.

34장 IV와 Nonce를 같은 말처럼 사용하면 안 된다#

암호 모드를 공부하다 보면 다음 용어가 자주 나옵니다.

IV
Nonce
Counter

서로 비슷한 용도로 보이지만 각 모드에서 요구하는 조건이 다를 수 있습니다.

원문의 적용 전 확인사항에서도:

모드마다 요구되는 IV·Nonce 조건을 구분하라.

고 강조합니다.

즉 용어 이름보다 해당 모드가 요구하는 정확한 조건이 중요합니다.

35장 CBC와 GCM의 값 관리 차이#

원문 기준으로 단순화하면:

CBC#

예측 불가능한 IV

가 중요합니다.

GCM#

동일 키 아래 Nonce 재사용 금지

가 핵심입니다.

즉:

CBC에서 사용한 IV 관리 규칙
=
GCM Nonce 규칙

이라고 그대로 옮겨 생각해서는 안 됩니다.

36장 복호화 실패 시 부분 평문을 외부에 전달하면 안 된다#

원문은 적용 전 확인사항에서 다음을 명시합니다.

복호화 실패 시 부분 평문을 외부에 전달하지 않는다.

왜 중요할까요?

복호화와 인증이 완전히 성공하기 전에 일부 데이터를 사용하거나 반환하면 공격자가 변조된 입력을 통해 예상하지 못한 동작을 유도할 수 있습니다.

37장 안전한 복호화 흐름#

개념적으로 다음과 같은 구조가 좋습니다.

flowchart TB
    C[암호문]
    D[복호화·검증]
    V{검증 성공?}

    OK[전체 평문 사용]
    FAIL[평문 폐기]

    C --> D --> V

    V -->|Yes| OK
    V -->|No| FAIL

중요한 것은:

일단 일부 복호화
→ 애플리케이션에 전달
→ 나중에 오류 확인

같은 흐름을 피하는 것입니다.

38장 기밀성만 필요한지 변조 탐지도 필요한지 먼저 확인한다#

원문의 첫 번째 적용 전 확인사항입니다.

기밀성만 필요한가?

변조 탐지도 필요한가?

현실적인 애플리케이션에서는 암호문을 공격자가 변경할 가능성까지 고려해야 하는 경우가 많습니다.

따라서 신규 설계에서는 기밀성과 무결성·인증을 함께 제공하는 구조를 우선 검토할 수 있습니다.

39장 암호화했다고 변조 공격이 사라지는 것은 아니다#

예를 들어 중요한 금액 정보가 암호화되어 있다고 하겠습니다.

공격자가 내용을 읽지는 못하더라도 암호문을 임의로 변경할 수 있다면:

암호문 변조
↓
복호화된 데이터 변화

같은 문제가 생길 수 있습니다.

따라서:

내용을 숨긴다

와:

변경 여부를 검증한다

는 서로 다른 보안 목표입니다.

40장 GCM을 사용한다고 모든 문제가 해결되는 것은 아니다#

GCM은 AEAD라는 큰 장점이 있지만 여전히 운영 조건이 중요합니다.

예를 들어:

Nonce 재사용
태그 검증 생략
키 노출
잘못된 키 관리

가 발생하면 문제가 될 수 있습니다.

따라서:

AES-GCM
=
아무렇게나 써도 안전

은 아닙니다.

41장 ECB는 왜 신규 데이터 보호에서 피해야 할까#

원문 기준 가장 큰 이유는 반복 패턴 노출입니다.

새로운 데이터 암호화 기능을 설계하면서 특별한 이유 없이 ECB를 선택할 필요는 거의 없습니다.

구현이 단순하다

는 이유가:

데이터 구조 노출 위험

을 정당화하지는 않습니다.

42장 CBC를 유지해야 하는 레거시 시스템도 있을 수 있다#

오래된 시스템이나 프로토콜에서는 이미 CBC 기반 형식이 존재할 수 있습니다.

이 경우 단순히:

CBC는 오래됐으니 삭제

라고 판단하기보다 기존 구현의:

IV 처리
인증
패딩
오류 처리

조건을 정확히 분석해야 합니다.

다만 신규 설계라면 원문처럼 안전한 AEAD API를 우선 검토하는 것이 실수를 줄이는 데 도움이 됩니다.

43장 CTR을 선택할 때도 인증 문제를 잊으면 안 된다#

CTR은 패딩이 필요 없고 처리 특성이 편리합니다.

하지만 원문 기준 메시지 인증은 별도로 구성해야 합니다.

따라서:

CTR이 구현하기 편하다

만 보고 선택하면 변조 탐지 요구사항을 놓칠 수 있습니다.

44장 암호 모드 선택을 성능만으로 결정하면 안 된다#

예를 들어 CTR은 병렬 처리나 임의 접근 특성 때문에 특정 환경에서 매력적으로 보일 수 있습니다.

하지만 보안 요구에는 다음도 있습니다.

기밀성
변조 검증
Nonce 관리
오류 처리

따라서 속도가 빠르다는 이유만으로 모드를 선택해서는 안 됩니다.

45장 애플리케이션 데이터 암호화 예제#

새 문서 저장 서비스를 만든다고 하겠습니다.

요구사항은 다음과 같습니다.

문서 내용은 외부에 노출되면 안 된다.

암호문이 변경되면 탐지해야 한다.

여러 문서를 같은 키로 처리할 수 있다.

이런 요구에서는 단순 ECB나 인증 없는 CBC·CTR보다 원문에서 권장하는 것처럼 검증된 AEAD 방식을 우선 검토할 수 있습니다.

46장 개념적인 AEAD 저장 구조#

flowchart TB
    FILE[원본 파일]
    KEY[암호화 키]
    NONCE[Nonce]

    AEAD[AEAD 암호화]

    CIPHER[암호문]
    TAG[인증 태그]

    FILE --> AEAD
    KEY --> AEAD
    NONCE --> AEAD

    AEAD --> CIPHER
    AEAD --> TAG

저장할 때는 암호문만이 아니라 필요한 메타데이터도 함께 관리해야 합니다.

47장 암호화 데이터에 함께 관리할 정보#

구체적인 형식은 사용하는 라이브러리와 프로토콜에 따라 다르지만 개념적으로 다음 정보를 관리할 수 있습니다.

암호 알고리즘
운영 모드
키 버전
IV 또는 Nonce
인증 태그
암호문

이런 정보를 명시하면 향후 키 교체나 알고리즘 전환에도 도움이 됩니다.

48장 실무에서 자주 하는 실수 1: AES라고만 기록한다#

예:

암호 알고리즘: AES

이 정보만으로는 부족합니다.

최소한:

어떤 모드인가?
키 길이는?
IV·Nonce는 어떻게 관리하는가?
인증 태그가 있는가?

를 확인해야 합니다.

49장 실무에서 자주 하는 실수 2: ECB가 단순하니 사용한다#

ECB는 각 블록을 독립적으로 처리해 구현 구조는 단순할 수 있습니다.

하지만 반복되는 평문 블록이 같은 암호문으로 변환되어 구조가 노출될 수 있습니다.

단순함과 안전성은 같은 의미가 아닙니다.

50장 실무에서 자주 하는 실수 3: CBC 암호화만 하면 무결성도 보호된다고 생각한다#

CBC는 원문 기준 별도 인증 없이 변조를 막아주지 않습니다.

기밀성과 메시지 인증을 분리해서 생각해야 합니다.

51장 실무에서 자주 하는 실수 4: CTR에서 같은 Counter 입력을 재사용한다#

원문은 동일 키 아래 카운터 입력 재사용 금지를 핵심 조건으로 제시합니다.

CTR은 이 조건을 어기면 키스트림 재사용 문제로 이어질 수 있습니다.

52장 실무에서 자주 하는 실수 5: GCM 태그 오류를 무시한다#

다음과 같은 코드는 논리적으로 위험합니다.

태그 검증 실패
↓
그래도 평문 처리

태그 검증이 실패하면 데이터 전체를 신뢰하지 않는 방향으로 처리해야 합니다.

53장 실무에서 자주 하는 실수 6: GCM Nonce를 무작위로 대충 만들면 된다고 생각한다#

핵심은 특정 구현에서 요구하는 방식으로 Nonce를 관리하고 동일 키 아래 재사용되지 않도록 하는 것입니다.

Nonce 관리 정책 없이 단순히 GCM을 선택하는 것으로는 부족합니다.

54장 실무에서 자주 하는 실수 7: 복호화 실패 내용을 자세히 노출한다#

예:

Padding Error

Invalid Tag

Wrong Key

같은 내부 오류를 그대로 외부 응답에 노출하면 공격자에게 불필요한 정보를 줄 수 있습니다.

원문은 특히 복호화 실패 시 부분 평문을 외부로 전달하지 않도록 강조합니다.

55장 운영 모드 선택 절차#

실무적으로는 다음과 같은 흐름으로 생각할 수 있습니다.

flowchart TB
    A[보호할 데이터 정의]
    B[기밀성 필요?]
    C[변조 탐지 필요?]
    D[신규 설계인가?]
    E[AEAD 지원 확인]
    F[IV·Nonce 관리 설계]
    G[태그 검증 설계]
    H[검증된 라이브러리 적용]
    I[오류 처리 테스트]

    A --> B --> C --> D --> E --> F --> G --> H --> I

핵심은 모드 이름을 먼저 고르는 것이 아니라 보안 요구사항부터 정하는 것입니다.

56장 신규 애플리케이션에서의 판단 기준#

원문의 내용을 기준으로 신규 데이터 암호화에서는 다음을 먼저 확인할 수 있습니다.

기밀성뿐 아니라 변조 탐지도 필요한가?

검증된 AEAD API가 있는가?

Nonce를 안전하게 관리할 수 있는가?

복호화 실패 시 데이터를 확실히 폐기하는가?

이런 질문을 만족하는 방향으로 설계하는 것이 좋습니다.

57장 ECB·CBC·CTR·GCM FAQ#

블록 암호 운영 모드란 무엇인가#

AES 같은 고정 길이 블록 암호를 긴 메시지에 적용하는 규칙입니다. 같은 AES라도 모드에 따라 패딩·변조 검증·IV·Nonce 관리 조건이 달라집니다.

ECB는 왜 문제가 되는가#

같은 평문 블록이 같은 암호문으로 변환되기 때문에 반복되는 구조가 노출될 수 있습니다.

CBC는 패딩이 필요한가#

네. 원문 기준 CBC는 블록에 맞춰 패딩이 필요하며 예측 불가능한 IV가 필요합니다.

CBC는 무조건 안전하지 않은가#

아닙니다. 인증과 IV·패딩 처리를 올바르게 결합한 프로토콜은 사용할 수 있습니다. 다만 신규 설계에서는 AEAD API를 선택하면 구현 실수를 줄일 수 있습니다.

CTR은 패딩이 필요한가#

필요하지 않습니다. 대신 동일 키 아래 카운터 입력을 재사용하지 않아야 하며 메시지 인증은 별도로 구성해야 합니다.

GCM은 무엇이 다른가#

GCM은 암호화와 인증을 결합하는 AEAD 방식이며 인증 태그를 제공합니다.

GCM에서 가장 중요한 조건은 무엇인가#

동일 키 아래 Nonce를 재사용하지 않고 태그를 반드시 검증하는 것입니다.

CTR을 디스크 암호화에 사용하면 안 되는가#

원문은 CTR의 임의 접근 특성만 보고 디스크 보안 방식으로 바로 채택해서는 안 된다고 설명합니다. 디스크 섹터 암호화에는 XTS 등 용도에 맞는 표준을 별도로 검토해야 합니다.

복호화 도중 오류가 나면 일부 평문을 사용할 수 있나#

원문은 복호화 실패 시 부분 평문을 외부에 전달하지 않도록 명시합니다.

핵심 정리#

ECB·CBC·CTR·GCM은 모두 블록 암호를 활용하는 방식이지만 서로 다른 특성을 가집니다.

원문의 비교 기준을 압축하면 다음과 같습니다.

ECB
패딩 필요
인증 없음
반복 패턴 노출

CBC
패딩 필요
별도 인증 필요
예측 불가능한 IV 필요

CTR
패딩 불필요
별도 인증 필요
카운터 입력 재사용 금지

GCM
패딩 불필요
인증 태그 제공
Nonce 재사용 금지
태그 검증 필수

구조적으로 보면:

flowchart LR
    ECB[ECB<br/>독립 블록]
    CBC[CBC<br/>연결된 블록]
    CTR[CTR<br/>Key Stream]
    GCM[GCM<br/>AEAD]

    ECB --> E[패턴 노출 위험]
    CBC --> C[IV·패딩·별도 인증]
    CTR --> T[Counter 재사용 금지]
    GCM --> G[Nonce·Tag 관리]

중요한 것은 단순히:

AES 사용

이라고 정하는 것이 아닙니다.

실제로는:

알고리즘
+
운영 모드
+
IV 또는 Nonce 관리
+
메시지 인증
+
태그 검증
+
오류 처리

전체를 함께 설계해야 합니다.

원문이 강조하듯 새 애플리케이션에서 데이터 암호화를 설계한다면 검증된 라이브러리가 제공하는 AEAD 방식을 우선 검토하고, 각 모드가 요구하는 IV·Nonce 조건과 복호화 실패 처리까지 함께 점검하는 것이 핵심입니다.

이 페이지의 목차