해시 생성기

어떻게 사용하나요?

1. 텍스트 — 입력하는 즉시(200ms 디바운스) MD5·SHA-1·SHA-256·SHA-384·SHA-512 다섯 값을 동시에 보여 줍니다. 출력 형식(hex 소문자·대문자, Base64, Base64URL)과 인코딩(UTF-8·ASCII)을 고를 수 있습니다.
2. 파일 — 끌어다 놓거나 선택하면 다섯 해시와 SRI 값을 계산합니다. 배포처가 공개한 체크섬을 ‘예상 해시’에 붙여넣으면 일치 여부를 바로 표시합니다.
3. HMAC — 비밀키와 메시지로 HMAC-SHA1/256/384/512 서명을 만듭니다. 키는 텍스트·hex·Base64로 넣을 수 있고, GitHub·Slack·AWS·JWT 프리셋이 알고리즘과 출력 형식을 맞춰 줍니다.
4. 가이드 — 알고리즘 비교, 안전성 등급, SRI 사용법, CLI 명령 대조표.

출력 형식·인코딩·HMAC 알고리즘 같은 옵션만 이 브라우저에 저장합니다. 입력 텍스트·비밀키·파일은 저장하지도, 서버로 보내지도 않습니다(MD5는 자체 JavaScript 구현, 나머지는 브라우저 내장 Web Crypto API).

해시 알고리즘 비교 — 출력 길이로 알고리즘 알아보기

해시는 입력 길이와 상관없이 항상 같은 길이로 나옵니다. 그래서 받은 체크섬이 어떤 알고리즘인지 모르면 글자 수로 먼저 가늠할 수 있습니다 — hex 32자면 MD5, 40자면 SHA-1, 64자면 SHA-256입니다. 본 도구의 파일 검증도 붙여넣은 값의 길이가 고른 알고리즘과 다르면 ‘변조’가 아니라 ‘알고리즘 불일치’로 따로 알려 줍니다.

길이는 본 도구의 알고리즘 정의에서 계산한 값입니다(Base64는 끝의 = 패딩 포함, Base64URL은 패딩 제외). SHA-384는 SHA-512를 다른 초깃값으로 계산해 앞 384비트만 쓰는 변형이라, 64비트 CPU에서 SHA-256보다 빠른 경우가 많습니다 — 다만 SHA 전용 명령어(SHA-NI 등)가 있는 최신 CPU에서는 SHA-256이 더 빠를 수 있습니다.

보이는 글자가 같아도 해시가 다른 이유 — 테스트 벡터

해시 함수는 글자가 아니라 바이트를 읽습니다. 아래 표는 본 도구의 텍스트 해시 함수로 직접 계산한 값으로, 줄바꿈 한 글자·보이지 않는 BOM·인코딩 모드만 달라도 결과가 완전히 바뀌는 것을 보여 줍니다(입력이 1비트만 바뀌어도 출력 비트의 약 절반이 바뀌는 ‘눈사태 효과’). 다른 도구와 값이 다를 때는 이 표의 경우부터 의심해 보세요.

검산용 기준값 — 텍스트 탭에 abc를 입력했을 때 SHA-256이 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, MD5가 900150983cd24fb0d6963f7d28e17f72이면 계산이 표준과 일치합니다. 터미널에서 같은 값을 얻으려면 printf abc | sha256sum처럼 줄바꿈 없이 넘겨야 합니다. EUC-KR(CP949)로 저장된 한글 파일은 한 글자가 2바이트라, 같은 문장을 UTF-8로 입력한 텍스트 탭 결과와 다릅니다 — 이럴 땐 파일 탭으로 원본 바이트를 그대로 해시하세요.

안전성 등급 — 무엇에 써도 되고 무엇에 쓰면 안 되나

기준은 ‘누군가 일부러같은 해시를 가진 다른 데이터를 만들 동기가 있느냐’입니다. 공격자가 끼어들 수 있는 곳이면 충돌 저항성이 필요하고, 우연한 손상만 걸러내면 되는 곳이면 MD5로도 충분합니다.

• 파일 체크섬 — 다운로드 중 손상 여부 확인. 단, 체크섬 자체를 같은 서버에서 받는다면 변조까지는 막지 못하므로 배포처가 SHA-256과 서명(GPG 등)을 함께 제공하면 그쪽을 쓰세요.
• 중복 파일 찾기·캐시 키 — 같은 내용을 빠르게 식별하는 용도. 충돌을 일부러 만들 사람이 없는 내부 데이터라면 MD5도 무방합니다.
• Git 커밋 ID — SHA-1 기반(충돌 탐지 기능을 넣은 변형). Git은 SHA-256 저장소 형식을 도입해 전환 중입니다.
• 레거시 연동 — 상대 시스템이 MD5·SHA-1만 받을 때. 새로 설계한다면 SHA-256 이상을 쓰세요.

알려진 충돌 공격: MD5 2004(Wang 외) · SHA-1 SHAttered 2017.02(Google·CWI) · SHA-1 chosen-prefix 2020.01. NIST는 2030년 12월 31일까지 SHA-1을 SHA-2·SHA-3로 교체하도록 권고합니다.

HMAC 서명 — 서비스별 형식과 검증할 때 틀리는 곳

HMAC은 비밀키와 메시지를 함께 해시해, 키를 가진 쪽만 올바른 값을 만들 수 있게 한 메시지 인증 코드입니다. 서비스마다 무엇을 서명하는지(본문만? 타임스탬프 포함?)가 달라서, 알고리즘을 맞춰도 서명 대상 문자열이 다르면 값이 일치하지 않습니다.

• 본문을 다시 직렬화하지 말 것 — 프레임워크가 JSON을 파싱한 뒤 다시 문자열로 만들면 공백·키 순서·유니코드 이스케이프가 바뀌어 서명이 틀어집니다. 받은 원문 바이트로 계산하세요.
• 접두어·구분자 확인 — GitHub은 sha256=, Slack은 v0=이 헤더 값 앞에 붙습니다. 비교 전에 떼거나, 계산 결과에 같은 접두어를 붙이세요.
• 상수 시간 비교 — 문자열 == 대신 Node의 crypto.timingSafeEqual, Python의 hmac.compare_digest를 쓰면 응답 시간 차이로 서명을 추측하는 공격을 막을 수 있습니다.
• 타임스탬프 검사 — Slack·Stripe는 서명에 시각을 포함합니다. 몇 분(두 서비스 모두 5분을 권장·기본값으로 안내)보다 오래된 요청을 거절해야 재전송 공격을 막습니다.

직접 확인해 보기 — HMAC 탭에서 키 key, 메시지 The quick brown fox jumps over the lazy dog, HMAC-SHA256·hex를 고르면 f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8가 나와야 합니다(본 도구의 서명 함수로 빌드 때 계산한 값).

파일 무결성 검증 — CLI 명령 대조표

OS 설치 이미지나 설치 파일은 배포처가 SHA-256 값(SHA256SUMS 파일 등)을 함께 공개합니다. 내려받은 파일로 같은 값을 계산해 비교하면 손상 여부를 알 수 있습니다. 본 도구의 파일 탭 결과는 아래 명령의 출력과 같아야 합니다.

PowerShell Get-FileHash는 알고리즘을 생략하면 SHA-256으로 계산하고 대문자 hex로 출력합니다. 본 도구의 ‘예상 해시’ 칸은 대소문자를 구분하지 않고,sha256sum 출력 한 줄(해시 + 파일명), BSD·macOS 형식(SHA256 (file) = …), 바이트 사이에 공백·콜론이 들어간 형식에서도 해시 부분만 골라 비교합니다. 여러 파일을 한 번에 확인할 때는 터미널의 sha256sum -c SHA256SUMS가 편합니다.

자주 묻는 질문

참고 자료

1. NIST FIPS 180-4 (SHS)(새 창)nvlpubs.nist.gov
2. NIST SHA-1 퇴역 발표(새 창)nist.gov
3. RFC 2104 (HMAC)(새 창)rfc-editor.org
4. W3C Subresource Integrity(새 창)w3.org