HMAC, PBKDF2 및 HKDF 계산기

HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 또는 HMAC-SHA-512(RFC 2104)로 텍스트, hex 바이트, 파일 전체에 키가 있는 메시지 인증 코드를 계산합니다 — 키는 텍스트, hex, Base64. 또는 PBKDF2(RFC 8018)와 HKDF(RFC 5869)로 키를 유도합니다. 모든 결과는 hex, 대문자 hex, Base64, Base64url로 표시할 수 있습니다. 일반 다이제스트는 해시 생성기, 체크섬은 CRC 계산기, JWT 안에서 쓰이는 HMAC은 JWT 디코더를 보세요.
전부 로컬에서 실행됩니다 — 키와 메시지는 탭을 떠나지 않습니다. 파일은 최대 200MB.
구성: 출력:
HMAC 알고리즘: RFC 2104 — MD5 변형은 md5.js가 필요합니다(이 페이지가 로드함).
비밀 키 (공유 비밀; 어떤 길이든, 아래 텍스트는 UTF-8로 인코딩)
Hex 읽기는 공백, 콜론, 0x 접두사를 허용합니다; Base64는 패딩 있/없는 표준형이어야 합니다.
빈 키는 RFC 2104상 적법하지만 거의 항상 실수입니다.
메시지 텍스트 (인증할 데이터, 아래 텍스트는 UTF-8)
HMAC 출력 (한 줄: 구성, 매개변수, 값)
첫 줄에 사용된 정확한 매개변수(알고리즘, 읽기 방식, 길이)가 기록됩니다.
어떤 구성이 필요한가?
HMAC은 공유 비밀과 메시지를 인증자로 바꿉니다. 키를 아는 수신자가 그것을 다시 계산해 변조를 감지할 수 있습니다. 서명된 모든 JWT의 "HS256"이 그것이며(참조: JWT 디코더) 세계의 API 요청 서명 방식 절반의 반쪽입니다. PBKDF2는 사람 비밀번호를 키로 늘리는 용입니다. HMAC을 수천 번 반복해 각 비밀번호 추측이 공격자에게 같은 지연 비용을 물립니다. HKDF는 프로토콜 키용입니다. 이미 무작위인 비밀 바이트(예: DH 공유 비밀)를 받아 여러 용도가 묶인 키로 안전하게 확장합니다 — TLS 1.3이 모든 트래픽 키를 이렇게 유도합니다. 경험칙: 인증 → HMAC, 비밀번호 → PBKDF2(또는 scrypt/Argon2, 비밀번호 해시 생성기 참조), 균일한 비밀 → HKDF.
자체 테스트
페이지 엔진을 공개 벡터에 대해 돌립니다. HMAC 앵커 10개(RFC 2202/4231 방식, 다섯 알고리즘 × 두 입력), PBKDF2 앵커 6개(SHA-1과 SHA-256을 세 반복 수에서), RFC 5869 HKDF 테스트 케이스 A.1~A.4 네 개. 아무것도 전송되지 않습니다.
HMAC, PBKDF2, HKDF — 키 해싱 설명
한 문장 요약: SHA-256 같은 맨 해시는 누구나 계산할 수 있어 누가 메시지를 보냈는지 아무것도 증명하지 못합니다 — HMAC은 비밀 키를 섞어 키 보유자만 다이제스트를 만들(또는 검증할) 수 있게 하고, PBKDF2와 HKDF는 그 같은 HMAC 기계를 재사용해 비밀을 키로 바꿉니다. 비밀번호에는 느리게, 이미 무작운 소재에는 빠르게.
HMAC란 (RFC 2104)

구성. HMAC은 해시 한 번이 아니라 두 번입니다. 키는 해시의 블록 크기로 채워지고(MD5/SHA-1/SHA-256은 64바이트, SHA-384/512는 128바이트), 메시지는 키 XOR 고정 안쪽 패드로 한 번 해시되고 그 다이제스트는 키 XOR 고정 바깥쪽 패드로 다시 해시됩니다. 이 이중 샌드위치는 이면 해시가 괜찮은 유사난수 함수인 한 증명 가능하게 안전합니다 — HMAC-MD5가 맨 MD5를 부순 실용적 충돌 공격에도 여전히 저항하는 이유입니다(그래도 은퇴했지만, 아래 참조).

키. 어떤 길이든 작동합니다. 블록보다 짧으면 그대로 쓰이고(32바이트 미만은 권장하지 않음) 길면 먼저 해시됩니다. 같은 페이지에서 키를 텍스트, hex, Base64로 입력할 수 있어 64자 hex 운영 키를 64자 텍스트 비밀번호로 오독하지 않고 붙여넣을 수 있습니다 — 출력 줄에 읽기 방식이 기록되는 것이 정확히 그 이유입니다.

어디서 만나는가. JWT 헤더의 HS256 필드는 문자 그대로 base64url 인코딩된 토큰 부분들에 대한 HMAC-SHA-256입니다(이 사이트의 JWT 디코더는 HS256 비밀을 붙여넣으면 정확히 그것을 계산합니다). 웹훅 서명(Stripe, GitHub), AWS SigV4, TLS 레코드 보호(구버전), OpenSSH의 umac-64@openssh.com 사촌까지 모두 같은 계열입니다.

그냥 hash(메시지 || 키)는 안 되나? 길이 확장 때문입니다. MD5/SHA-1/SHA-2 계열의 모든 해시는 H(비밀 || 메시지)를 아는 공격자가 비밀 없이 H(비밀 || 메시지 || 패딩 || 아무거나)를 계산하게 합니다. HMAC의 안팎 분할이 그 공격 계열을 죽입니다. API 서명 코드에서 가장 흔한 DIY 실수이며 — HMAC이 존재하는 이유입니다.

PBKDF2란 (RFC 8018)

설계상 느림. 비밀번호는 어쩌다 실제 엔트로피 40비트 정도이고 공격자의 GPU는 초당 수십억 번의 맨 SHA-256을 시도합니다. PBKDF2는 HMAC(비밀번호, 솔트)를 iter번 반복해 각 추측이 당신에게도 공격자에게도 같은 iter번의 HMAC 비용이 되게 합니다. 여기 기본값은 HMAC-SHA-256에 600,000 반복, OWASP 비밀번호 저장 치트시트 기준선이며, 하드웨어가 빨라질수록 보안 권고가 올라가기에 슬라이더는 천만까지 갑니다.

솔트. 비밀번호마다 무작위 솔트가 있으면 같은 사용자도 같게 해시되지 않고 사전 계산 표(레인보우 테이블)가 무가치해집니다. 비밀이 아닙니다 — 해시 옆에 저장됩니다 — 유일하기만 하면 됩니다. 무작위 16바이트가 표준입니다.

알려진 약점. PBKDF2는 CPU 하드이지 메모리 하드가 아닙니다. GPU와 ASIC이 이를 아주 잘 병렬화합니다. 그래서 비밀번호 해시 저장을 설계할 때 현대적 조언은 scrypt나 Argon2id이며(이 계열의 비밀번호 해시 생성기 페이지가 다룹니다), PBKDF2는 호환성과 FIPS-140 환경에서 여전히 올은 답입니다.

HKDF란 (RFC 5869)

추출 후 확장. HKDF는 두 일을 합니다. 추출: 어쩌면 고르지 않은 입력 키 소재(예: Diffie–Hellman 공유 비밀)를 솔트와 함께 하나의 짧은 유사난수 키 PRK = HMAC(솔트, IKM)로 누릅니다. 확장: 그 PRK를 최대 255 해시 블록까지 늘리며 각 출력 블록은 이전 것에 연결되고 info 필드로 꼬리표가 붙습니다. 결과적으로 하나의 비밀이 암호화 키, MAC 키, IV를 모두 안전하게 분리해 줄 수 있습니다.

비밀번호용이 아님. HKDF는 입력이 이미 충분한 엔트로피를 지녔다고 가정합니다 — 출력 32바이트당 HMAC 한 번이므로 사람 비밀번호는 사실상 즉시 통과하며 그것이 정확히 공격자가 바라는 것입니다. PBKDF2 대신 HKDF에 비밀번호를 먹이는 것은 고전적 설계 오류이며, info 필드는 용도 라벨("클라이언트 트래픽 키", "서버 iv")용이지 추가 엔트로피용이 아닙니다.

어디서 만나는가. TLS 1.3은 핸드셰이크 비밀에서 HKDF로 모든 키를 유도하고, WireGuard, Signal, EAP-TLS 1.3, JSON Web Encryption(직접 키 합의 KDF로)이 모두 같은 계보에 있습니다.

앵커 값 — 이 페이지에서 재현

첫 두 표는 이 페이지의 샘플 버튼과 자체 테스트가 만들어진 테스트 벡터입니다(키 "key", 메시지 "The quick brown fox jumps over the lazy dog", 그다음 16바이트 0x0b 키와 메시지 "Hi There"의 RFC 방식 사례). 모두 독립적인 네이티브 구현으로 생성되었고 이 페이지에서 재검증되었습니다.

"fox"의 HMAC, 키 = key다이제스트 (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
KDF 앵커매개변수출력 (hex, 첫 바이트)
PBKDF2-HMAC-SHA-1비밀번호 / 솔트, c=4096, 32바이트4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256비밀번호 / 솔트, c=4096, 32바이트c5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
HKDF-SHA-256 (RFC 5869 A.1)IKM=0x0b×22, 솔트=00..0c, info=f03cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
HKDF-SHA-256 (RFC 5869 A.2)IKM=00..4f, 솔트=60..af, info=b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c…
HKDF-SHA-256 (RFC 5869 A.3)IKM=0x0b×22, 빈 솔트와 info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
흔한 실수
  • HMAC을 암호화와 혼동. HMAC은 (공유 비밀이 주어졌을 때) 무결성과 출처를 증명합니다. 아무것도 숨기지 않습니다. 키 없는 사람은 메시지 전체를 여전히 봅니다.
  • HMAC을 서명과 혼동. 디지털 서명은 공개 키입니다. 한 명이 서명하고 모두가 검증합니다. HMAC은 대칭입니다. 모든 검증자가 위조도 할 수 있습니다. 부인 방지가 필요하면 HMAC이 아니라 RSA/ECDSA(이 계열의 RSA 도구 참조)가 필요합니다.
  • 키 읽기 불일치. 텍스트 키 칸에 붙여넣은 64자 hex 문자열은 32바이트가 아니라 64바이트가 되며 — HMAC이 완전히 달라집니다. 이 페이지는 출력 줄에 읽기 방식을 인쇄합니다. 두 도구가 다를 때 가장 먼저 비교할 것입니다.
  • PBKDF2 반복이 너무 낮음. 1,000회는 2000년엔 합리적이었습니다. 오늘날 GPU 랙이 그것을 집어삼킵니다. 시스템이 아직 1,000회 해시를 저장한다면 로그인 시 재해시 마이그레이션을 계획하세요.
  • 비밀번호에 HKDF. 출력 블록당 HMAC 한 번은 비밀번호가 즉시 통과한다는 뜻입니다 — 비밀번호에는 PBKDF2(또는 Argon2id), 고엔트로피 비밀에는 HKDF를 쓰세요.
  • 하나의 유도 키를 모든 용도에 재사용. 수정은 공짜입니다. 서로 다른 info 라벨로 별도 키를 유도하세요. 다른 라벨의 두 키는 설계상 독립입니다.
FAQ

HMAC-MD5는 깨졌나? 충돌 저항 해시로서 MD5는 죽었지만 HMAC-MD5의 보안은 유사난수 함수로서의 MD5에 달렸고 실용적 파괴는 알려지지 않았습니다. 그래도 은퇴했습니다 — 구 프로토콜 호환 외에 HMAC-SHA-256 대신 고를 이유가 없습니다.

HMAC 키는 얼마나 길어야 하나? 최소한 해시 출력 크기(SHA-256의 32바이트) 이상이고 CSPRNG로 생성되어야 합니다. 다이제스트보다 짧은 키도 허용되지만 그 아래의 모든 비트가 보안을 직접 깎습니다.

PBKDF2는 반복이 늘수록 무한히 "더 안전"해지나? 공격자 비용을 선형으로 올리지만 로그인 비용도 선형으로 올립니다. 게임은 사용자가 견딜 가장 큰 수를 고르는 것입니다 — OWASP 숫자가 그것을 보정합니다.

HKDF가 255 × 해시 크기에서 막히는 이유는? 확장 루프는 T(i) = HMAC(PRK, T(i-1) || info || i)이며 1바이트 카운터 i를 씁니다 — 255가 카운터 최대값이고 RFC 5869의 굳은 구조적 한계입니다. 정책 선택이 아닙니다.

이 페이지의 PBKDF2와 비밀번호 해시 생성기의 차이는? 같은 알고리즘, 다른 임무. 이 페이지는 다른 곳에 쓸 날 키 바이트를 유도하고, 비밀번호 해시 페이지는 (솔트와 매개변수가 내장된) 저장용 자격 증명 문자열을 만들고 붙여넣은 후보를 검증합니다.