HKDF는 먼저 PRK = HMAC-Hash(salt, IKM)으로 입력 키 재료에서 의사난수 키를 뽑고, 이어 PRK와 info로 필요한 길이의 키 재료를 확장합니다. 출력은 255×HashLen 바이트 이하입니다. 이 글은 2026-10-27에 연 RFC 5869(Informational, 2010년 5월)로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
추출 단계는 무엇을 할까?
HKDF-Extract(salt, IKM)은 HMAC에서 salt를 키로, IKM을 메시지로 써서 PRK를 만듭니다. 원문은 이 단계에서 IKM이 HMAC의 입력이라는 점에 주의하라고 적습니다. 추출은 이미 가진 엔트로피를 모을 뿐 늘리지는 못합니다.
| 이름 | 원문 설명 |
|---|---|
| salt | 선택, 비밀이 아닌 무작위 값, 없으면 HashLen개의 0 |
| IKM | 입력 키 재료 |
| PRK | 추출 결과, HashLen 바이트 |
| info | 선택, 문맥 정보, 길이 0도 가능 |
| L | 출력 길이, 255×HashLen 이하 |
| OKM | 출력 키 재료, T의 앞 L바이트 |
확장 단계의 카운터는 어떻게 붙을까?
N=ceil(L/HashLen)이고 T(0)은 빈 문자열입니다. T(1)=HMAC-Hash(PRK, T(0) | info | 0x01), T(2)=HMAC-Hash(PRK, T(1) | info | 0x02)처럼 이어 가며, 끝에 붙는 상수는 한 바이트입니다. T(1)부터 T(N)까지 이어 붙인 앞 L바이트가 OKM입니다. 바이트 카운터가 하나이므로 N이 255를 넘을 수 없고, 해시 출력이 32바이트라면 최대 8,160바이트입니다.
salt와 info는 어떻게 다를까?
salt는 비밀일 필요가 없고 재사용할 수 있으며, 이상적으로는 HashLen 길이의 무작위 값입니다. 다만 공격자가 고르거나 조작하는 값이어서는 안 됩니다. info는 프로토콜 번호, 알고리즘 식별자, 사용자 신원 같은 문맥을 파생 키에 묶어 같은 IKM에서 다른 용도의 키가 같게 나오지 않게 합니다. 지갑에서 문구를 더해 키 공간을 나누는 기능은 하드웨어 지갑 패스프레이즈 글에서 다룹니다.
어디에 쓰려고 만든 설계일까?
원문은 약한 난수원에서 의사난수를 만드는 일, Diffie-Hellman 공유값에서 키를 뽑는 키 합의, 하이브리드 공개키 암호화에서 대칭 키를 파생하는 일, 키 래핑을 용도로 듭니다. 이 모든 용도에 단순하고 다목적이라는 점이 장점이라고 설명합니다.
추출을 건너뛰거나 비밀번호에 써도 될까?
IKM이 이미 강한 키라면 추출을 건너뛸 수 있습니다. 그러나 Diffie-Hellman 값이면 건너뛰지 말아야 한다고 원문이 못박습니다. L이 HashLen 이하여도 PRK를 그대로 쓰는 것은 권장하지 않습니다. 비밀번호처럼 엔트로피가 낮은 입력에는 느리게 만드는 장치가 HKDF에 없으므로 PKCS5 같은 방식을 검토하라고 합니다. 니모닉 문구에서 시드를 만드는 규칙은 이 문서에 없으며 BIP39 체크섬 글에서 이어 볼 수 있습니다.
자주 묻는 질문
salt 없이 HKDF를 써도 되나요?
정의상 가능하며 HashLen개의 0으로 채웁니다. 다만 원문은 salt를 쓰면 강도가 크게 높아지므로 구할 수 있다면 제공하라고 권합니다.
info를 비워 둘 수 있나요?
정의상 선택 입력이고 길이 0도 허용됩니다. 원문은 실제 응용에서는 매우 중요한 경우가 많다고 설명합니다.
info는 IKM과 어떤 관계여야 하나요?
원문이 둔 기술적 요건은 info가 IKM 값과 독립이어야 한다는 것 하나입니다.
