파일을 다운로드 할 때 체크섬을 비교하는 것이 좋은 방법은 무엇입니까?

다운로드 용 ISO 파일을 제공하는 웹 사이트는 종종 해당 파일의 md5 체크섬을 제공하여 파일이 올바르게 다운로드되었고 손상되지 않았 음을 확인할 수 있습니다.

왜 이것이 필요한가요? TCP의 오류 수정 속성은 충분합니다. 패킷이 올바르게 수신되지 않으면 다시 전송됩니다. TCP / IP 연결의 특성상 데이터 무결성을 보장하지 않습니까?

다른 사람들이 지적했듯이, 전송 계층에서 체크섬을 계산하기 전에 이미 발생하는 손상, 스트림을 가로 채서 수정하는 MITM (데이터도 포함)과 같이 전송 계층의 모든 체크섬이 도울 수없는 데이터 손상 가능성이 많이 있습니다. 수신 측에서 체크섬을 검증 한 후 발생하는 손상 등

이러한 다른 모든 가능성을 무시하고 TCP 체크섬 자체의 특성과 데이터 무결성 유효성 검사 측면에서 실제로 수행하는 작업에 중점을두면 이 체크섬의 속성이 오류 감지 측면에서 포괄적 인 것은 아닙니다. 이 체크섬 알고리즘이 선택된 방식은 시간과 함께 속도에 대한 요구 사항을 반영합니다 (1970 년대 후반).

TCP 체크섬 을 계산 하는 방법 은 다음과 같습니다.

체크섬 : 16 비트

체크섬 필드는 헤더와 텍스트에있는 모든 16 비트 단어의 보수 합계의 16 비트 보수입니다. 세그먼트에 체크섬 할 홀수의 헤더 및 텍스트 옥텟이 포함 된 경우 마지막 옥텟은 오른쪽에 0으로 채워져 체크섬 목적으로 16 비트 워드를 형성합니다. 패드는 세그먼트의 일부로 전송되지 않습니다. 체크섬을 계산하는 동안 체크섬 필드 자체는 0으로 바뀝니다.

이는 데이터를 합산 할 때 균형을 유지하는 손상이 감지되지 않음을 의미합니다. 데이터가 손상 될 수있는 여러 가지 범주의 손상이 있지만 사소한 예로 16 비트 단어의 순서를 변경하면 항상 감지되지 않습니다.

실제로 많은 전형적인 오류를 포착하지만 무결성을 보장 하지는 않습니다 . 또한 로컬 링크를 통한 전송에 대해서만 L2 계층이 무결성 검사 (예 : 이더넷 프레임의 CRC32)를 수행하는 방법을 통해 도움이되며, 손상된 데이터의 경우가 TCP 스택으로 전달되지도 않습니다.

강력한 해시 또는 바람직하게는 암호화 서명을 사용하여 데이터를 검증하는 것은 데이터 무결성을 보장하는 측면에서 완전히 다른 수준에 있습니다. 이 둘은 간신히 비교 될 수 있습니다.

md5sum을 확인 해야하는 이유는 아마 있지만 몇 가지가 내 마음에 왔습니다.

• 악의적 인 활동-서버에서 나가는 동안 ISO가 변조되었을 수 있습니다
• 페이지 자체가 스푸핑되었습니다 (md5sum도 서명하는 것이 가장 좋습니다).
• (TCP 에러 보정에도 불구하고) 브로큰 다운로드 (확인 이 아웃)
• ISO가 잘못 태워 짐

어쨌든 몇 초 밖에 걸리지 않습니다.

TCP / IP는 데이터 무결성을 보장합니다 *. 그러나 100 % 파일이 다운로드되었다는 보장은 없습니다. 이것이 일어날 수있는 많은 이유가있을 수 있습니다. 예를 들어, 중간 어딘가에 1 바이트 또는 2 바이트가 누락 된 ISO를 마운트 할 수 있습니다. 손상된 하나 또는 두 개의 특정 파일이 필요할 때까지 문제가 없습니다. 체크섬을 비교하면 실제로 전체 파일을 다운로드했는지 확인할 수 있습니다.

* 의견보기

TCP 체크섬은 16 비트입니다. 이는 다른 체크섬이없는 경우 65536 개의 손상된 패킷 중 하나가 손상되지 않은 것으로 수락됨을 의미합니다. 예를 들어, 1 %의 손상 률로 시끄러운 링크를 통해 8GB DVD 이미지를 다운로드하는 경우 81 개의 패킷이 감지되지 않을 것으로 예상됩니다.

MD5는 128 비트에서 훨씬 더 큰 체크섬입니다. 원본과 동일한 체크섬으로 무언가를 생성하는 81 개의 패킷의 확률은 1,000,000,000,000,000,000,000,000,000,000,000에서 약 1입니다.

HTTP를 통해 다운로드 한 파일의 체크섬을 확인해야하는 몇 가지 이유가 있습니다.

• 전체 파일을 받았는지 확인
  • Firefox 와 같은 일부 클라이언트 는 중단 된 연결을 성공적인 다운로드로 취급하여 파일이 잘리지 만 다운로드가 완료되었다고 주장 할 수 있습니다.
• 올바른 파일을 받았는지 확인
  • 예 : 버그가 있거나 손상된 서버 또는 악의적 인 서버가 다른 것을 보낼 수 있습니다
  • 누군가가 전송을 조작 할 수 있습니다 (중간자 공격)-Superfish와 같은 시스템이 손상되었거나 사용중인 암호화 방법이 약한 경우 HTTPS조차도 이것으로부터 안전하지 않습니다
  • 그들은 또한 당신에게 잘못된 다운로드 페이지를 제공 할 수도 있으므로 실제 서버에 연결되어 있지도 않습니다 (그러나이 경우 체크섬은 동일한 가짜 서버에서 가져 오는 경우별로 도움이되지 않습니다)
  • 인터넷 서비스 제공자 (ISP)의 수는 여러 가지 이유로 전송의 페이지에 자바 스크립트 주입 적발 된 ¹ ; 이것이 얼마나 잘 구현되었는지에 따라 일부 파일 다운로드를 엉망으로 만들 수 있습니다
  • 미러가 오래된 버전의 파일을 호스팅하거나 관리자가 잘못된 파일을 업로드했을 수 있습니다
• TCP가 감지 할 수없는 파일로 파일이 손상되지 않았는지 확인
  • 예를 들어, 파일이 서버에서 손상 될 수 있으므로 TCP는 이미 손상된 파일이 전송에서 더 이상 엉망이되지 않도록 보장합니다.
  • 또는 메모리 / 디스크 결함, 버그가있는 파일 시스템 드라이버 등으로 인해 종료 된 후에 손상 될 수 있습니다.
  • TCP 체크섬은 16 비트에 불과하므로 손상된 패킷이 감지되지 않을 확률이 천문학적 (65536 중 1 개)이 아닙니다.
• ISO를 사용하면 디스크가 올바르게 레코딩되었는지 확인

lol rep의 댓글 ^{1 개}

Daniel, 말한대로 ISO 다운로드에 사용중인 도구에 따라 다릅니다. Say Firefox 인 경우 파일 다운로드가 표시 될 수 있습니다. 그러나 완전한 ISO가 없을 수도 있습니다. 화상을 입었다가 사용하려고하면 정보가 누락 될 수 있습니다. 파일을 호스팅하는 다른 웹 서버에서 때때로 발생합니다.

최소한 파일 크기 (총 바이트 또는 비트)를 비교하여 일치하는지 확인하는 것이 좋습니다. Windows는 파일 바이트 수를 다르게 표시하고 Linux를 말합니다. MD5 합계 검사는 어떤 OS를 사용하든 상관없이 동일한 값을 표시합니다. 희망이 조금 도움이되기를 바랍니다. 건배...

흥미로운 답변이 많이 있지만 마지막으로 고려해야 할 사항이 두 가지 있습니다 .

두 장군 문제와 비잔틴 장군 문제는 신뢰할 수없는 채널을 통해 정보를 안정적으로 전송하는 의미를 구체적으로 고려합니다.

체크섬은 "신뢰성 향상"의 또 다른 계층이며 실패 가능성이 매우 낮은 계층입니다. 이것이 인기가 높은 이유입니다.