HKDF 키 유도 (RFC 5869, 추출·확장)

HKDF는 강한 비밀 하나를 필요한 만큼의 독립적인 키로 바꿔 주는 키 유도 함수이고, 한 단계가 아니라 두 단계입니다. 추출(extract)은 입력 키 재료를 고정 길이 의사난수 키로 압축합니다. PRK = HMAC-Hash(salt, IKM)이고, 추출 단계는 그것이 전부입니다. 확장(expand)은 그 PRK를 HMAC 연쇄로 원하는 길이까지 늘립니다. T(i) = HMAC(PRK, T(i-1) ‖ info ‖ i)를 이어 붙여 길이만큼 자릅니다. 이 페이지는 둘 다 보여 주는데, 브라우저는 보여 주지 않기 때문에 그게 중요합니다.

crypto.subtle.deriveBits는 추출과 확장을 한 호출로 합쳐 놓고 PRK를 절대 돌려주지 않습니다. HKDF 키 객체는 내보낼 수도 없어서 바이트를 요구하면 InvalidAccessError가 납니다. 즉 API를 통해서는 중간값을 볼 방법이 아예 없습니다. 그래서 이 도구는 두 단계를 HMAC으로 직접 계산해 PRK와 각 T 블록을 출력하고, 그다음 브라우저에 같은 답을 물어 둘이 일치하는지 알려 줍니다. 두 구현이 합의하는 것이 하나가 주장하는 것보다 값집니다.

info 필드는 대부분 그냥 건너뛰는 부분이자, HKDF가 지금 같은 모양인 이유입니다. 같은 IKM과 솔트에 info만 다르면 서로 계산 가능한 관계가 없는 키가 나옵니다. TLS 1.3이 하나의 핸드셰이크 비밀에서 방향별·용도별 키를 따로 얻는 방식이 바로 이것이고, 긴 출력 하나를 조각내 나눠 쓰며 잘 되기를 바라는 것과는 다릅니다. 한 비밀에서 여러 키를 뽑는다면 그 키들은 오프셋이 아니라 info로 달라야 합니다.

명세가 두는 제한 두 가지는 브라우저도 강제합니다. 출력은 255 × HashLen으로 제한됩니다. SHA-256이면 8160바이트입니다. 확장 안에서 붙이는 블록 카운터가 1바이트이기 때문입니다. 더 요구하면 이 페이지와 deriveBits 둘 다 거부합니다. 그리고 솔트가 없으면 0 바이트 HashLen개로 바뀌는데, 이는 관례처럼 들리다가 직접 해 보면 달라집니다. Web Crypto는 길이 0인 HMAC 키를 DataError: HMAC key data must not be empty로 거부하므로, 그 대체 없이는 브라우저에서 추출 단계를 계산할 수조차 없습니다.

프리셋 네 개는 RFC 5869의 테스트 케이스 1, 3, 4, 7이라서 한 번 눌러 명세와 대조할 수 있습니다. 케이스 1의 PRK는 077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5이고 OKM은 3cb25f25faacd57a로 시작합니다. 케이스 3은 같은 IKM에 솔트도 info도 없는 경우인데, 결과가 완전히 다른 곳에 떨어집니다 — 19ef24a32c717b16… — 추출 단계가 형식적인 절차가 아니기 때문입니다.

HKDF가 아닌 것 하나. 비밀번호용 KDF가 아닙니다. 출력 블록마다 HMAC을 한 번 돌릴 뿐 반복 횟수도 메모리 비용도 없어서, 비밀번호를 찍어 보는 공격자에게 아무 부담도 주지 않습니다. 입력이 이미 엔트로피가 높다고 가정합니다. 비밀번호라면 PBKDF2, scrypt, Argon2를 쓰세요.