해시 & HMAC 생성기

텍스트나 파일의 SHA-1, SHA-256, SHA-384, SHA-512와 HMAC 값을 브라우저에 내장된 Web Crypto로 계산합니다.

해시는 지문이지 암호화가 아닙니다. 되돌릴 수 없고, 같은 입력은 언제나 같은 값을 냅니다. 그래서 내려받은 파일이 온전한지, 두 파일이 같은지 확인하는 데는 맞고, 비밀번호를 저장하는 데는 맞지 않습니다. 비밀번호를 SHA-256으로 한 번 돌린 값은 이 문장을 읽는 시간이면 조회 테이블로 뚫립니다.

SHA-1을 넣어 둔 이유는 옛 체크섬에서 아직 마주치기 때문이고, 무언가를 보호하는 용도로는 쓰면 안 됩니다. 2017년에 실제 충돌이 만들어졌습니다. 기본값으로는 SHA-256이 무난하고, SHA-384와 SHA-512는 그것을 요구하는 프로토콜을 위해 있습니다. MD5는 없습니다. 이 도구가 쓰는 Web Crypto API가 구현하지 않기 때문인데, 지금 새로 고를 이유가 없는 해시라는 점에서 맞는 결정입니다. HMAC은 공유 비밀키를 함께 섞는 별개의 경우로, Stripe나 GitHub 같은 서비스의 웹훅 서명을 검증할 때 쓰는 방식입니다.

해시를 쓸모 있게 만드는 성질은 두 가지이고, 둘 다 분명히 해 둘 값어치가 있습니다. 하나는 결정성입니다. 같은 입력은 어떤 기계에서 어떤 언어로 계산하든 항상 같은 다이제스트를 냅니다. 다른 하나는 눈사태 효과입니다. 입력의 비트 하나만 바뀌어도 출력 비트의 절반가량이 바뀝니다. 두 다이제스트를 비교하는 것이 두 파일이 바이트 단위로 같은지 확인하는 믿을 만한 방법인 이유이고, 다이제스트가 다르다는 사실이 두 파일이 얼마나 다른지는 전혀 알려 주지 않는 이유이기도 합니다.

실제 쓰임은 검증입니다. 내려받기 링크 옆에 적힌 SHA-256은 파일이 온전히 도착했고 주장하는 곳에서 왔음을 확인하라고 있는 것입니다. 손상되거나 변조된 사본을 내려주는 미러는 곧바로 다른 다이제스트를 냅니다. 설치 파일이나 디스크 이미지에서 특히 중요합니다. 조용히 잘린 내려받기의 결과가 절반만 동작하는 설치이기 때문입니다. 이 페이지의 해싱은 Web Crypto API를 통해 페이지 안에서 일어나므로 파일이 기기를 떠나지 않습니다. 체크섬 사이트에 올릴 생각이 들지 않는 파일에도 쓸 수 있는 이유입니다.

HMAC은 구조가 다르고 답하는 질문도 다릅니다. 일반 해시는 무결성을 증명합니다. 누구나 계산할 수 있으니 누구나 데이터를 바꾼 뒤 다시 계산할 수도 있습니다. HMAC은 공유된 비밀값을 섞으므로, 유효한 다이제스트는 그것을 만든 쪽이 키를 가지고 있다는 사실을 증명합니다. Stripe, GitHub, Slack 같은 서비스의 웹훅 서명이 바로 이 방식입니다. 요청 본문을 양쪽이 아는 비밀값과 함께 해싱하고, 그 결과를 상대가 보낸 헤더와 비교하는 것이 그 요청이 정말 그쪽에서 온 것인지, 누군가 재구성해 흘려보낸 것인지를 가르는 방법입니다.

다이제스트는 모든 바이트를 포함하고, 거기에는 아무도 신경 쓰지 않는 바이트도 들어갑니다. 파일 끝의 줄바꿈 하나가 해시를 바꾸고, 윈도우와 유닉스 사이를 텍스트 모드로 전송된 파일도 마찬가지입니다. 전송 중에 줄 끝이 바뀌어서, 읽기에는 같아도 바이트 단위로는 더 이상 같은 파일이 아니기 때문입니다. 공개된 체크섬이 내려받은 파일과 맞지 않을 때, 손상된 내려받기가 한 가지 설명이고 줄 끝을 친절하게 정규화해 준 도구가 또 하나의 설명입니다. 내용을 붙여넣는 대신 파일 자체를 해싱하면 이 범주 전체를 피할 수 있고, 파일 입력이 있는 이유가 그것입니다.