왜 constant-time 비교가 중요한가요?

단순 `==` 비교는 첫 다른 바이트에서 early return — 그 시간 차이를 측정하면 한 글자씩 정답을 추측할 수 있는 timing attack 가능. 본 도구는 모든 바이트를 XOR 합산해 일정 시간에 비교.

서명이 Base64 인데요?

현재 hex 입력만 지원합니다. Base64 서명은 Base64 → bytes → hex 한 번 변환 후 사용하세요 (Base64 도구로 디코딩 → 다시 hex 인코딩). 후속 작업에서 Base64 직접 지원 검토 중.

아닙니다 — Web Crypto API 의 `crypto.subtle.importKey` + `subtle.sign` 모두 브라우저에서만 동작. secret · message · signature 어느 것도 yutils 서버나 외부 API 로 나가지 않습니다.

예시

Message: GET /api/orders
Secret: your-256-bit-secret
Signature: f4a4d5e1c8d2b3a9...
Algorithm: SHA-256

✓ 서명 일치 — 메시지가 secret 으로 서명되었음 확인

constant-time 비교 — 첫 다른 바이트에서 early return 하지 않아 timing attack 회피. webhook payload 검증 (Stripe/GitHub/Slack) 시 동일 패턴 필수.

사용법 / 자주 묻는 질문

Q.왜 constant-time 비교가 중요한가요?: A.단순 `==` 비교는 첫 다른 바이트에서 early return — 그 시간 차이를 측정하면 한 글자씩 정답을 추측할 수 있는 timing attack 가능. 본 도구는 모든 바이트를 XOR 합산해 일정 시간에 비교.
Q.서명이 Base64 인데요?: A.현재 hex 입력만 지원합니다. Base64 서명은 Base64 → bytes → hex 한 번 변환 후 사용하세요 (Base64 도구로 디코딩 → 다시 hex 인코딩). 후속 작업에서 Base64 직접 지원 검토 중.
Q.secret 이 외부로 전송되나요?: A.아닙니다 — Web Crypto API 의 `crypto.subtle.importKey` + `subtle.sign` 모두 브라우저에서만 동작. secret · message · signature 어느 것도 yutils 서버나 외부 API 로 나가지 않습니다.

재미있는 사실

Stripe, GitHub, Slack, Twilio 등 거의 모든 webhook 가 HMAC 서명을 사용합니다. 받은 payload 와 signature 를 비교해 변조 여부 + 발신자 진위 확인 — 'shared secret 으로 비대칭 인증' 패턴의 사실상 표준.
Stripe — Webhook signatures
HMAC 검증의 핵심은 constant-time 비교 (`crypto.timingSafeEqual`). 단순 `===` 비교는 첫 다른 바이트에서 early return 해 timing side-channel 을 남깁니다 — 네트워크 너머에서 통계적 분석 가능. 2009년 Keyczar 의 Lawson 취약점이 유명한 사례.
Wikipedia — Timing attack
Replay attack 방지를 위해 signature 만으로는 부족 — timestamp 도 같이 서명하고 5분 이상 지난 요청을 거부해야 합니다. Stripe 의 `t=` + `v1=` 형식은 timestamp + signature 를 한 헤더에 담아 보내 이 패턴을 표준화한 좋은 사례.
Stripe — Verify webhook