해시값을 이용한 파일 동일성 확인 질문
페이지 정보
작성일
2024.06.27 10:16
125 조회
13 댓글
0 추천
본문
안녕하세요.
일반인 수준의 컴퓨터를 알고 있는 사람입니다.
업무 상 PDF나 엑셀 파일들을 비교해서 변동 사항이 있는지 확인을 자주 해야 하는데, 간혹 동일한 파일을 또 받아서 확인하는 경우가 있습니다. 파일 크기는 1메가 미만부터 4~5메가 수준입니다.
그래서 생각한 것이, Hash 값을 비교해보면 우선 같은 파일인지를 확인할 수 있지 않을까 싶어서 그렇게 해보려고 하는데 신뢰할 수 있을지 문의드립니다.
지금 설치해둔 프로그램에서 보여줄 수 있는 Hash는 CRC-32, MD2, MD4, MD5, SHA-1, SHA-256, SHA-384, SHA-512, HAS-160이라고 나오는데, 혹시 이 중에서 분석 시간 대비 신뢰도가 높은 것은 무엇인지도 문의드립니다.
댓글 13
/ 1 페이지
재재아빠님의 댓글의 댓글
@BLUEnLIVE님에게 답글
말씀 감사드립니다! 그럼 sha-384만 해도 간단한 엑셀, PDF 파일은 동일성 검증에 문제가 없겠네요.
aicasse님의 댓글의 댓글
@BLUEnLIVE님에게 답글
해쉬 충돌쌍의 가능성에 대해 얘기하려면 출력 비트수를 반으로 나누어야 합니다. SHA-384는 2^(384/2)개의 파일을 생성하다 보면 같은 SHA-384 값을 갖는 파일을 발견할 수 있습니다.
BLUEnLIVE님의 댓글의 댓글
@aicasse님에게 답글
몰라서 질문 드립니다:
충돌 가능성을 얘기할 때 출력 비트수를 왜 반으로 나눠야 되는 건가요?
충돌 가능성을 얘기할 때 출력 비트수를 왜 반으로 나눠야 되는 건가요?
aicasse님의 댓글의 댓글
@BLUEnLIVE님에게 답글
소위 '생일 역설(birthday paradox)'과 상관있는 이야기입니다. 어떤 모임에 사람이 23명 이상이 있다고 하면, 50% 이상의 확률로 이 모임 안에 생일이 같은 한 쌍이 존재한다는 것이 생일 역설입니다. 이건 사실 진정한 의미의 논리적 역설은 아니고, 단순히 확률론적인 계산 결과입니다만, 그럼에도 불구하고 이걸 '역설'이라고 하는 이유는, 이 이야기를 처음 들으면, 1년에는 무려 365일이나 있는데 비해 이 집단에는 고작 23명밖에 없기 때문에, 생일이 높은 확률로 겹치기에는 사람 수가 너무나 적게 느껴지기 때문입니다. 이게 되는 이유는 23이 아주 대강 계산해서 365의 제곱근과 가깝다는 것과 상관이 있습니다.
일반화해서 말하자면, 2^384일로 이루어진 1년을 갖는 어떤 외계 행성이 있다고 할 때, 그 행성인들로 이루어진 어떤 모임에 사람 수가 sqrt(2^384)=2^(384/2) 명이 넘으면, 높은 확률로 생일이 같은 사람이 존재하게 됩니다. 여기에서 날짜를 해쉬값으로, 파일을 사람으로 대응시키면 됩니다.
실제로, 해쉬함수의 내부구조를 보지 않고 그냥 무식하게 충돌쌍을 찾는 공격을 할 때에 이러한 '생일 공격'을 할 수 있습니다. 시간만 충분하다면요.
일반화해서 말하자면, 2^384일로 이루어진 1년을 갖는 어떤 외계 행성이 있다고 할 때, 그 행성인들로 이루어진 어떤 모임에 사람 수가 sqrt(2^384)=2^(384/2) 명이 넘으면, 높은 확률로 생일이 같은 사람이 존재하게 됩니다. 여기에서 날짜를 해쉬값으로, 파일을 사람으로 대응시키면 됩니다.
실제로, 해쉬함수의 내부구조를 보지 않고 그냥 무식하게 충돌쌍을 찾는 공격을 할 때에 이러한 '생일 공격'을 할 수 있습니다. 시간만 충분하다면요.
BLUEnLIVE님의 댓글의 댓글
@aicasse님에게 답글
이해했습니다.
해쉬의 크기와 충돌할 확률을 (무식하게) 동일하게 보면 안 되는군요.
감사합니다.
해쉬의 크기와 충돌할 확률을 (무식하게) 동일하게 보면 안 되는군요.
감사합니다.
aicasse님의 댓글의 댓글
@BLUEnLIVE님에게 답글
포인트 때문에 :) 첨언하자면,
이 '생일 공격'의 존재는, 어차피 생일 공격이라고 해도 효율적인 공격은 아니기 때문에 해쉬의 길이가 충분히 크면 걱정할 필요가 없습니다만, 해쉬의 길이가 작은 경우라고 하면 이걸 계산에 넣지 않으면 문제가 될 수 있습니다.
예를 들어 80비트 해쉬에서 2^80개의 파일을 작성하기 전까지는 충돌이 발생하지 않는다고 생각한다면, 밑에 제가 정리한 것과 마찬가지로 2^80이 실용적인 관점에서 거의 고려에 넣지 않아도 될 정도의 수이기 때문에 이 정도면 괜찮겠다고 안심할 수 있습니다만, 생일 공격 때문에 실제로는 2^40개의 파일이 작성된다고 하면 충돌쌍이 발견될 것이고, 2^40개의 파일은 밑에서 대강 계산한 식으로 하면, 1TB 디스크 1024개 안에 들어가 있는 1KB짜리 파일의 총 갯수입니다. 이 정도면 웬만한 데이터센터의 저장공간보다 아마도 더 적지 않을까요. 데이터센터에서 deduplication을 한다고 하면 문제가 될 수 있는 여지가 충분히 있습니다. 즉, 80비트 출력을 갖는 해쉬같은 것은 정말 제한적인 응용이 아니고서는 웬만하면 사용하면 안 되는 거죠
이 '생일 공격'의 존재는, 어차피 생일 공격이라고 해도 효율적인 공격은 아니기 때문에 해쉬의 길이가 충분히 크면 걱정할 필요가 없습니다만, 해쉬의 길이가 작은 경우라고 하면 이걸 계산에 넣지 않으면 문제가 될 수 있습니다.
예를 들어 80비트 해쉬에서 2^80개의 파일을 작성하기 전까지는 충돌이 발생하지 않는다고 생각한다면, 밑에 제가 정리한 것과 마찬가지로 2^80이 실용적인 관점에서 거의 고려에 넣지 않아도 될 정도의 수이기 때문에 이 정도면 괜찮겠다고 안심할 수 있습니다만, 생일 공격 때문에 실제로는 2^40개의 파일이 작성된다고 하면 충돌쌍이 발견될 것이고, 2^40개의 파일은 밑에서 대강 계산한 식으로 하면, 1TB 디스크 1024개 안에 들어가 있는 1KB짜리 파일의 총 갯수입니다. 이 정도면 웬만한 데이터센터의 저장공간보다 아마도 더 적지 않을까요. 데이터센터에서 deduplication을 한다고 하면 문제가 될 수 있는 여지가 충분히 있습니다. 즉, 80비트 출력을 갖는 해쉬같은 것은 정말 제한적인 응용이 아니고서는 웬만하면 사용하면 안 되는 거죠
aicasse님의 댓글
해쉬함수는 원칙적으로는 서로 다른 파일이 같은 해쉬값을 갖는 것이 있을 수는 있습니다만, 실제로는 그런 것을 찾기 위해 필요한 계산 시간이 매우매우 길기 때문에 같은 해쉬값을 갖는 서로 다른 파일을 발견할 가능성이 무시할만큼 적습니다.
위에 나열하신 것들 중에 CRC-32는 너무 약하고, 해쉬도 아니고, 안 쓰는 것이 낫습니다.
MD2, MD4, MD5, SHA-1, HAS-160은 구체적인 충돌쌍(다른 메시진데 같은 해쉬를 갖는 것)을 찾는 공격이 이루어진 바 있습니다. 이중에 MD2, MD4, MD5, HAS-160은 현재 관점에서 볼 때 많이 약합니다. SHA-1은 그래도 이것들보다는 낫습니다.
그렇기는 합니다만, 이 충돌쌍 공격은 말하자면 해쉬값이 같은 파일을 찾기 위해 파일을 '악의적으로' 만들어내는 것입니다. 업무적인 목적으로 일상적으로 접하는 파일들이 해쉬 충돌쌍 공격을 위해 악의적으로 만들어져있다고 보기는 매우 어렵습니다. duplication check을 위한 목적으로 해쉬함수를 쓴다고 하면, 이건 해쉬함수의 암호학적인 응용은 아니기 때문에, 암호학적인 충돌쌍 공격을 그리 걱정해야 하는 것은 아니지 않나 생각합니다. 그렇다면 SHA-1 정도로 충분합니다. 160비트 출력이므로, 2^80개 정도의 파일을 만들다 보면 서로 다른 두 개 파일이 같은 SHA-1 값을 갖는 것을 발견할 수 있습니다. 2^80은 그리고 충분히 큰 숫자죠.
SHA-256, SHA-384, SHA-512 등도 좋습니다만, 솔직히 overkill입니다. SHA-256이면 2^128개의 파일을 생성하다 보면 충돌쌍을 발견할 여지가 생깁니다. 2^80으로도 충분하다고 봅니다. SHA-256, SHA-384, SHA-512 등의 SHA-2 계열 해쉬함수들은 SHA-1보다 느리기도 하고요. 암호학적인 목적이 아닌데 굳이 이런 걸 쓸 이유가 없습니다. 유일하게 고려해야 할 이유는, 내가 정말로 겁나게 많은 파일을 생성하기 때문에 2^80개조차 안심이 되지 않는다... 정도인데, 대강 계산해 보시면 2^80이 이미 상당히 큰 숫자입니다. 한 개 파일의 길이가 1KB라고 해 보죠. 그럼 내 디스크의 크기가 1TB이고 여기에 1KB짜리 파일들이 가득 차 있다고 하면, 여기에 파일의 총 갯수는 2^30개가 있는 겁니다. 2^80개의 파일이라면, 그러니까 1TB 짜리 디스크가 2^50개가 있고 각각에 1KB 짜리 파일이 가득 차 있어야 합니다. 우리 나라 인구가 대강 2^25명이 안됩니다. 우리 나라 전 국민에게 1TB짜리 디스크를 하나씩 주고, 이걸 모두 수거해서 한 사람에게 모아줍니다. 그리고 이런 일을 국민 전체에게 해줍니다. 그러면 2^25명의 국민 각각이 2^25개의 1TB짜리 디스크를 가지고 있게 되죠. 각각의 디스크마다 1KB짜리 파일이 가득차 있으면... 그 정도 수준이 되면 비로소 SHA-1의 충돌쌍을 걱정해야 합니다.
이 목적이라면 더 빠르게는 'universal hashing' 같은 종류의 것을 쓰는 수도 있습니다만, 쓰기 편하게 대중적인 소프트웨어로 구현되어 있는 것이 잘 있는지 모르겠습니다. 그냥 SHA-1 쓰시면 되지 않을까 싶네요.
위에 나열하신 것들 중에 CRC-32는 너무 약하고, 해쉬도 아니고, 안 쓰는 것이 낫습니다.
MD2, MD4, MD5, SHA-1, HAS-160은 구체적인 충돌쌍(다른 메시진데 같은 해쉬를 갖는 것)을 찾는 공격이 이루어진 바 있습니다. 이중에 MD2, MD4, MD5, HAS-160은 현재 관점에서 볼 때 많이 약합니다. SHA-1은 그래도 이것들보다는 낫습니다.
그렇기는 합니다만, 이 충돌쌍 공격은 말하자면 해쉬값이 같은 파일을 찾기 위해 파일을 '악의적으로' 만들어내는 것입니다. 업무적인 목적으로 일상적으로 접하는 파일들이 해쉬 충돌쌍 공격을 위해 악의적으로 만들어져있다고 보기는 매우 어렵습니다. duplication check을 위한 목적으로 해쉬함수를 쓴다고 하면, 이건 해쉬함수의 암호학적인 응용은 아니기 때문에, 암호학적인 충돌쌍 공격을 그리 걱정해야 하는 것은 아니지 않나 생각합니다. 그렇다면 SHA-1 정도로 충분합니다. 160비트 출력이므로, 2^80개 정도의 파일을 만들다 보면 서로 다른 두 개 파일이 같은 SHA-1 값을 갖는 것을 발견할 수 있습니다. 2^80은 그리고 충분히 큰 숫자죠.
SHA-256, SHA-384, SHA-512 등도 좋습니다만, 솔직히 overkill입니다. SHA-256이면 2^128개의 파일을 생성하다 보면 충돌쌍을 발견할 여지가 생깁니다. 2^80으로도 충분하다고 봅니다. SHA-256, SHA-384, SHA-512 등의 SHA-2 계열 해쉬함수들은 SHA-1보다 느리기도 하고요. 암호학적인 목적이 아닌데 굳이 이런 걸 쓸 이유가 없습니다. 유일하게 고려해야 할 이유는, 내가 정말로 겁나게 많은 파일을 생성하기 때문에 2^80개조차 안심이 되지 않는다... 정도인데, 대강 계산해 보시면 2^80이 이미 상당히 큰 숫자입니다. 한 개 파일의 길이가 1KB라고 해 보죠. 그럼 내 디스크의 크기가 1TB이고 여기에 1KB짜리 파일들이 가득 차 있다고 하면, 여기에 파일의 총 갯수는 2^30개가 있는 겁니다. 2^80개의 파일이라면, 그러니까 1TB 짜리 디스크가 2^50개가 있고 각각에 1KB 짜리 파일이 가득 차 있어야 합니다. 우리 나라 인구가 대강 2^25명이 안됩니다. 우리 나라 전 국민에게 1TB짜리 디스크를 하나씩 주고, 이걸 모두 수거해서 한 사람에게 모아줍니다. 그리고 이런 일을 국민 전체에게 해줍니다. 그러면 2^25명의 국민 각각이 2^25개의 1TB짜리 디스크를 가지고 있게 되죠. 각각의 디스크마다 1KB짜리 파일이 가득차 있으면... 그 정도 수준이 되면 비로소 SHA-1의 충돌쌍을 걱정해야 합니다.
이 목적이라면 더 빠르게는 'universal hashing' 같은 종류의 것을 쓰는 수도 있습니다만, 쓰기 편하게 대중적인 소프트웨어로 구현되어 있는 것이 잘 있는지 모르겠습니다. 그냥 SHA-1 쓰시면 되지 않을까 싶네요.
HideD님의 댓글
SHA-256 추천합니다.
모든 경우(문자 그대로 '모든')에 적용 가능하고, 적어도 10년간 아무 문제 없을 해시 알고리즘입니다.
CRC32, MD-2, MD-4는 써서는 안되며,
MD5는 개인용도로 쓰시는 정도까지는 괜찮은데, 여럿이서 같이 써야한다면 안될 것 같습니다.
SHA-1은 지금 당장은 큰 문제는 없는데(작은 문제는 있습니다), 간당간당합니다.
+ SHA-512가 SHA-256보다 두배 크다고 해서, 두배 오래 걸리진 않습니다. 어차피 디스크 읽는 시간이 해시 속도보다 한참 오래 걸리거든요. 그냥 최고로 좋은거 쓴다 치고 SHA-512 쓰는 방법도 괜찮습니다.
+ SHA-384 쓸 바엔 SHA-512, SHA-192 쓸 바에는 SHA-256 쓰는게 맞습니다.
모든 경우(문자 그대로 '모든')에 적용 가능하고, 적어도 10년간 아무 문제 없을 해시 알고리즘입니다.
CRC32, MD-2, MD-4는 써서는 안되며,
MD5는 개인용도로 쓰시는 정도까지는 괜찮은데, 여럿이서 같이 써야한다면 안될 것 같습니다.
SHA-1은 지금 당장은 큰 문제는 없는데(작은 문제는 있습니다), 간당간당합니다.
+ SHA-512가 SHA-256보다 두배 크다고 해서, 두배 오래 걸리진 않습니다. 어차피 디스크 읽는 시간이 해시 속도보다 한참 오래 걸리거든요. 그냥 최고로 좋은거 쓴다 치고 SHA-512 쓰는 방법도 괜찮습니다.
+ SHA-384 쓸 바엔 SHA-512, SHA-192 쓸 바에는 SHA-256 쓰는게 맞습니다.
몽몽이님의 댓글
쓰신 글 보면 비교하려는 파일의 갯수가 보통 2개, 많아도 4~5개를 비교하시는 것 같은데
가장 간단한 해시함수 쓰시는게 제일 효율적이지 않을까요.
충돌 가능성을 따지는건 위조나 변조 같은 악의적인 공격이 있을 경우에 보안 관점으로 접근하는 것인데 쓰신 글로는 업무 목적에 그것 같지는 않아요. 결론은 그냥 아무 해시함수 쓰셔도 변경 여부 확인하는 용도로는 차고 넘칠 것 같아요.
가장 간단한 해시함수 쓰시는게 제일 효율적이지 않을까요.
충돌 가능성을 따지는건 위조나 변조 같은 악의적인 공격이 있을 경우에 보안 관점으로 접근하는 것인데 쓰신 글로는 업무 목적에 그것 같지는 않아요. 결론은 그냥 아무 해시함수 쓰셔도 변경 여부 확인하는 용도로는 차고 넘칠 것 같아요.
아이폰점보님의 댓글의 댓글
@몽몽이님에게 답글
동의 합니다. 변조 방지가 아니라 변경 확인이 목적이니까요.
재재아빠님의 댓글
생각도 못했는데 이렇게 정성들여서 조언해주셔서 정말 감사드립니다! 내용 이해가 어려운 부분도 있지만 잘 참고해서 업무에 적용하겠습니다.
BLUEnLIVE님의 댓글
예를 들면 SHA-384는 결과가 384비트 즉, 2^284의 결과가 나오는 건데, 다른 파일이 같은 해시가 나올 확률은 깔끔하게 1/(2^384) 일 뿐입니다.
그냥 비트수가 크면 그만큼 신뢰도가 올라간다고만 생각하면 될 것 같습니다.