HMAC 생성기 (SHA-1·256·384·512)

Web Crypto로 HMAC 서명 계산 — 웹훅 페이로드 서명, API 요청 검증, hex 또는 base64.

메시지

비밀 키키 인코딩

알고리즘출력 포맷

서명

메시지와 키를 입력하세요.

사용법

메시지와 키 붙여넣기.
키 인코딩 선택(UTF-8이 가장 흔함; Stripe·GitHub UTF-8, AWS SigV4는 파생 hex 키).
알고리즘과 출력 포맷 선택 — 결과 실시간 업데이트.

자세한 설명

펼치기

비밀 키로 메시지의 HMAC을 계산합니다. SHA-1, SHA-256, SHA-384, SHA-512를 지원하고 결과는 16진수나 Base64로 읽을 수 있습니다. HMAC은 키와 메시지를 이어 붙여 해시한 것이 아니라 특정한 2단계 구성이며, 그 구조가 길이 확장 공격으로부터 지켜 줍니다. 비밀 키에 메시지를 그냥 이어 붙여 해시하는 방식이 안전하지 않은 이유가 그 공격입니다. 결제 대행사와 깃 호스팅의 웹훅 서명이 HMAC인 까닭도 여기에 있습니다. 내 서명이 상대의 서명과 맞을지를 가르는 설정은 키 인코딩입니다. 실제로는 16진수나 Base64 바이트인 비밀 키를 UTF-8 텍스트로 읽으면 완전히 다른 결과가 나옵니다. 서명에는 브라우저의 WebCrypto를 쓰며 키도 메시지도 페이지를 벗어나지 않습니다.

자주 묻는 질문

어떤 알고리즘을 써야 하나요?

HMAC-SHA256이 현대 기본값 — Stripe·GitHub·Shopify·AWS SigV4 사용. 신규 코드엔 SHA-1 피하기(HMAC 공격엔 여전히 안전하지만 미래 보장 아님).

왜 키 인코딩이 필요한가요?

일부 API는 시크릿을 Base64·Hex 문자열로 줍니다. 이를 UTF-8로 다루면 서버가 계산한 것과 다른 서명이 나옵니다. 게시된 시크릿 인코딩에 맞추세요.

hex와 Base64 출력 차이가 중요?

API마다 하나를 기대합니다 — GitHub은 sha256= 접두 hex, Stripe도 hex, Slack도 hex, AWS도 hex. Base64는 일부 커스텀 프로토콜.

서명 검증도 되나요?

간접적으로 — 메시지·키의 HMAC을 계산해 기대 서명과 비교. 안전을 위해 상수 시간 비교가 좋지만 브라우저 ===은 아닙니다.

이 주제의 가이드

해싱 vs 암호화 vs 인코딩: 무엇이 다른가끊임없이 혼동되는 세 용어 — 해싱, 암호화, 인코딩 — 을 명확히 설명합니다. 각각의 용도, 언제 무엇을 쓸지, 피해야 할 실수까지.

HMAC 생성기 (SHA-1·256·384·512)

사용법

자세한 설명

자주 묻는 질문

이 주제의 가이드

관련 도구

해시 생성기 (SHA)

PBKDF2 키 유도

파일 해시 (체크섬)

BLAKE3·BLAKE2·Keccak-256 해시 생성기

JWT 생성기

UUID v5 생성기