본문으로 건너뛰기
yutils
예시

입력 (메시지 + 키)

메시지: GET /api/orders
키: secret-key-1234

출력 (HMAC-SHA256)

3f8b2a4c1d9e7b6f5a2c8d4e1b9f6a3c7d2e8b5a4f1c9d6e3b8a5d2c9f6e3b1a

참고

HMAC 은 message + key 둘 다 필요한 keyed hash. 키 없이는 같은 hash 를 만들 수 없어 메시지 무결성 + 인증을 동시에 보장.

사용법 / 자주 묻는 질문

이런 경우 사용하세요

  • API 요청 서명 — AWS Signature V4, Stripe webhook, GitHub webhook 등
  • Webhook payload 가 진짜 발신처에서 왔는지 검증
  • JWT HS256 알고리즘 학습 — 본질이 HMAC-SHA256
  • 메시지 변조 감지 — 키를 모르면 재서명 불가
  • 보안 토큰의 무결성 확인 (CSRF 토큰 · session ID 등)

자주 묻는 질문

Q.HMAC 과 그냥 hash 의 차이는?
A.SHA-256(message) 은 누구나 만들 수 있어 위조 가능. HMAC-SHA256(message, key) 은 키를 아는 측만 만들 수 있어 진위 보증. 메시지를 누가 보냈는지 확인하려면 HMAC.
Q.키는 얼마나 길어야 하나요?
A.SHA-256 기반이라 32바이트(256비트) 이상 권장. 짧은 키는 자동 padding 되지만 공격면이 늘어남. 키는 절대 코드 · 클라이언트에 박지 마세요.
Q.constant-time 비교가 필요한가요?
A.예. HMAC 검증 시 단순 `==` 비교는 timing attack 에 취약 — 응답 시간으로 한 글자씩 추측 가능. 서버 코드에서는 `crypto.timingSafeEqual` 같은 함수 사용 필수.
재미있는 사실
  • HMAC 의 핵심 발견은 '해시 함수에 키를 단순히 붙이면(`hash(key || message)`) 위조가 가능하다' 입니다. SHA-1/SHA-256/MD5 모두 Merkle-Damgård 구조라 length-extension 공격이 통하기 때문이에요. HMAC 의 ipad/opad 더블 hash 는 이걸 깔끔하게 막아줍니다.

    Wikipedia — Length extension attack
  • HMAC 은 1996년 Mihir Bellare·Ran Canetti·Hugo Krawczyk 가 CRYPTO 학회에 발표한 'Keying Hash Functions for Message Authentication' 에서 시작됐고, 1997년 RFC 2104 로 표준화됐습니다. IPsec / TLS / JWT(HS256) 모두 같은 뿌리입니다.

    RFC 2104 (1997)
  • HMAC 검증은 반드시 constant-time 비교(`crypto.timingSafeEqual` 등)로 해야 합니다. `===` / `strcmp` 는 일치하는 prefix 길이만큼 시간이 길어지는 timing side-channel 을 남기고, 네트워크 너머에서도 통계적으로 측정 가능합니다 — 2009년 Lawson 의 Keyczar 취약점이 유명한 사례.

    Wikipedia — Timing attack