암호화 기초
암호화 방식
| 방식 | 키 | 속도 | 용도 |
|---|
| 대칭키 (AES) | 동일 키 | 빠름 | 데이터 암호화 |
| 비대칭키 (RSA) | 공개키+개인키 | 느림 | 키 교환, 서명 |
| 해시 (SHA, bcrypt) | 키 없음 (단방향) | - | 비밀번호 저장 |
HTTPS (TLS) 동작 과정
- 클라이언트 → 서버: 지원하는 암호화 방식 전송
- 서버 → 클라이언트: 인증서(공개키 포함) 전송
- 비대칭키로 대칭키 교환
- 이후 대칭키로 통신 (성능 때문)
무엇을 지켜 주고 무엇을 못 지켜 주나
암호화는 오가는 길과 저장된 것을 지킵니다. 그 밖은 지켜 주지 않습니다.
| 지켜 주는 것 | 못 지켜 주는 것 |
|---|
| 중간에서 엿보는 것 | 서버에 이미 들어온 뒤의 처리 |
| 저장 매체를 통째로 가져가는 것 | 권한이 있는 계정으로 조회하는 것 |
| 오가는 값을 바꿔치기하는 것 | 잘못 만든 권한 검사 |
그래서 암호화를 켰다는 것이 안전하다는 뜻이 아닙니다. 실제 사고는 대개 권한 검사나
새어 나간 키에서 납니다.
키가 새면 되돌릴 수 없다
암호문을 지키는 것은 키뿐입니다. 키가 새면 그 키로 잠근 모든 것이 열립니다.
코드와 저장소에 키를 두지 않는다
로그와 오류 메시지에 값이 찍히지 않게 한다
바꿀 수 있게 만들어 둔다. 언젠가 바꿔야 한다
마지막이 자주 빠집니다. 키를 바꾸려면 옛 키로 잠근 것을 새 키로 다시 잠그는 경로가
있어야 하고, 그것을 처음에 만들어 두지 않으면 나중에는 바꾸지 못합니다.
실무 포인트
- 비밀번호 저장: bcrypt/scrypt 사용 (MD5/SHA 금지!)
- JWT 서명: HMAC(대칭) vs RSA(비대칭) 선택
- API 키, DB 비밀번호: 환경변수로 관리, 코드에 하드코딩 금지
Q.대칭키 vs 비대칭키 암호화 차이는?
키가 하나인지 한 쌍인지의 차이이고, 거기서 속도와 용도가 갈립니다.
| 항목 | 대칭키 | 비대칭키 |
|---|
| 키 | 같은 키로 암호화와 복호화 | 공개키로 암호화, 개인키로 복호화 |
| 속도 | 빠르다 | 수백에서 수천 배 느리다 |
| 키 전달 | 상대에게 안전하게 줄 방법이 필요하다 | 공개키는 그냥 공개해도 된다 |
| 용도 | 대량 데이터 암호화 | 키 교환, 전자 서명 |
| 예 | AES, ChaCha20 | RSA, 타원곡선 |
비대칭키가 해결한 문제는 키 전달입니다. 처음 만난 상대와 사전 공유 없이 안전한 채널을 만들 수 있습니다.
흔한 실수: 비대칭키가 더 안전하다고 답하는 것. 안전성의 차원이 아니라 해결하는 문제가 다릅니다. 같은 보안 강도를 기준으로 보면 대칭키가 짧은 키로 같은 강도를 냅니다.
Q.HTTPS에서 두 방식을 함께 쓰는 이유는?
각자의 장점만 쓰기 위해서입니다. 비대칭키로 키를 나누고, 대칭키로 데이터를 나릅니다.
핸드셰이크 (비대칭키)
서버 인증서로 서버가 진짜인지 확인한다
이 구간에서 양쪽이 같은 대칭키를 안전하게 만든다
이후 통신 (대칭키)
만든 대칭키로 실제 데이터를 암호화한다
비대칭키만 쓰면 느려서 실용적이지 않습니다. 대칭키만 쓰면 그 키를 처음에 어떻게 전달하느냐가 풀리지 않습니다. 그래서 비싼 방식으로 한 번, 싼 방식으로 계속이 됩니다.
흔한 실수: 서버 공개키로 대칭키를 암호화해 보낸다고만 설명하는 것. 그 방식(RSA 키 전송)은 개인키가 나중에 유출되면 과거 통신까지 복호화됩니다. 현재는 매 연결마다 임시 키를 만드는 방식을 써서 과거 통신을 보호합니다.
Q.비밀번호를 DB에 어떻게 저장해야 하나요?
무작위 값을 섞어 느린 해시로 저장합니다. 암호화가 아니라 해시라는 점이 핵심입니다.
| 방식 | 판정 |
|---|
| 평문 | 불가 |
| 암호화 (AES) | 불가. 키가 유출되면 전부 복호화된다 |
| 빠른 해시 (SHA-256) | 부족. 초당 수십억 번 시도할 수 있다 |
| 솔트 + 느린 해시 (bcrypt, Argon2) | 권장 |
암호화가 아니라 해시를 쓰는 이유는 원문을 되돌릴 필요가 없기 때문입니다. 로그인은 입력값을 같은 방식으로 해시해 비교하면 됩니다. 되돌릴 수 없으니 유출돼도 원문이 새지 않습니다.
저장할 것: 알고리즘, 비용 계수, 솔트, 해시값
흔한 실수: 솔트를 따로 안전하게 보관해야 한다고 답하는 것. 솔트는 비밀이 아니고 해시와 함께 저장합니다. 목적은 은닉이 아니라 같은 비밀번호가 다른 해시를 갖게 해서 미리 계산한 표를 무력화하는 것입니다.
Q.bcrypt vs SHA-256 차이는?
설계 목적이 반대입니다. SHA-256은 빠르려고, bcrypt는 느리려고 만들었습니다.
| 항목 | SHA-256 | bcrypt |
|---|
| 목적 | 무결성 검증, 서명 | 비밀번호 저장 |
| 속도 | 매우 빠르다 | 의도적으로 느리다 |
| GPU 가속 | 잘 된다 | 메모리를 써서 방해한다 |
| 비용 조절 | 없다 | 비용 계수로 조절한다 |
| 솔트 | 직접 붙여야 한다 | 내장 |
비밀번호에 빠른 해시가 위험한 이유는 공격자에게도 빠르기 때문입니다. GPU로 SHA-256은 초당 수십억 번 시도할 수 있는데, bcrypt cost 12는 한 번에 250ms 안팎입니다.
흔한 실수: SHA-256을 여러 번 반복하면 된다고 답하는 것. 방향은 맞지만 GPU 병렬화에 여전히 취약합니다. bcrypt와 Argon2는 메모리를 요구해 병렬화 자체를 비싸게 만듭니다. 새로 만든다면 Argon2id 가 현재 권고안입니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
보안 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.