HMAC 생성기

HMAC이란?#

HMAC은 해시 기반 메시지 인증 코드(Hash-based Message Authentication Code)를 뜻합니다. 평문 해시(SHA-256 같은)는 “이 바이트 스트림이 바뀌었는가?”라는 질문에 답합니다. HMAC은 더 강한 질문에 답합니다. “이 바이트 스트림이 바뀌었는가, 그리고 이것을 내 비밀 키를 실제로 공유하는 사람이 보냈는가?”. 메시지가 온전히 신뢰할 수 없는 채널을 지날 때 이 차이가 중요해집니다. 웹훅 콜백, 서명된 URL, API 요청 서명, 서비스 간 토큰이 그런 사례입니다.

기구적으로 HMAC은 비밀 키 를 정해진 방식(패딩을 곁들인 두 라운드)으로 해시 함수에 끼워 넣어, 키 없이는 다이제스트를 위조할 수 없게 만듭니다. 출력은 고정 길이 바이트 문자열이며, 그 크기는 기반이 되는 해시와 같습니다. SHA-1은 20바이트, SHA-256은 32바이트, SHA-384는 48바이트, SHA-512는 64바이트입니다.

이 페이지는 Web Crypto API로 브라우저 안에서 HMAC을 계산합니다. 해시를 고르고, 메시지와 비밀 키를 붙여넣고, 다이제스트를 Hex 또는 Base64로 얻습니다.

사용 방법#

1. 메시지 를 타이핑하거나 붙여넣으세요. 인증하려는 페이로드입니다. 수신자가 자기 쪽에서 해싱할 바이트입니다.
2. 비밀 키 를 입력하세요. 이 필드는 기본적으로 가려져 있으며, 타이핑하는 동안 드러내려면 오른쪽의 눈 모양 버튼을 누르세요. 키와 메시지 모두 UTF-8로 인코딩됩니다.
3. 알고리즘 을 고르세요.
   • SHA-1 — 160비트. 빠르지만 레거시 HMAC에만 적합합니다(일부 오래된 서명 흐름이 여전히 이것을 요구합니다). 디지털 서명 용도로 SHA-1을 쓰지는 마세요.
   • SHA-256 — 256비트. 현대적인 기본값이며, 대부분의 웹훅 서명(Stripe, GitHub, Slack 유형 흐름)이 HMAC-SHA-256을 씁니다.
   • SHA-384 / SHA-512 — 더 긴 다이제스트, 약간 더 높은 충돌 저항, 약간 더 느림. 수신 시스템이 명시적으로 요구할 때 선택하세요.
4. 출력 형식 을 고르세요. Hex (X-Signature 유형 헤더에 전형적) 또는 Base64 (다이제스트가 JSON이나 토큰에 박힐 때 전형적).
5. 생성 을 누르세요. 다이제스트가 오른쪽 패널에 나타나고, 상태 줄은 정합성 확인용으로 알고리즘과 바이트 길이를 보여줍니다. 복사 로 가져가세요.

주요 기능#

• Web Crypto 기반. 브라우저의 네이티브 crypto.subtle을 씁니다. 실제 프로덕션 코드가 쓰는 것과 같은 원시적 기능이지, 자바스크립트 재구현이 아닙니다.
• 길이 정합성 검사. 모든 다이제스트는 해당 알고리즘의 예상 바이트 길이와 대조되어, 잘리거나 변조된 결과가 조용히 빠져나가지 않습니다.
• Hex 또는 Base64 출력. 한 번의 클릭으로 전환하며, 다시 타이핑할 필요가 없습니다.
• 비밀 키는 로컬에. 키 필드는 비밀번호 입력으로 렌더링되며 페이지를 떠나지 않습니다. 백엔드가 없습니다.
• 보안 컨텍스트 인식. 페이지가 평문 HTTP로 로딩되면 crypto.subtle을 쓸 수 없으며, 도구는 잘못된 답을 내놓는 대신 그 사실을 명시적으로 알려줍니다.

실전 예시#

고전적인 참조 쌍(RFC 4231)은 키 Jefe 에 메시지 what do ya want for nothing? 를 씁니다. 이 페이지를 SHA-256 과 Hex 로 설정하면 다이제스트는 다음과 같습니다.

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

같은 입력으로 SHA-512 로 바꾸면 다이제스트 길이가 두 배가 됩니다.

164b7a7bfcf819e2e395fbe73b56e0a387bd64222e831fd610270cd7ea2505549758bf75c05a994a6d034f65f8f0e6fdcaeab1a34d4a6b4b636e070a38bce737

둘 다 여기서 바로 재현할 수 있습니다. 예제 를 불러온 뒤 생성 을 누르세요. 이 정확한 쌍은 이 도구 자체의 테스트 스위트가 올바름을 검증하는 방식이기도 합니다. 다른 다이제스트가 나온다면 무언가가 페이지를 변조한 것입니다.

FAQ#

SHA-256과 SHA-512 중 어느 것을 써야 하나요?#

HMAC에 한해서 SHA-256이 실용적인 기본값입니다. 주요 웹훅 서명자가 모두 이것을 쓰고, 빠르며, 256비트 다이제스트는 이미 무차별 대입을 아득히 넘어선 영역입니다. SHA-512로 넘어가야 할 때는 (a) 수신 시스템이 요구하거나, (b) 새 프로토콜을 처음 설계하면서 약간의 속도 비용으로 추가 충돌 여유를 원할 때뿐입니다. 이것을 강제하는 레거시 시스템에 맞추는 게 아니라면 SHA-1은 아예 피하세요.

HMAC은 메시지를 암호화하는 것과 같나요?#

아닙니다. HMAC은 인증 만 합니다. 메시지가 변경되지 않았고 키를 쥔 사람이 보냈다는 것을 증명할 뿐입니다. 메시지 자체는 평문으로 남습니다. 기밀성도 필요하다면 HMAC을 암호화 방식과 짝지어 쓰거나, AES-GCM 같은 인증 암호화 모드를 쓰세요.

다이제스트에서 비밀 키를 복구할 수 있나요?#

아니요. 다이제스트는 메시지와 키 모두의 단방향 함수입니다. 출력에서 키를 복구하는 것은 계산상 실현 불가능합니다. 그렇다고 해서 짧거나 추측 가능한 키는 오프라인으로 후보 키를 시도하는 무차별 대입에 여전히 당할 수 있습니다. 그러니 사람이 고른 비밀번호가 아니라, 최소 128비트의 진짜 엔트로피를 가진 키를 쓰세요.

수신자가 제 서명이 맞지 않는다고 합니다. 먼저 무엇을 확인해야 하나요?#

열에 아홉은 메시지의 바이트 표현 입니다. 뒤에 붙은 줄바꿈, URL-인코딩이냐 원시 본문이냐, JSON 공백, 다른 필드 순서. 서명한 정확한 바이트와 수신자가 해싱한 정확한 바이트를, 글자 단위로 먼저 비교하세요. 다른 것은 그 다음에 확인해도 됩니다.