본문으로 이동
Financial Context Wiki

암호학적 해시 함수

보안 속성, 바이트 인코딩, SHA-2, SHA-3, Keccak, 블록체인 활용 및 구현 위험을 다루는 검증 중심의 암호학적 해시 함수 안내서입니다.

업데이트

교육 목적으로만 제공되며 투자 또는 암호 기술 구현에 관한 조언이 아닙니다. 다이제스트가 일치한다는 사실만으로 진위, 소유권, 권한 부여, 최종성 또는 데이터 가용성이 입증되지는 않습니다.

핵심 답변

암호학적 해시 함수는 바이트로 표현된 메시지를 정해진 출력 길이의 다이제스트로 결정론적으로 매핑합니다. 출력 길이가 고정된 n비트 해시의 기본 관계는 다음과 같습니다.

h = H(m), where h is in {0,1}^n

동일한 바이트와 알고리즘은 동일한 다이제스트를 생성합니다. 입력이 한 비트 바뀌면 많은 출력 비트가 예측할 수 없게 달라져야 하지만, 이러한 눈사태 효과 자체가 보안의 정의는 아닙니다. 주요 보안 목표는 역상 저항성(다이제스트가 주어졌을 때 그 값을 생성하는 입력을 찾는 것이 현실적으로 불가능함), 두 번째 역상 저항성(하나의 입력이 주어졌을 때 같은 다이제스트를 갖는 다른 입력을 찾는 것이 현실적으로 불가능함), 충돌 저항성(같은 다이제스트를 갖는 서로 다른 임의의 두 입력을 찾는 것이 현실적으로 불가능함)입니다.

해싱은 암호화가 아닙니다. 복호화 키가 없으며 입력을 복원할 수 있다는 보장도 없습니다. 무한히 많은 메시지 후보가 유한한 출력 공간에 매핑되므로 충돌은 반드시 존재합니다. 보안이란 선택한 알고리즘과 출력 길이에서 유용한 충돌을 찾는 일이 계산상 불가능하다는 뜻입니다.

다이제스트 자체는 진위도 보장하지 않습니다. 예상 다이제스트와 알고리즘을 신뢰할 수 있는 경로로 받은 경우에만 파일의 해시를 다시 계산해 불일치를 탐지할 수 있습니다. 프로토콜은 해시를 서명, 메시지 인증 코드, 인증된 데이터 구조, 합의 규칙 또는 작업 증명과 결합해 더 강한 보장을 제공합니다.

작동 방식

  1. 정확한 바이트를 정의합니다. 텍스트 인코딩, 대소문자, 공백, 필드 순서, 정수 표현, 길이 접두사, 직렬화는 모두 m에 영향을 줍니다. 프로토콜은 정규 인코딩을 명시하고 해시를 특정 알고리즘, 버전, 네트워크 및 용도에 결부해야 합니다.
  2. 지정된 구성을 실행합니다. SHA-256은 길이가 제한된 메시지를 전처리하고 블록으로 나눈 뒤 내부 상태를 반복해서 갱신합니다. SHA3-256은 KECCAK 기반 스펀지 구성을 사용합니다. 둘 다 256비트 다이제스트를 반환하지만 서로 다른 함수이며 출력은 호환되지 않습니다.
  3. 필요한 속성에 따라 보안을 해석합니다. 이상적인 n비트 해시에서 일반적인 역상 탐색은 약 2^n회의 평가가 필요하지만, 생일 효과로 인해 일반적인 충돌 탐색은 약 2^(n/2)회의 평가가 필요합니다. 알고리즘이 깨졌거나 다이제스트가 잘렸거나 주변 프로토콜에 결함이 있다면 출력 길이만으로는 보안을 판단할 수 없습니다.
  4. 다이제스트를 중심으로 프로토콜을 구성합니다. 디지털 서명 방식은 메시지의 다이제스트에 서명할 수 있습니다. HMAC은 비밀 키를 추가해 메시지를 인증합니다. 머클 트리는 하나의 루트로 여러 리프를 커밋합니다. 작업 증명은 다이제스트가 목표값을 충족할 때까지 후보 블록 헤더를 반복해서 해싱합니다. 이러한 구성은 서로 다른 보장을 제공합니다.
  5. 블록체인이 지정한 정확한 함수를 사용합니다. Bitcoin 블록 헤더와 머클 노드는 지정된 바이트 순서로 이중 SHA-256을 사용합니다. Ethereum 실행 계층은 표준화 이전 KECCAK 설계의 Keccak-256을 사용하며, 표준화된 SHA3-256을 사용하지 않습니다. 따라서 “256비트 해시”라는 표기만으로는 검증에 충분하지 않습니다.
  6. 의미를 해석하기 전에 맥락을 검증합니다. 예상 다이제스트의 출처, 알고리즘 식별자, 바이트 인코딩, 도메인 또는 블록체인, 참조하는 블록과 상태, 확인 상태 및 잘림 여부를 확인합니다. 잘못된 맥락에서 계산만 정확한 경우에도 검증은 실패입니다.

구체적인 예

  • 입력의 아주 작은 변화. hello를 나타내는 다섯 개의 UTF-8 바이트에 대한 SHA-256은 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824입니다. 첫 번째 바이트를 대문자 H로 바꾸면 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969가 됩니다. 다이제스트가 다르다는 사실만으로 어떤 바이트가 바뀌었는지는 알 수 없습니다.
  • 모든 공격 모델에서 보안 강도가 다이제스트 길이와 같은 것은 아닙니다. 이상적인 256비트 해시는 역상 탐색에 약 2^256의 작업량이 필요하지만 충돌 탐색에는 2^128의 작업량이 필요합니다. 디지털 서명 절차처럼 프로토콜이 충돌 저항성에 의존할 때 이 차이는 중요합니다.
  • 머클 증명은 하나의 루트를 기준으로 포함 관계를 인증합니다. 검증자는 인코딩된 리프와 제공된 각 형제 노드를 지정된 순서로 해싱하여 커밋된 루트를 재구성합니다. 값이 일치해도 해당 루트가 최종 확정되었는지, 리프 데이터가 사실인지, 생략된 데이터를 이용할 수 있는지는 증명되지 않습니다.
  • 작업 증명에는 목표값 규칙이 추가됩니다. Bitcoin은 후보 헤더의 이중 SHA-256 값을 합의 규칙에 따라 해석한 결과가 인코딩된 목표값 이하일 때만 해당 헤더를 유효하다고 판정합니다. 채굴자가 더 많은 작업을 수행했다고 해서 다이제스트의 충돌 저항성이 높아지는 것은 아닙니다.

위험

  • 폐기되었거나 용도에 적합하지 않은 알고리즘을 사용하는 것, 특히 충돌 저항성이 필요한 곳에서 SHA-1에 의존하는 것.
  • SHA3-256, Keccak-256, SHA-256, 이중 SHA-256 및 서로 다르게 잘린 변형을 서로 바꿔 쓸 수 있다고 보는 것.
  • 정규 바이트가 아니라 화면에 표시된 텍스트를 해싱하거나 Unicode 정규화, 공백, 엔디언, 필드 순서 및 길이 인코딩을 간과하는 것.
  • 파일과 예상 다이제스트를 동일하게 침해된 위치에서 내려받아 독립적인 무결성 검사가 되지 못하게 하는 것.
  • 비밀번호 저장에 적절한 작업 계수를 적용한 솔트 기반 전용 비밀번호 해싱 방식 대신 빠른 범용 해시를 직접 사용하는 것.
  • H(secret || message)를 자체 제작 인증 코드로 사용하는 것. 일부 반복형 해시 구성은 길이 확장 공격을 허용하지만 HMAC은 키 기반 인증을 위해 설계되었습니다.
  • 프로토콜의 규모와 위협 모델에 따른 충돌 보안 및 역상 보안의 변화를 계산하지 않고 다이제스트를 자르는 것.
  • 도메인 분리 없이 여러 프로토콜에서 인코딩을 재사용하여 한 맥락에서 유효한 다이제스트가 다른 맥락에서 해석될 수 있게 하는 것.
  • 거래 해시가 확인, 최종성, 성공적인 실행, 소유권 또는 체인 재구성 방지를 증명한다고 가정하는 것.
  • 콘텐츠 해시가 참조된 데이터를 가져올 수 있음까지 보장한다고 가정하는 것. 이용 가능한 모든 사본이 사라져도 커밋먼트는 여전히 유효할 수 있습니다.
  • 탐색기에 표시된 문자열을 비교하면서 바이트 순서, 접두사 규칙, 직렬화 또는 인터페이스가 내부 식별자를 다르게 표시하는지 확인하지 않는 것.
  • 표준 테스트 벡터, 유지 관리되는 라이브러리, 독립적인 검토 및 업그레이드 절차 없이 암호 프리미티브를 구현하는 것.

흔한 오해

  • 해시는 암호화된 데이터입니다. 암호화는 올바른 키로 되돌릴 수 있지만 암호학적 해시는 복호화 연산이 없는 단방향 다이제스트입니다.
  • 서로 다른 입력은 절대 같은 다이제스트를 가질 수 없습니다. 고정 길이 출력에는 반드시 충돌이 존재합니다. 안전한 설계는 충돌을 찾아 악용하는 일을 현실적으로 불가능하게 만듭니다.
  • 256비트 다이제스트는 항상 256비트의 보안 강도를 제공합니다. 이상적인 256비트 해시도 일반적인 충돌 저항성은 약 128비트이며, 프로토콜 선택에 따라 더 낮아질 수 있습니다.
  • 해시가 일치하면 누가 메시지를 만들었는지 증명됩니다. 해시 자체에는 비밀이 없고 발신자를 인증하지도 않습니다. 출처가 중요하다면 서명이나 적절한 MAC을 사용해야 합니다.
  • Keccak-256과 SHA3-256은 같은 함수를 가리키는 두 이름입니다. 둘은 밀접하게 관련된 설계를 사용하지만 표준화 매개변수가 다르며 생성하는 다이제스트도 다릅니다.
  • 온체인 거래 해시는 결제를 증명합니다. 거래 해시는 인코딩된 거래 데이터를 식별합니다. 체인 포함, 실행 상태, 확인 및 최종성은 각각 별개의 사실입니다.

관련 주제

출처

탐색

위키 검색...