암호학 기초: 엔트로피·해시·KDF·대칭키·공개키를 구분하는 법

암호학을 처음 공부하면 해시, 비밀번호 저장, 파일 암호화, 전자서명이 모두 비슷한 수학 도구처럼 보인다. 하지만 이들은 해결하는 문제가 다르다. 용도를 섞으면 알고리즘 이름은 맞아도 시스템은 안전하지 않을 수 있다.

이 글은 MIT Missing Semester의 Security and Cryptography 강의를 따라 적었던 메모를 현재 기준으로 다시 정리한 것이다. 강의가 먼저 강조하듯, 여기서 얻을 수 있는 것은 도구를 읽는 기초다. 직접 암호 알고리즘이나 프로토콜을 설계할 근거는 아니다.

가장 먼저 지킬 원칙은 검증된 라이브러리와 프로토콜을 쓰고, 키·nonce·salt·파라미터를 임의로 조합하지 않는 것이다.

MIT Missing Semester: Security and Cryptography

다섯 개념을 먼저 나누면

개념	입력과 출력	주된 목적	대표적인 오해
엔트로피	선택 과정 → 예측 불가능성의 척도	비밀값을 얼마나 맞히기 어려운지 설명	겉보기 복잡성만으로 계산할 수 있다
암호학적 해시	임의 길이 입력 → 고정 길이 digest	무결성 확인, 서명 전 처리 등	비밀번호 저장에도 빠른 SHA를 쓰면 된다
비밀번호 해싱·KDF	비밀번호·salt·비용 파라미터 → verifier 또는 key	추측 한 번의 비용을 높이기	salt를 비밀로 숨겨야 한다
대칭키 암호	같은 비밀키로 암호화·복호화	데이터 기밀성, 인증된 암호화	AES라는 이름만 고르면 변조도 막힌다
공개키 암호·서명	공개키와 개인키의 서로 다른 역할	키 교환, 암호화, 서명·검증	서명은 개인키로 암호화하는 것이다

같은 서비스에서도 이 도구들은 함께 쓰인다. 예를 들어 파일 암호화 프로그램은 passphrase를 KDF에 넣어 키를 만들고, 그 키로 인증된 대칭 암호화를 수행할 수 있다. 공개키 방식은 대칭키를 안전하게 합의하거나 서명을 검증하는 데 쓰인다.

엔트로피는 문자열 모양보다 생성 과정을 본다

가능한 결과가 N개이고 각 결과를 균등하고 독립적으로 고른다면 엔트로피는 다음과 같이 계산할 수 있다.

H = log2(N) bits

공정한 동전 한 번은 1bit, 여섯 면 주사위 한 번은 약 2.58bit다. 그러나 사람이 고른 비밀번호는 보통 균등 분포가 아니다. 대문자를 맨 앞에 놓고 숫자와 느낌표를 끝에 붙이는 패턴까지 공격자가 알고 있다면, 문자 종류만 세어 계산한 값은 실제 추측 난도를 과대평가한다.

그래서 온라인 로그인과 유출된 해시를 공격하는 오프라인 상황을 고정된 40bit, 80bit 하나로 나누는 방식은 실무 기준으로 쓰기 어렵다. 2025년에 확정된 NIST SP 800-63B-4는 길이, 흔한·유출된 비밀번호 차단 목록, 시도 횟수 제한, 안전한 저장을 함께 다룬다. 사용자 입장에서는 비밀번호 관리자로 서비스마다 길고 고유한 값을 생성하고, 가능한 곳에서는 피싱 저항성이 있는 다중 인증을 더하는 편이 현실적이다.

일반 해시와 비밀번호 저장은 다른 문제다

암호학적 해시 함수는 같은 입력에 같은 digest를 만들고, 입력이나 충돌을 실용적인 시간 안에 찾기 어렵도록 설계된다. NIST FIPS 180-4는 SHA-2 계열을 포함한 Secure Hash Standard를 설명한다.

파일을 받은 뒤 공식 사이트의 SHA-256 값과 비교하는 것은 전송 중 손상이나 다른 파일로의 교체를 확인하는 한 단계다. 다만 해시 값을 파일과 같은 신뢰할 수 없는 위치에서 함께 받았다면 진위를 보장하지 못한다. digest를 제공한 채널이나 전자서명까지 신뢰할 수 있어야 한다.

비밀번호 저장에는 SHA-256처럼 빠른 범용 해시를 그대로 쓰지 않는다. 공격자도 같은 계산을 매우 빠르게 반복할 수 있기 때문이다. 비밀번호별 무작위 salt와 비용 파라미터를 사용하는 전용 password hashing scheme을 선택한다. RFC 9106는 메모리 사용량까지 비용으로 만드는 Argon2와 기본 지원 변형인 Argon2id를 정의한다.

저장: password_hash(password, unique_salt, cost_parameters)
검증: 같은 salt·파라미터로 계산한 결과를 저장값과 비교

salt는 사용자마다 같은 비밀번호가 같은 결과를 만들지 않게 한다. 공개되어도 되는 값이며 비밀번호와 함께 저장한다. 반대로 애플리케이션 전역의 추가 비밀값인 pepper를 쓴다면 별도 secret manager와 회전 절차가 필요하다. 알고리즘과 비용은 프레임워크의 검증된 구현을 사용하고 서버 성능에 맞춰 주기적으로 재평가한다.

대칭키 암호화는 기밀성과 무결성을 함께 본다

대칭 암호는 송신자와 수신자가 같은 비밀키를 공유한다. AES 표준인 FIPS 197은 AES-128·192·256 블록 암호를 정의한다. 그러나 “AES를 사용했다”는 말만으로 전체 설계가 안전해지는 것은 아니다.

실제 사용에서는 다음 항목이 함께 정해져야 한다.

• 인증된 암호화 모드(AEAD)와 라이브러리 API
• 키 생성과 보관, 접근 권한, 회전 정책
• nonce의 길이와 재사용 금지 조건
• 암호문과 인증 tag의 저장 형식
• 복호화 실패를 처리하고 기록하는 방법

기밀성만 제공하는 조합은 공격자가 암호문을 변조했는지 확인하지 못할 수 있다. 새 설계라면 라이브러리가 제공하는 AES-GCM이나 ChaCha20-Poly1305 같은 AEAD API를 우선 검토하되, nonce 규칙과 키 관리까지 해당 라이브러리 문서대로 따라야 한다.

공개키 암호화와 전자서명은 역연산 관계가 아니다

비대칭 방식은 공개해도 되는 키와 소유자만 지켜야 하는 개인키를 나눈다. 하지만 모든 공개키 알고리즘이 암호화와 서명을 둘 다 제공하는 것은 아니다.

암호화: recipient public key → ciphertext → recipient private key로 복호화
서명:   signer private key → signature → signer public key로 검증

전자서명을 “개인키로 암호화하고 공개키로 복호화한다”라고 외우면 알고리즘의 목적과 보안 조건을 놓치기 쉽다. 서명은 메시지의 기밀성을 주는 기능이 아니라, 메시지와 서명자의 키가 연결되어 있고 내용이 바뀌지 않았음을 검증하는 기능이다.

SSH 공개키 인증에서도 클라이언트는 서버에 개인키를 보내지 않는다. 프로토콜이 정한 인증 데이터에 서명해 해당 개인키를 보유했다는 사실을 증명한다. SSH 키의 사용과 호스트 검증은 SSH 키 인증과 보안 기준에서 이어서 볼 수 있다.

공개키가 누구의 것인지 확인하는 일이 남는다

공개키를 받았다는 사실만으로 소유자를 알 수는 없다. 중간자가 자신의 키를 대신 전달하면 암호 수학이 멀쩡해도 상대를 잘못 믿게 된다.

환경마다 신뢰를 연결하는 방식이 다르다.

• 웹 TLS는 신뢰한 인증기관, 인증서의 이름·유효기간·체인을 확인한다.
• SSH는 known_hosts에 기록한 호스트 키와 이후 연결의 키를 비교한다.
• 메신저는 안전 번호나 QR 코드를 별도 채널에서 대조할 수 있다.
• 소프트웨어 서명은 배포자가 공개한 키와 서명 검증 절차를 따른다.

처음 본 키를 무조건 받아들이는 것과, 다른 채널에서 fingerprint를 확인하는 것은 보장 수준이 다르다. 도구가 어떤 신뢰 모델을 쓰는지 모른 채 “암호화됨” 표시만 확인해서는 충분하지 않다.

일상에서 적용할 최소 기준

1. 서비스마다 고유한 비밀번호를 비밀번호 관리자로 생성한다.
2. 가능한 경우 다중 인증을 켜고 복구 수단도 안전하게 보관한다.
3. 비밀번호는 평문이나 빠른 범용 해시가 아니라 전용 password hashing scheme으로 저장한다.
4. 노트북과 휴대기기는 운영체제가 제공하는 전체 디스크 암호화를 사용한다.
5. SSH·Git 서명 키의 개인키에는 passphrase를 설정하고 노출 시 폐기·교체한다.
6. 암호 알고리즘을 직접 구현하지 않고, 검토된 라이브러리의 높은 수준 API를 사용한다.
7. 키와 토큰은 로그, 셸 기록, 저장소에 남기지 않는다.

HMAC처럼 키가 들어가는 무결성 도구는 HMAC 키 공유와 관리 기준과 연결해서 읽으면 해시와 MAC의 차이가 더 선명해진다.

정리

엔트로피는 비밀값이 만들어진 과정을, 해시는 데이터의 digest를, KDF와 password hashing은 추측 비용을 다룬다. 대칭키 암호는 효율적인 데이터 보호에, 공개키 암호와 서명은 키 공유·인증·무결성 확인에 각각 쓰인다.

어떤 알고리즘 이름을 골랐는가보다 더 중요한 질문은 세 가지다. 무엇을 보호하려는가, 키를 누가 어떻게 관리하는가, 공격자가 통제할 수 있는 입력과 채널은 어디인가. 이 질문에 답하지 못한다면 직접 조합하기보다 검증된 기본값으로 돌아가는 편이 안전하다.

참고 자료

• MIT Missing Semester: Security and Cryptography
• NIST SP 800-63B-4: Authentication and Authenticator Management
• NIST FIPS 180-4: Secure Hash Standard
• RFC 9106: Argon2
• NIST FIPS 197: Advanced Encryption Standard
• RFC 8439: ChaCha20 and Poly1305 for IETF Protocols