본문으로 건너뛰기

HMAC 생성

HMAC Generator

해시 종류와 키 인코딩을 정해 메시지의 HMAC을 계산합니다. 웹훅 서명 확인에 씁니다.

텍스트나 파일에 대해 HMAC — 키를 쓰는 해시값 — 을 계산합니다. 키는 텍스트·16진수·Base64로 읽을 수 있습니다. 해시 도구에서 HMAC 쪽을 켠 화면과 같습니다. HMAC은 키가 붙은 해시일 뿐이고, 나눠 두면 모든 조작부를 공유하는 페이지가 둘이 되기 때문입니다.

🔒 브라우저 안에서만 처리hmacsignaturewebhookcrypto
출력 형식

입력

체크섬을 낼 파일 놓기

이 탭에서 읽습니다. 올라가지 않습니다.

텍스트는 UTF-8 바이트로 해싱합니다. 다른 도구들이 문자열 해싱이라고 할 때의 그 방식입니다.

해시값

공개된 체크섬을 붙여넣으면 일치하는 줄이 표시됩니다.

알고리즘마다 한 줄. 해시값과 복사 버튼이 함께 있습니다.
알고리즘해시값복사
MD5충돌을 만들어 내는 비용이 쌉니다. 체크섬으로는 괜찮지만 서명이나 비밀번호에는 쓰지 마세요.
SHA-1충돌이 실제로 시연됐습니다. 예전부터 쓰던 체크섬이라면 몰라도 새로 쓸 것은 아닙니다.
SHA-256
SHA-384
SHA-512
CRC-32해시가 아니라 오류 검출 코드입니다. 두 파일이 우연히도 같은 값을 가질 수 있고, 일부러라면 더 쉽습니다.

입력

0byte

출처

텍스트 상자

사용 방법

  1. HMAC을 켭니다

    키 입력란이 나오고 표에서 CRC-32가 빠집니다. 해시 함수가 아니라 체크섬이라 HMAC이 없습니다.

  2. 키를 어떻게 읽을지 정합니다

    HMAC이 틀어지는 자리가 대개 여기입니다. `0a1b2c`라고 쓴 키는 16진수로는 3바이트, 텍스트로는 6바이트이고, 둘은 완전히 다른 값을 냅니다.

  3. 받은 서명과 대조합니다

    비교 상자에 붙여넣으면 일치하는 줄이 표시됩니다. Stripe, GitHub, Slack의 웹훅 서명은 모두 특정 문자열에 대한 HMAC-SHA256이라, 키만큼이나 메시지를 정확히 맞추는 것이 중요합니다.

자주 묻는 질문

헤더에 온 HMAC과 왜 안 맞나요?

보통은 키가 아니라 메시지 때문입니다. 웹훅 서명은 정해진 문자열 — 대개 타임스탬프와 구분자와 원본 본문 — 에 대해 계산되고, JSON 파서를 거쳐 다시 직렬화된 본문은 다른 문자열입니다. 받은 바이트 그대로 서명하세요.

키와 메시지를 이어 붙여 해싱하는 것과 같나요?

아니고, 그게 HMAC의 존재 이유입니다. `hash(키 + 메시지)`는 MD5·SHA-1·SHA-256에서 길이 확장 공격에 취약합니다. 안쪽과 바깥쪽 패딩을 쓰는 HMAC의 2패스 구조가 그것을 없앱니다. 직접 만들지 마세요.

키가 탭 밖으로 나가나요?

아니요. 이 탭에서 WebCrypto 키를 만드는 데만 씁니다. 전송하지도, 저장하지도, URL에 넣지도 않습니다. 새로고침하면 사라지는데, 비밀에 대해서는 그게 옳은 동작입니다.

키는 얼마나 길어야 하나요?

적어도 해시값 길이만큼입니다. SHA-256이면 32바이트죠. HMAC은 어떤 길이든 받지만, 블록 크기보다 긴 키는 먼저 해싱해 줄이고, 짧은 키는 그냥 짧은 키입니다. 보안은 넣은 엔트로피만큼입니다.

이 도구로 이어지는 것

다음 단계

이 도구의 결과를 그대로 받을 수 있는 도구들입니다.