ThinkX | AI·기술·IT·개발·산업·자기계발 지식 아카이브
암호화·해시·전자서명의 차이: 보호하려는 목적부터 고르기
1장 암호화·해시·전자서명은 왜 자꾸 헷갈릴까#
보안 시스템을 설계하다 보면 다음과 같은 기술을 자주 만납니다.
암호화
해시
HMAC
전자서명이들은 모두 데이터를 수학적으로 변환한다는 공통점이 있습니다.
그래서 처음 접하면 비슷한 기술처럼 보일 수 있습니다.
하지만 목적은 서로 다릅니다.
원문에서는 이를 다음과 같이 구분합니다.
암호화
→ 내용을 숨긴다
해시
→ 입력의 요약값을 만든다
전자서명
→ 개인키로 서명하고 공개키로 검증한다즉 어떤 기술을 선택할지는 먼저:
무엇을 보호하려는가?
부터 결정해야 합니다.
2장 목적별로 먼저 보면 이해하기 쉽다#
원문의 구분을 구조화하면 다음과 같습니다.
flowchart TD
A["보호하려는 목적"]
A --> B["내용을 숨기고 싶다"]
A --> C["데이터가 바뀌었는지 비교하고 싶다"]
A --> D["공유 키로 메시지를 인증하고 싶다"]
A --> E["공개키로 발신자와 무결성을 검증하고 싶다"]
B --> B1["암호화"]
C --> C1["해시"]
D --> D1["HMAC"]
E --> E1["전자서명"]이 기준을 잡아두면 암호 기술을 훨씬 쉽게 구분할 수 있습니다.
3장 암호화 Encryption이란 무엇인가#
암호화는 평문을 읽을 수 없는 암호문으로 바꾸는 기술입니다.
원문에서는 암호화를 다음과 같이 설명합니다.
키를 이용해 평문을 암호문으로 바꾸고 허용된 주체가 복호화하도록 하는 기술
예를 들어 원본 데이터가:
고객 이름: 홍길동
계좌번호: 123-456-789이라면 암호화를 거친 뒤에는 사람이 직접 읽기 어려운 데이터로 변환됩니다.
flowchart LR
P["평문"]
E["암호화"]
C["암호문"]
D["복호화"]
P2["원래 평문"]
P --> E --> C --> D --> P2암호화의 가장 대표적인 목적은 기밀성입니다.
4장 암호화에서 가장 중요한 것은 키다#
암호화 알고리즘만 사용한다고 안전한 것은 아닙니다.
실제로는 다음 요소가 함께 중요합니다.
알고리즘
키
운영 모드
Nonce
키 저장 위치
접근 권한원문에서도 암호화를 사용할 때 키·모드·Nonce·권한을 함께 고려해야 한다고 설명합니다.
즉:
AES를 사용한다라는 사실만으로 보안 설계가 끝나는 것은 아닙니다.
5장 암호 알고리즘을 숨겨야 안전한가#
현대 암호학에서는 일반적으로 알고리즘 자체를 숨기는 것을 보안의 핵심으로 삼지 않습니다.
원문은 Kerckhoffs 원리를 언급합니다.
핵심은 다음과 같습니다.
공격자가 알고리즘을 알고 있더라도 키를 모르면 시스템이 안전해야 한다.
구조적으로 보면:
flowchart TB
ALGO["공개된 알고리즘"]
KEY["비밀 키"]
SEC["보안"]
ALGO --> SEC
KEY --> SEC중요한 것은 알고리즘을 숨기는 것이 아니라:
키의 비밀성
안전한 구현
올바른 사용 조건입니다.
6장 자체 암호 알고리즘을 만드는 것이 위험한 이유#
다음과 같은 생각을 할 수 있습니다.
알고리즘을 나만 알면
공격자가 해독하기 어렵지 않을까?하지만 이런 방식은 알고리즘이 노출되는 순간 보안이 무너질 수 있습니다.
검증되지 않은 자체 알고리즘은 구조적인 결함이 발견되지 않은 상태일 가능성도 있습니다.
원문은 검증된 라이브러리의 안전한 상위 API를 사용해야 한다고 권고합니다.
따라서 일반적인 애플리케이션 개발에서는 검증된 암호 라이브러리를 사용하는 것이 기본입니다.
7장 대칭키 암호란 무엇인가#
대칭키 방식에서는 암호화와 복호화에 같은 비밀 키를 사용합니다.
flowchart LR
P["평문"]
E["암호화"]
C["암호문"]
D["복호화"]
P2["평문"]
K["공유 비밀 키"]
P --> E --> C --> D --> P2
K --> E
K --> D대표적인 특징은 대량의 데이터를 비교적 효율적으로 처리할 수 있다는 점입니다.
원문도 대칭키 기술을 주로 데이터 처리에 활용한다고 설명합니다.
8장 대칭키의 핵심 문제는 키 공유다#
대칭키에서는 송신자와 수신자가 같은 비밀 키를 알아야 합니다.
그렇다면 다음 문제가 생깁니다.
처음에 이 비밀 키를 어떻게 안전하게 전달할 것인가?
예를 들어 인터넷을 통해 그대로 키를 보내면:
flowchart LR
A["사용자 A"]
K["비밀 키"]
B["사용자 B"]
X["공격자"]
A --> K --> B
K -. 탈취 가능 .-> X키 자체가 탈취될 수 있습니다.
이 문제를 해결하는 데 공개키 기술이 함께 사용될 수 있습니다.
9장 공개키 암호 기술은 무엇인가#
공개키 기술에서는 서로 다른 두 키를 사용합니다.
공개키
개인키공개키는 다른 사람에게 공개할 수 있습니다.
개인키는 소유자가 보호해야 합니다.
원문은 공개키 기술을 키 설정이나 전자서명에 활용한다고 설명합니다.
10장 공개키는 공개되면 위험한가#
공개키는 이름 그대로 공개를 전제로 설계됩니다.
원문의 FAQ에서도 이 부분을 명확하게 설명합니다.
보호해야 하는 것은:
공개키가 아니라:
개인키입니다.
그러나 또 하나 중요한 문제가 있습니다.
내가 받은 공개키가 정말 상대방의 공개키인가?
그래서 인증서 또는 신뢰할 수 있는 전달 경로가 필요할 수 있습니다.
11장 실제 시스템은 대칭키와 공개키를 함께 사용한다#
현실적인 시스템에서는 한 가지 암호 기술만 사용하는 경우보다 여러 기술을 조합하는 경우가 많습니다.
원문도 실제 시스템에서는 여러 암호 기술을 결합한다고 설명합니다.
개념적으로는:
flowchart LR
PK["공개키 기술"]
KEY["안전한 키 설정"]
SYM["대칭키 암호화"]
DATA["대량 데이터 보호"]
PK --> KEY --> SYM --> DATA처럼 사용할 수 있습니다.
즉:
공개키 기술
→ 안전하게 키를 설정
대칭키 기술
→ 실제 데이터를 효율적으로 암호화라는 역할 분담이 가능합니다.
12장 해시 Hash란 무엇인가#
해시는 입력 데이터를 일정한 길이의 요약값으로 변환하는 기술입니다.
예:
Hello라는 입력을 넣으면 특정 해시값이 생성됩니다.
flowchart LR
DATA["입력 데이터"]
HASH["해시 함수"]
VALUE["해시값"]
DATA --> HASH --> VALUE해시는 암호화와 목적이 다릅니다.
암호화는 원본을 다시 복호화하는 것을 전제로 하지만, 해시는 일반적으로 원문을 되돌리는 목적으로 사용하지 않습니다.
13장 해시는 어디에 사용하는가#
원문에서는 해시를 요약과 변경 비교에 사용하는 기술로 설명합니다.
예를 들어 파일을 다운로드했다고 하겠습니다.
배포자가 제공한 해시:
ABC123...다운로드한 파일에서 계산한 해시:
ABC123...두 값이 같다면 파일이 동일한지 비교하는 데 활용할 수 있습니다.
flowchart TB
ORIGINAL["배포자가 제공한 기준 해시"]
FILE["다운로드한 파일"]
HASH["해시 계산"]
RESULT["계산된 해시"]
FILE --> HASH --> RESULT
ORIGINAL --> CHECK{"같은가?"}
RESULT --> CHECK
CHECK -->|"같음"| OK["변경되지 않았을 가능성"]
CHECK -->|"다름"| BAD["파일 변경"]14장 해시값만 있다고 무결성이 완성되는 것은 아니다#
여기서 중요한 문제가 있습니다.
공격자가 파일과 해시값을 모두 바꿀 수 있다면 어떻게 될까요?
악성 파일
+
악성 파일에 맞는 새로운 해시값을 함께 제공할 수 있습니다.
따라서 원문도 해시를 이용한 변경 비교에는 신뢰할 수 있는 기준값이 필요하다고 설명합니다.
즉 해시 자체보다:
이 기준 해시값을 신뢰할 수 있는가?
가 중요합니다.
15장 암호화와 해시는 목적이 다르다#
두 기술을 비교하면 다음과 같습니다.
| 구분 | 암호화 | 해시 |
|---|---|---|
| 주요 목적 | 내용 숨기기 | 요약·변경 비교 |
| 키 | 일반적으로 필요 | 일반 해시에는 불필요 |
| 원본 복원 | 복호화 가능 | 원본 복구 목적 아님 |
| 대표 보안 목표 | 기밀성 | 무결성 비교 |
따라서:
비밀번호를 숨기기 위해 해시한다와:
문서를 숨기기 위해 암호화한다는 서로 다른 목적입니다.
16장 HMAC은 무엇인가#
HMAC은 공유 비밀 키와 해시 기반 구조를 이용해 메시지를 인증하는 기술입니다.
개념적으로:
flowchart LR
DATA["메시지"]
KEY["공유 비밀 키"]
HMAC["HMAC"]
TAG["인증값"]
DATA --> HMAC
KEY --> HMAC
HMAC --> TAG원문에서는 HMAC의 주요 목적을 공유 키 기반 메시지 인증으로 설명합니다.
17장 단순 해시와 HMAC의 차이#
단순 해시:
데이터
↓
해시값HMAC:
데이터
+
공유 비밀 키
↓
인증값이 차이가 중요합니다.
공격자가 데이터를 바꾼 뒤 일반 해시값을 다시 계산하는 것은 가능할 수 있습니다.
그러나 HMAC을 올바르게 생성하려면 비밀 키를 알아야 합니다.
18장 HMAC으로 무엇을 확인할 수 있는가#
송신자와 수신자가 같은 비밀 키를 공유한다고 하겠습니다.
송신자:
메시지
+
비밀 키
→ HMAC수신자:
받은 메시지
+
같은 비밀 키
→ HMAC 재계산두 값이 같으면 메시지가 전송 과정에서 변경되지 않았는지 검증하는 데 활용할 수 있습니다.
sequenceDiagram
participant A as 송신자
participant B as 수신자
A->>A: 메시지 + 공유 키로 HMAC 생성
A->>B: 메시지 + HMAC
B->>B: 공유 키로 HMAC 재계산
B->>B: 두 값 비교19장 HMAC에도 중요한 한계가 있다#
원문에서는 HMAC의 주의점으로:
양쪽이 인증값을 생성할 수 있다.
는 점을 제시합니다.
왜냐하면 송신자와 수신자가 같은 비밀 키를 공유하기 때문입니다.
즉 두 사람 모두 유효한 HMAC을 생성할 수 있습니다.
따라서:
특정 한 사람만 생성했다는 사실을 제3자에게 증명하고 싶다.
는 요구에는 전자서명이 더 적합할 수 있습니다.
20장 전자서명 Digital Signature이란 무엇인가#
전자서명은 공개키 암호 기술을 이용합니다.
원문에서는:
개인키로 만든 서명을 공개키로 검증한다.
고 설명합니다.
기본 구조는 다음과 같습니다.
flowchart LR
DOC["문서"]
SIGN["개인키로 서명"]
SIG["전자서명"]
DOC --> SIGN
SIGN --> SIG
SIG --> VERIFY["공개키로 검증"]
DOC --> VERIFY
VERIFY --> RESULT["검증 결과"]21장 전자서명의 핵심은 무엇인가#
전자서명은 다음과 같은 검증에 활용됩니다.
문서가 변경되지 않았는가
해당 개인키 보유자가 만든 서명인가원문은 전자서명의 주요 목적을 공개키를 이용한 발신·무결성 검증으로 정리합니다.
즉 단순 암호화와는 목적이 다릅니다.
22장 전자서명은 데이터를 숨기는 기술이 아니다#
이 부분도 자주 혼동합니다.
전자서명이 있다고 해서 문서 내용이 숨겨지는 것은 아닙니다.
예를 들어:
공개 문서
+
전자서명구조도 가능합니다.
문서는 누구나 읽을 수 있지만:
누가 서명했는가
서명 이후 문서가 변경되었는가를 검증하는 데 전자서명을 사용할 수 있습니다.
따라서 기밀성이 필요하면 별도의 암호화가 필요합니다.
23장 암호화와 전자서명은 반대 개념이 아니다#
둘은 경쟁 기술이 아니라 목적이 다른 기술입니다.
예를 들어 중요한 문서를:
암호화
+
전자서명할 수도 있습니다.
flowchart LR
DOC["문서"]
ENC["암호화"]
SIGN["전자서명"]
DOC --> ENC
DOC --> SIGN
ENC --> CONF["기밀성"]
SIGN --> VERIFY["무결성·발신자 검증"]즉 하나의 데이터에 여러 보안 목표를 동시에 적용할 수 있습니다.
24장 HMAC과 전자서명의 차이#
두 기술 모두 메시지 인증과 무결성 확인에 활용할 수 있지만 키 구조가 다릅니다.
| 구분 | HMAC | 전자서명 |
|---|---|---|
| 키 구조 | 공유 비밀 키 | 개인키·공개키 |
| 생성 | 공유 키 보유자 | 개인키 보유자 |
| 검증 | 공유 키 보유자 | 공개키 보유자 |
| 주요 용도 | 시스템 간 메시지 인증 | 공개키 기반 서명 검증 |
| 주의점 | 양쪽 모두 인증값 생성 가능 | 개인키 보호·신뢰체계 필요 |
원문의 비교 기준 역시 이 차이를 강조합니다.
25장 문서 저장소 사례로 구분해보자#
원문은 문서 저장소를 예로 들어 기술을 구분합니다.
문서 내용을 다른 사람이 보지 못하게 하고 싶다#
암호화가 필요합니다.
배포 파일이 바뀌었는지 확인하고 싶다#
신뢰할 수 있는 해시값과 비교합니다.
누가 배포했는지 확인하고 싶다#
전자서명 검증을 사용할 수 있습니다.
이 사례 하나만 이해해도 각 기술의 목적 차이가 상당히 명확해집니다.
26장 파일 배포 사례로 보면 더 쉽다#
소프트웨어 배포 파일이 있다고 하겠습니다.
program.zip파일 내용을 숨길 필요가 없다#
암호화가 반드시 필요한 것은 아닙니다.
다운로드 과정에서 파일이 바뀌었는지 확인하고 싶다#
해시를 사용할 수 있습니다.
공식 개발자가 배포한 파일인지 확인하고 싶다#
전자서명을 사용할 수 있습니다.
flowchart TB
FILE["배포 파일"]
H["해시"]
S["전자서명"]
FILE --> H
FILE --> S
H --> H1["변경 비교"]
S --> S1["발신자·무결성 검증"]27장 Base64는 암호화가 아니다#
이 부분은 실무에서도 자주 혼동됩니다.
예를 들어:
hello를 Base64로 변환하면 읽기 어려운 문자열처럼 보일 수 있습니다.
하지만 Base64는 원문에서 설명하듯 표현 형식을 바꾸는 인코딩입니다.
따라서 기밀성을 제공하지 않습니다.
28장 인코딩과 암호화의 차이#
인코딩#
데이터 표현 형식을 바꿉니다.
목적은 저장이나 전송 호환성입니다.
암호화#
비밀 키 없이는 내용을 읽기 어렵게 만듭니다.
목적은 기밀성입니다.
flowchart LR
DATA["원본 데이터"]
ENC1["Base64 인코딩"]
ENC2["암호화"]
B64["다른 표현"]
CIPHER["암호문"]
DATA --> ENC1 --> B64
DATA --> ENC2 --> CIPHER
B64 --> EASY["누구나 디코딩 가능"]
CIPHER --> KEY["복호화 키 필요"]29장 Base64로 비밀번호를 숨기면 안 되는 이유#
다음처럼 저장했다고 하겠습니다.
password123
↓
Base64
↓
cGFzc3dvcmQxMjM=겉보기에는 원본이 보이지 않습니다.
그러나 누구나 쉽게 원래 값으로 되돌릴 수 있습니다.
따라서:
Base64
=
보안 기능으로 생각해서는 안 됩니다.
30장 목적부터 선택하는 것이 중요한 이유#
암호 기술을 먼저 선택하고 목적을 나중에 생각하면 잘못된 설계가 나올 수 있습니다.
예:
데이터가 바뀌었는지 확인하고 싶다
↓
무조건 암호화보다:
목적이 무엇인가?
↓
무결성 확인
↓
해시·HMAC·전자서명 중 조건에 맞게 선택하는 것이 올바른 접근입니다.
31장 보호 목표에서 기술을 선택하는 흐름#
flowchart TB
GOAL["보호 목표"]
C["내용을 숨길 것인가?"]
I["변경 여부를 확인할 것인가?"]
A["공유 키로 인증할 것인가?"]
S["공개키로 발신자를 검증할 것인가?"]
ENC["암호화"]
HASH["해시"]
HMAC["HMAC"]
SIGN["전자서명"]
GOAL --> C
GOAL --> I
GOAL --> A
GOAL --> S
C --> ENC
I --> HASH
A --> HMAC
S --> SIGN이 흐름이 원문의 핵심적인 판단 방법입니다.
32장 실제 시스템에서는 여러 기술이 동시에 필요하다#
예를 들어 API 통신을 생각해볼 수 있습니다.
필요한 보안 목표가:
내용 노출 방지
메시지 무결성
상대방 인증이라면 한 기술만으로 모든 목적을 해결하려 하기보다 여러 기술을 조합할 수 있습니다.
flowchart TB
API["API 통신"]
C["기밀성"]
I["무결성"]
AUTH["인증"]
API --> C
API --> I
API --> AUTH
C --> ENC["암호화"]
I --> MAC["HMAC 또는 서명"]
AUTH --> CERT["키·인증 체계"]33장 키 관리가 암호 알고리즘만큼 중요하다#
강력한 알고리즘을 사용하더라도 키가 노출되면 문제가 됩니다.
예:
소스코드에 키 저장
Git 저장소에 비밀 키 커밋
로그에 키 출력
모든 서버에서 하나의 키 공유등은 위험할 수 있습니다.
원문도 알고리즘만이 아니라 키 관리까지 함께 설계해야 한다고 강조합니다.
34장 개인키는 특히 보호해야 한다#
전자서명에서는 개인키가 핵심입니다.
공격자가 개인키를 탈취하면 해당 키 소유자인 것처럼 서명을 생성할 수 있습니다.
flowchart LR
PRIVATE["개인키"]
SIGN["서명 생성"]
TRUST["신뢰"]
PRIVATE --> SIGN --> TRUST
ATTACK["개인키 탈취"] -.-> SIGN따라서 전자서명 시스템에서는 알고리즘 선택뿐 아니라:
개인키 저장
접근 제어
키 교체
폐기등의 관리가 중요합니다.
35장 공개키도 진짜 상대의 것인지 확인해야 한다#
공개키는 공개되어도 괜찮지만 다음 질문은 남습니다.
이 공개키가 정말 내가 통신하려는 상대의 공개키인가?
공격자가 자신의 공개키를 상대방의 공개키라고 속일 수도 있기 때문입니다.
원문에서도 공개키가 올바른 상대의 것인지 인증서 또는 신뢰할 수 있는 경로로 확인해야 한다고 설명합니다.
36장 검증된 라이브러리를 사용하는 것이 중요한 이유#
암호학은 구현 세부사항에 따라 보안성이 크게 달라질 수 있습니다.
예를 들어 같은 알고리즘을 사용하더라도:
Nonce 재사용
잘못된 모드 선택
약한 키
잘못된 난수
오류 처리 문제등이 있으면 보안이 약해질 수 있습니다.
따라서 원문은 검증된 라이브러리의 안전한 상위 API를 사용하라고 권고합니다.
가능하면 암호 원시 기능을 직접 조립하기보다 검증된 사용 패턴을 따르는 것이 좋습니다.
37장 암호 기술을 선택하기 전 체크할 질문#
원문의 적용 전 확인사항을 실무 질문으로 바꾸면 다음과 같습니다.
기밀성이 필요한가#
누군가 내용을 읽지 못하게 해야 하는가?그렇다면 암호화를 검토합니다.
무결성 확인이 필요한가#
데이터가 변경되었는지 확인해야 하는가?해시·HMAC·전자서명 등을 검토할 수 있습니다.
발신자를 검증해야 하는가#
누가 만든 데이터인지 확인해야 하는가?HMAC 또는 전자서명의 특성을 비교합니다.
키는 어떻게 관리할 것인가#
암호 알고리즘보다 운영이 더 큰 문제가 될 수 있습니다.
38장 암호 기술 비교표#
| 기술 | 주요 목적 | 키 | 복원 | 주요 주의점 |
|---|---|---|---|---|
| 암호화 | 기밀성 | 필요 | 복호화 가능 | 키·모드·Nonce |
| 해시 | 요약·변경 비교 | 일반적으로 없음 | 복원 목적 아님 | 기준값 신뢰 |
| HMAC | 메시지 인증·무결성 | 공유 키 | 해당 없음 | 양쪽 모두 생성 가능 |
| 전자서명 | 발신자·무결성 검증 | 개인키·공개키 | 해당 없음 | 개인키·신뢰 체계 |
원문의 비교 기준을 확장해 정리한 표입니다.
39장 자주 하는 실수 1: 암호화하면 무결성도 자동으로 해결된다고 생각한다#
암호화의 주요 목적은 기밀성입니다.
어떤 암호 방식과 사용 방법을 선택했는지에 따라 무결성 보호 특성이 달라질 수 있으므로:
암호화했으니
무결성도 무조건 안전하다라고 단정해서는 안 됩니다.
목적에 맞는 설계가 필요합니다.
40장 자주 하는 실수 2: 해시값이 있으면 무조건 안전하다고 생각한다#
기준 해시값 자체가 공격자에게 변경될 수 있다면 검증 신뢰성이 떨어집니다.
따라서:
해시값이 있는가뿐 아니라:
그 해시값을 신뢰할 수 있는가를 함께 확인해야 합니다.
41장 자주 하는 실수 3: HMAC과 전자서명을 같은 것으로 생각한다#
두 기술 모두 메시지 무결성과 인증에 활용할 수 있지만 키 구조가 다릅니다.
HMAC
→ 같은 비밀 키를 공유
전자서명
→ 개인키로 생성
→ 공개키로 검증특히 HMAC에서는 공유 키를 가진 양쪽 모두 인증값을 생성할 수 있다는 차이가 있습니다.
42장 자주 하는 실수 4: Base64를 암호화로 생각한다#
Base64는 인코딩입니다.
누구나 알고리즘을 알고 있으며 별도의 비밀 키 없이 원래 데이터로 되돌릴 수 있습니다.
원문도 Base64가 기밀성을 제공하지 않는다고 명시합니다.
43장 자주 하는 실수 5: 자체 암호화 방식을 만든다#
예를 들어:
문자 위치 변경
XOR 몇 번 적용
임의 치환
Base64 반복등으로 자신만의 암호 체계를 만드는 것은 안전성을 검증하기 어렵습니다.
보안성이 필요한 경우 검증된 암호 기술과 라이브러리를 사용하는 것이 좋습니다.
44장 실제 설계에서는 목적을 분리해서 적어보자#
예를 들어 고객 문서를 저장한다고 하겠습니다.
요구사항을 다음처럼 적을 수 있습니다.
목표 1
저장된 문서 내용을 권한 없는 사람이 읽지 못해야 한다.
목표 2
문서가 임의로 변경되었는지 확인할 수 있어야 한다.
목표 3
공식 시스템에서 생성된 문서인지 확인해야 한다.그러면 기술도 자연스럽게 나뉩니다.
flowchart LR
G1["내용 숨기기"]
G2["변경 검증"]
G3["발신자 검증"]
E["암호화"]
H["해시·HMAC"]
S["전자서명"]
G1 --> E
G2 --> H
G3 --> S45장 암호 기술 선택의 핵심은 CIA와 연결할 수 있다#
기본적인 정보보안 목표와 연결하면 이해하기 쉽습니다.
기밀성#
암호화와 밀접합니다.
무결성#
해시
HMAC
전자서명과 연결할 수 있습니다.
인증·책임추적#
공개키와 전자서명 같은 기술이 활용될 수 있습니다.
하지만 하나의 기술이 항상 하나의 목표만 가진다고 단순화해서는 안 됩니다.
실제 보안 특성은 알고리즘과 구현 방식에 따라 달라질 수 있습니다.
46장 암호 기술 설계의 전체 흐름#
flowchart TB
A["보호 대상 식별"]
B["보안 목표 결정"]
C["암호 기술 선택"]
D["알고리즘·모드 선택"]
E["키 관리 설계"]
F["검증된 라이브러리 적용"]
G["운영·키 교체·검증"]
A --> B --> C --> D --> E --> F --> G단순히 알고리즘 이름을 선택하는 것보다 전체 생명주기를 보는 것이 중요합니다.
47장 암호화·해시·전자서명 FAQ#
암호화란 무엇인가#
키를 이용해 평문을 암호문으로 변환하고 허용된 주체가 다시 복호화할 수 있도록 하는 기술입니다. 주요 목적은 기밀성입니다.
해시는 암호화와 같은가#
아닙니다. 해시는 입력의 요약값을 계산하는 기술이며 원문은 변경 비교 등에 사용하는 것으로 구분합니다.
HMAC은 무엇인가#
공유 비밀 키를 이용해 메시지를 인증하고 무결성을 검증하는 방식입니다. 공유 키를 가진 양쪽이 인증값을 생성할 수 있다는 특징이 있습니다.
전자서명은 무엇인가#
개인키로 서명을 생성하고 공개키로 검증하는 기술입니다. 발신자와 데이터 무결성 검증에 활용됩니다.
공개키가 공개되면 보안이 깨지는가#
아닙니다. 공개키는 공개를 전제로 합니다. 보호해야 할 것은 개인키이며 공개키가 올바른 상대의 것인지도 확인해야 합니다.
Base64도 암호화인가#
아닙니다. Base64는 데이터를 다른 표현으로 바꾸는 인코딩이며 기밀성을 제공하지 않습니다.
파일이 변경되었는지만 확인하려면 무엇을 사용해야 하나#
신뢰할 수 있는 기준 해시와 비교할 수 있습니다. 기준 해시 자체가 신뢰할 수 있는 경로에서 제공되는지가 중요합니다.
누가 파일을 배포했는지 확인하려면 무엇을 사용할 수 있나#
원문의 사례에서는 누가 배포했는지 확인하기 위해 전자서명을 검증하는 방법을 제시합니다.
핵심 정리#
암호화·해시·HMAC·전자서명은 비슷해 보이지만 목적이 다릅니다.
flowchart TD
G["보안 목표"]
C["내용을 숨긴다"]
I["변경 여부를 확인한다"]
M["공유 키로 메시지를 인증한다"]
S["공개키로 발신자를 검증한다"]
ENC["암호화"]
HASH["해시"]
HMAC["HMAC"]
SIGN["전자서명"]
G --> C --> ENC
G --> I --> HASH
G --> M --> HMAC
G --> S --> SIGN가장 간단하게 정리하면 다음과 같습니다.
암호화
→ 내용을 숨긴다
해시
→ 데이터의 요약값을 만든다
HMAC
→ 공유 비밀 키로 메시지를 인증한다
전자서명
→ 개인키로 서명하고 공개키로 검증한다그리고 반드시 기억해야 할 것이 있습니다.
Base64
≠
암호화Base64는 인코딩이며 기밀성을 제공하지 않습니다.
또한 암호학에서 중요한 것은 알고리즘 이름만이 아닙니다.
보호 목표
+
알고리즘
+
운영 모드
+
키 관리
+
안전한 구현전체를 함께 설계해야 합니다.
원문이 강조하듯 먼저 기밀성·무결성·발신자 검증 중 무엇이 필요한지 결정하고, 그다음 알고리즘·모드·키 관리와 검증된 라이브러리를 선택하는 것이 암호 기술을 올바르게 사용하는 출발점입니다.