암호화 기초, 헷갈리는 지점부터
AWS KMS 노트를 정리하면서 봉투 암호화 개념은 익혔는데, 그 아래 깔린 대칭/비대칭 암호화 기본기를 별도로 정리해두지 않았다는 걸 깨달아서 여기 채워둠
대칭키 vs 비대칭키
| 구분 | 키 | 속도 | 대표 용도 |
|---|---|---|---|
| 대칭키(Symmetric) | 암호화/복호화에 같은 키 | 빠름 | 대용량 데이터 암호화 (AES) |
| 비대칭키(Asymmetric) | 공개키로 암호화, 개인키로 복호화 (또는 그 반대) | 느림 | 키 교환, 전자서명 (RSA, ECC) |
실무에서는 거의 항상 둘을 섞어 쓴다 — TLS가 대표적인 예시임
TLS 핸드셰이크 감각 (단순화)
1. 클라이언트 → 서버: "TLS 버전, 지원 암호 스위트 목록 보낼게"
2. 서버 → 클라이언트: "인증서(공개키) + 선택한 암호 스위트"
3. 클라이언트: 인증서 검증(CA 체인 확인) 후, 비대칭 암호화로 대칭키 재료 교환
4. 이후 통신은 교환된 대칭키로 빠르게 암호화
즉 “느리지만 안전한 비대칭키로 세션을 열고, 그 안에서는 빠른 대칭키로 통신”하는 구조임 AWS 봉투 암호화의 “평문 데이터 키로 로컬 암호화 후 즉시 폐기”와 발상이 비슷함
해싱은 암호화가 아니다
- 암호화: 되돌릴 수 있음 (복호화 키로 원문 복원)
- 해싱: 일방향, 원칙적으로 되돌릴 수 없음 (같은 입력 → 같은 해시, 역산 불가)
자주 하는 실수
“비밀번호를 암호화해서 저장했다”는 틀린 표현인 경우가 많음 비밀번호는 해싱(+솔트) 해서 저장해야 함 암호화는 나중에 원문이 필요할 때 쓰는 방식이고, 비밀번호는 원문이 다시 필요할 일이 없어야 정상임
인증서 체인 감각
Root CA (자체 서명, OS/브라우저에 미리 신뢰 등록됨)
└─ Intermediate CA (Root가 서명)
└─ 최종 서버 인증서 (Intermediate가 서명)
브라우저가 서버 인증서를 신뢰하는 이유는, 그 인증서를 서명한 체인을 타고 올라가면 결국 “이미 신뢰하기로 약속된 Root CA”에 도달하기 때문임 체인 중간에 끊기거나 만료된 인증서가 있으면 전체가 불신 처리됨
더 생각해볼 것들
- 대칭키만으로는 왜 안전한 키 교환이 어려운지 내 말로 설명할 수 있을까 (키를 어떻게 안전하게 처음 나눠 가지는가의 문제)
- 자체 서명 인증서(self-signed)가 왜 브라우저에서 경고를 띄우는지, Root CA 체인 개념으로 설명해보기