CRC 알고리즘은 일반적으로 해밍 거리 조건에서 오류 감지를 보장합니다. 제한된 수의 비트 플립이 주어지면 CRC는 _ 필요하게 _ 다른 결과를 생성합니다.

이것은 오류가 몇 비트 만 뒤집는 것으로 추정되는 상황에서 유용 할 수 있습니다.
불과 수십 년 전만해도 이는 기본 신호가 여전히 매우 "원시"였기 때문에 특히 전송 시나리오에서 상대적으로 흔했습니다. 따라서 물리 계층에서 감지되지 않은 비트 플립이 문제였습니다.

그러나이 속성에는 배포 비용이 있습니다. "안전한"해밍 거리를 넘으면 충돌 가능성이 더 나빠집니다. 이것은 비둘기 구멍 원칙의 논리적 결과입니다. 얼마나 나빠요? 음, 정확한 CRC에 따라 다르지만 좋은 CRC는 3x-7x 더 나쁜 범위에있을 것으로 예상합니다. 그것은 많이 들릴지 모르지만 그것은 단지 2-3 비트 분산 감소이므로 끔찍하지 않습니다. 아직도.

"이상적인"분포 속성을 특징으로하는 해시와 대조됩니다. 단일 비트이든 완전히 다른 출력이든 모든 변경은 충돌을 생성 할 확률이 정확히 1 / 2 ^ n입니다. 이해하는 것이 더 간단합니다. 충돌 위험은 항상 동일합니다. CRC와 직접 비교하면 해밍 거리가 작을 때 충돌 률은 더 나쁘지만 (> 0이기 때문에) 해밍 거리가 클 때 더 좋습니다.

요즘에는 상황이 급격히 변했습니다. 우리는 물리적 매체 위에 오류 감지 및 수정 논리 계층에 계층이 있습니다. 우리는 플래시 블록에서 조금만 추출 할 수 없으며 블루투스 채널에서 조금만 읽을 수도 없습니다. 더 이상 말이되지 않습니다. 이러한 프로토콜은 더 복잡하고 탄력적이며 물리 계층의 영구적 인 노이즈를 지속적으로 보상하는 상태 저장 블록 로직을 포함합니다. 실패하면 단일 플립이 생성되지 않습니다. 오히려 완전한 데이터 영역이 완전히 섞여서 모두 0이거나 임의의 노이즈가됩니다.

이 새로운 환경에서는 오류가 발생했을 때 더 이상 "bitflip"범주에 속하지 않습니다. 이 경우 CRC의 배포 속성은 책임이됩니다. 순수한 해시는 실제로 충돌을 일으킬 확률이 낮습니다.

이것은 체크섬 만 고려할 때입니다.
"이상적인"해시의 추가 속성은 해시에서 비트 세그먼트를 추출 할 때 여전히이 1 / 2^n 충돌 확률을 특징으로하며, 이는 다음과 같은 다른 구조의 비트 소스로 매우 중요합니다. 해시 테이블 또는 블룸 필터. 반대로 CRC는 그러한 보증을 제공하지 않습니다. 일부 비트는 매우 예측 가능하거나 상관 관계가 높으며 해시 목적으로 추출 할 때 분산이 훨씬 더 심합니다.

체크섬과 해싱은 단순히 두 개의 다른 도메인이며 혼동해서는 안된다고 말할 수 있습니다. 사실, 그것이 이론입니다. 문제는 이것이 편리함과 현장 실습을 무시한다는 것입니다. 여러 목적을 위해 하나의 "믹서"를 갖는 것은 편리하며 프로그래머는 하나에 만족하고 잊어 버릴 것입니다. 나는 crc32가 해싱에 사용 된 것을 몇 번이나 보았는지 셀 수 없다. 단지 "충분히 임의적"이라고 느꼈기 때문이다. 일어나서는 안된다고 말하기는 쉽지만 계속해서 발생합니다.
이 환경에서 두 사용 사례 모두에 잘 작동하도록 설계된 솔루션을 제안하는 것은 사용자의 기대와 일치하기 때문에 의미가 있습니다.

PIC / Arduino 군중 내에서 사람들은 여전히 ​​오래된 간단한 8 비트 체크섬, 16 비트 Fletcher 합계 또는 16 비트 CRC를 사용합니다.
(...)
8 비트 또는 16 비트로 줄일 때 해시 함수에 본질적으로 나쁜 것이 있습니까?

좋은 해시의 속성으로 인해 실제로 해시에서 8 비트 또는 16 비트를 추출 할 수 있으며 결과적으로 1/256 또는 1/65535 충돌 확률이 발생합니다. 나는 이것에 대해 걱정하지 않는다.

단지, 우리는 _history_의 지연 시간을 받아 들여야합니다. 사람들은 체크섬을 위해 특정 체크섬 기능을 사용하는 것과 같은 특정 방식에 익숙합니다. 더 최근의 잠재적으로 더 나은 솔루션이 있더라도 습관은 빠르게 변하지 않습니다.

CRC 알고리즘은 일반적으로 해밍 거리 조건에서 오류 감지를 보장합니다. 제한된 수의 비트 플립이 주어지면 CRC는 _ 필요하게 _ 다른 결과를 생성합니다.

이것은 오류가 몇 비트 만 뒤집는 것으로 추정되는 상황에서 유용 할 수 있습니다.
불과 수십 년 전만해도 이는 기본 신호가 여전히 매우 "원시"였기 때문에 특히 전송 시나리오에서 상대적으로 흔했습니다. 따라서 물리 계층에서 감지되지 않은 비트 플립이 문제였습니다.

그러나이 속성에는 배포 비용이 있습니다. "안전한"해밍 거리를 넘으면 충돌 가능성이 더 나빠집니다. 이것은 비둘기 구멍 원칙의 논리적 결과입니다. 얼마나 나빠요? 음, 정확한 CRC에 따라 다르지만 좋은 CRC는 3x-7x 더 나쁜 범위에있을 것으로 예상합니다. 그것은 많이 들릴지 모르지만 그것은 단지 2-3 비트 분산 감소이므로 끔찍하지 않습니다. 아직도.

"이상적인"분포 속성을 특징으로하는 해시와 대조됩니다. 단일 비트이든 완전히 다른 출력이든 모든 변경은 충돌을 생성 할 확률이 정확히 1 / 2 ^ n입니다. 이해하는 것이 더 간단합니다. 충돌 위험은 항상 동일합니다. CRC와 직접 비교하면 해밍 거리가 작을 때는 충돌 률이 더 나쁘지만 (> 0이기 때문에) 해밍 거리가 클 때는 더 좋습니다.

요즘에는 상황이 급격히 변했습니다. 우리는 물리적 매체 위에 오류 감지 및 수정 논리 계층에 계층이 있습니다. 우리는 플래시 블록에서 조금만 추출 할 수 없으며 블루투스 채널에서 조금만 읽을 수도 없습니다. 더 이상 말이되지 않습니다. 이러한 프로토콜은 더 복잡하고 탄력적이며 물리 계층의 영구적 인 노이즈를 지속적으로 보상하는 상태 저장 블록 로직을 포함합니다. 실패하면 단일 플립이 생성되지 않습니다. 오히려 완전한 데이터 영역이 완전히 섞여서 모두 0이거나 임의의 노이즈가됩니다.

이 새로운 환경에서는 오류가 발생했을 때 더 이상 "bitflip"범주에 속하지 않습니다. 이 경우 CRC의 배포 속성은 책임이됩니다. 순수한 해시는 실제로 충돌을 일으킬 확률이 낮습니다.

이것은 체크섬 만 고려할 때입니다.
"이상적인"해시의 추가 속성은 해시에서 비트 세그먼트를 추출 할 때 여전히이 1 / 2^n 충돌 확률을 특징으로하며, 이는 다음과 같은 다른 구조의 비트 소스로 매우 중요합니다. 해시 테이블 또는 블룸 필터. 반대로 CRC는 그러한 보증을 제공하지 않습니다. 일부 비트는 매우 예측 가능하거나 상관 관계가 높으며 해시 목적으로 추출 할 때 분산이 훨씬 더 심합니다.

체크섬과 해싱은 단순히 두 개의 다른 도메인이며 혼동해서는 안된다고 말할 수 있습니다. 사실, 그것이 이론입니다. 문제는 이것이 편리함과 현장 실습을 무시한다는 것입니다. 여러 목적을 위해 하나의 "믹서"를 갖는 것은 편리하며 프로그래머는 하나에 만족하고 잊어 버릴 것입니다. 나는 crc32가 해싱에 사용 된 것을 몇 번이나 보았는지 셀 수 없다. 단지 "충분히 임의적"이라고 느꼈기 때문이다. 일어나서는 안된다고 말하기는 쉽지만 계속해서 발생합니다.
이 환경에서 두 사용 사례 모두에 잘 작동하도록 설계된 솔루션을 제안하는 것은 사용자의 기대와 일치하기 때문에 의미가 있습니다.

PIC / Arduino 군중 내에서 사람들은 여전히 ​​오래된 간단한 8 비트 체크섬, 16 비트 Fletcher 합계 또는 16 비트 CRC를 사용합니다.
(...)
8 비트 또는 16 비트로 줄일 때 해시 함수에 본질적으로 나쁜 것이 있습니까?

좋은 해시의 속성으로 인해 실제로 해시에서 8 비트 또는 16 비트를 추출 할 수 있으며 결과적으로 1/256 또는 1/65535 충돌 확률이 발생합니다. 나는 이것에 대해 걱정하지 않는다.

단지, 우리는 _history_의 지연 시간을 받아 들여야합니다. 사람들은 체크섬을 위해 특정 체크섬 기능을 사용하는 것과 같은 특정 방식에 익숙합니다. 더 최근의 잠재적으로 더 나은 솔루션이 있더라도 습관은 빠르게 변하지 않습니다.

CRC 32와 HD = 6을 사용하면 5 비트 오류를 ​​감지 할 수 있으며 최대 2 ^ 31 = 약 204MB까지 버스트를 감지 할 수 있습니다.
모든 단일 비트 오류 감지
xxHash에서 오류를 감지하지 못하도록 몇 비트를 변경해야합니까?
해시에서 1 비트 변경조차도 완전히 다른 다이제스트를 만드는 것을 알고 있지만 충돌을 만드는 데 필요한 비트 수를 어떻게 계산할 수 있습니까?
또 다른 질문은 말씀하신대로입니다.

반대로 CRC는 그러한 보증을 제공하지 않습니다. 일부 비트는 매우 예측 가능하거나 상관 관계가 높으며 해시 목적으로 추출 할 때 분산이 훨씬 더 심합니다.

왜 나쁜가요? 비트가 어떻게 든 상관 관계가 있다면이 상관 관계를 사용하여 손상된 파일을 복구 할 수 있습니까?

xxHash에서 오류 (또는 충돌)를 감지 할 수 없도록 변경해야하는 비트 수

1 비트.

xxHash는 체크섬이 아닌 비 암호화 해시 함수입니다. 해밍 거리 또는 충돌 저항을 보장하지 않습니다.

괜찮은 일을 할 수는 있지만 최선의 선택은 아닙니다. 펜치를 렌치로 사용하는 것과 같습니다. 물론 작업을 완료 할 수 있지만 실제 렌치보다 효과가 떨어지고 손상을 입힐 수 있습니다.

xxHash에서 오류 (또는 충돌)를 감지 할 수 없도록 변경해야하는 비트 수

1 비트.

xxHash는 체크섬이 아닌 비 암호화 해시 함수입니다. 해밍 거리 또는 충돌 저항을 보장하지 않습니다.

괜찮은 일을 할 수는 있지만 최선의 선택은 아닙니다. 펜치를 렌치로 사용하는 것과 같습니다. 물론 작업을 완료 할 수 있지만 실제 렌치보다 효과가 떨어지고 손상을 입힐 수 있습니다.

1 비트의 데이터 만 변경해도 디코더를 속일 수 있다는 뜻입니까?
충돌을 일으킬 수 있습니까? (무섭습니다) 그리고 그러한 충돌의 가능성은 다이제스트 크기에 따라 달라집니다

1 비트의 데이터 만 변경해도 디코더를 속일 수 있다는 뜻입니까?

2 개의 다른 콘텐츠에서 생성 된 해시 값을 고려할 때 충돌 확률은 항상 1 / 2^64 ( xxh64 또는 xxh3 와 같은 양질의 64 비트 해시 알고리즘의 경우). 이 두 콘텐츠 사이의 수 정량.

실제로 적어도 이론적으로는 단일 비트의 변경이 충돌을 생성 할 수 있음을 의미합니다.

이제이 확률은 1 / 2^64 이며, 이는 거의 극소수입니다.
사람들은이 주제를 비교적 잘 이해하지 못합니다. 그들은 때때로 그것을 "작은"과 혼동하는데, 이는 대부분의 사람들의 마음에서 ~ 10 %처럼 실질적인 양으로 인식되는 경향이 있습니다.

보다 정확한 아이디어를 얻기 위해 다음 표를 참조합니다.

ie : 1 / 2 ^ 64 은 머리에 직접 혜성을받을 확률보다 훨씬 낮고, 전국 복권 _3 번 연속 당첨되는 것보다 훨씬 낮습니다. 이것은 실제로 "null"에 훨씬 더 가깝습니다. 모든 시스템의 대부분의 구성 요소는 다른 소프트웨어 버그 소스부터 시작하여 그보다 훨씬 더 높은 확률로 중단되기 쉽습니다.

그러한 이론적 인 1 비트 충돌을 찾고자한다면이 문제에 대한 해결책을 무차별 대입하기 위해서는 상당히 거대한 입력과 믿을 수 없을 정도의 힘이 필요합니다. 그럼에도 불구하고 솔루션이 존재하지 않을 수 있습니다. 사용 된 산술의 특성을 고려할 때 단일 비트 수정으로 충돌을 생성하는 것이 불가능하더라도 놀라지 않을 것입니다. 내 생각은 적어도 2 비트가 필요하다는 것인데, 그럴 경우에도 원하는 목표를 달성 할 수있는 기회를 얻기 위해 특정 입력 위치에 배치해야하므로 이러한 수정이 더 이상 "무작위"가 아니므로 범위를 벗어납니다. 비 암호화 해시.

하지만 인용 된 텍스트가 이미이 모든 것을 설명하고 있다고 생각합니다. 실제 crc 는 해밍 거리를 보장합니다. 이것은 유용 할 수 있으며, 과거에는 신호가 비트 레벨에서 수정되기 쉬웠을 때와 체크섬 자체가 다소 작을 때 (16 비트 또는 32 비트) 훨씬 더 의미가있었습니다. 16 비트 해시 알고리즘은 매우 적은 비트 플립과 관련된 충돌을 놓칠 수있는 무시할 수없는 기회를 가지므로 작업에 덜 적합합니다. 그러나 이제 64 비트 또는 128 비트 해시가 테이블에 있으므로 충돌 가능성, 따라서 감지되지 않은 손상의 가능성이 헤아릴 수 없을 정도로 적기 때문에 더 이상 위험한 옵션이 아니라고 생각합니다.

일부 비트는 매우 예측 가능하거나 상관 관계가 높으며 해시 목적으로 추출 할 때 분산이 훨씬 더 심합니다.

왜 나쁜가요?

해시는 일반적으로 체크섬 교체보다 더 많은 용도로 사용됩니다.
실제로 대부분의 경우 해시 알고리즘의 목적은 해시 테이블에서 위치를 지정하기 위해 임의의 비트를 제공하는 것입니다. 이러한 비트 중 일부가 내용에 따라 예측 가능 해지면 해시 테이블의 위치 분포가 더 이상 "무작위"가되지 않고 결과적으로 일부 셀이 다른 셀보다 더 빨리 오버플로되어 해시 테이블의 성능에 부정적인 영향을 미칩니다. .

비트가 어떻게 든 상관 관계가 있다면이 상관 관계를 사용하여 손상된 파일을 복구 할 수 있습니까?

이것은 완전히 다른 주제입니다.
하나는 CRC로 손상된 입력을 복구하지 않습니다. CRC는 오류를 감지 할 수만 있고 복구 할 수는 없습니다.

자가 복구 데이터는 주제이며 컨볼 루션 코드와 같은 다른 (그리고 훨씬 더 계산적으로 관련된) 기술을 사용합니다. 이것은 훨씬 더 복잡합니다.

그러한 이론적 인 1 비트 충돌을 찾고자한다면이 문제에 대한 해결책을 무차별 대입하기 위해서는 상당히 거대한 입력과 믿을 수 없을 정도의 힘이 필요합니다. 그럼에도 불구하고 솔루션이 존재하지 않을 수 있습니다. 사용 된 산술의 특성을 고려할 때 단일 비트 수정으로 충돌을 생성하는 것이 불가능하더라도 놀라지 않을 것입니다. 내 생각은 적어도 2 비트가 필요하다는 것인데, 그럴 경우에도 원하는 목표를 달성 할 수있는 기회를 얻기 위해 특정 입력 위치에 배치해야하므로 이러한 수정이 더 이상 "무작위"가 아니므로 범위를 벗어납니다. 비 암호화 해시.

261은 XXH3의 64 비트 변형에서 단일 비트 충돌을 보여줍니다.

과연; 좀 더 완벽하게 말하면, 내 이전 진술은 240 바이트 이상의 입력에 대해 큰 크기 섹션에 대한 것이 었습니다.

그러나 예, 입력이 64 비트 secret 중 하나와 정확히 일치해야하는 제한된 범위의 크기에서는 단일 비트 충돌이 가능합니다. 정확한 위치에서 정확한 64 비트 입력을 기반으로 한 충돌이 여전히이 1 / 2^64 영역 내에 있기 때문에 수용 가능하다고 느꼈습니다. 입력이 임의적이라고 가정합니다 (즉, 충돌을 생성하도록 설계되지 않음). 또한 일치시킬 secret 는 효과적으로 _secret_ 만들 수 있으므로 외부 공격자가이를 찾으려면 무차별 대입해야합니다.

1 비트의 데이터 만 변경해도 디코더를 속일 수 있다는 뜻입니까?

2 개의 다른 콘텐츠에서 생성 된 해시 값을 고려할 때 충돌 확률은 항상 1 / 2^64 ( xxh64 또는 xxh3 와 같은 양질의 64 비트 해시 알고리즘의 경우). 이 두 콘텐츠 사이의 수 정량.

실제로 적어도 이론적으로는 단일 비트의 변경이 충돌을 생성 할 수 있음을 의미합니다.

이제이 확률은 1 / 2^64 이며, 이는 거의 극소수입니다.
사람들은이 주제를 비교적 잘 이해하지 못합니다. 그들은 때때로 그것을 "작은"과 혼동하는데, 이는 대부분의 사람들의 마음에서 ~ 10 %처럼 실질적인 양으로 인식되는 경향이 있습니다.

보다 정확한 아이디어를 얻기 위해 다음 표를 참조합니다.

ie : 1 / 2 ^ 64 은 머리에 직접 혜성을받을 확률보다 훨씬 낮고, 전국 복권 _3 번 연속 당첨되는 것보다 훨씬 낮습니다. 이것은 실제로 "null"에 훨씬 더 가깝습니다. 모든 시스템의 대부분의 구성 요소는 다른 소프트웨어 버그 소스부터 시작하여 그보다 훨씬 더 높은 확률로 중단되기 쉽습니다.

그러한 이론적 인 1 비트 충돌을 찾고자한다면이 문제에 대한 해결책을 무차별 대입하기 위해서는 상당히 거대한 입력과 믿을 수 없을 정도의 힘이 필요합니다. 그럼에도 불구하고 솔루션이 존재하지 않을 수 있습니다. 사용 된 산술의 특성을 고려할 때 단일 비트 수정으로 충돌을 생성하는 것이 불가능하더라도 놀라지 않을 것입니다. 내 생각은 적어도 2 비트가 필요하다는 것인데, 그럴 경우에도 원하는 목표를 달성 할 수있는 기회를 얻기 위해 특정 입력 위치에 배치해야하므로 이러한 수정이 더 이상 "무작위"가 아니므로 범위를 벗어납니다. 비 암호화 해시.

하지만 인용 된 텍스트가 이미이 모든 것을 설명하고 있다고 생각합니다. 실제 crc 는 해밍 거리를 보장합니다. 이것은 유용 할 수 있으며, 과거에는 신호가 비트 레벨에서 수정되기 쉬웠을 때와 체크섬 자체가 다소 작을 때 (16 비트 또는 32 비트) 훨씬 더 의미가있었습니다. 16 비트 해시 알고리즘은 매우 적은 비트 플립과 관련된 충돌을 놓칠 수있는 무시할 수없는 기회를 가지므로 작업에 덜 적합합니다. 그러나 이제 64 비트 또는 128 비트 해시가 테이블에 있으므로 충돌 가능성, 따라서 감지되지 않은 손상의 가능성이 헤아릴 수 없을 정도로 적기 때문에 더 이상 위험한 옵션이 아니라고 생각합니다.

일부 비트는 매우 예측 가능하거나 상관 관계가 높으며 해시 목적으로 추출 할 때 분산이 훨씬 더 심합니다.

왜 나쁜가요?

해시는 일반적으로 체크섬 교체보다 더 많은 용도로 사용됩니다.
실제로 대부분의 경우 해시 알고리즘의 목적은 해시 테이블에서 위치를 지정하기 위해 임의의 비트를 제공하는 것입니다. 이러한 비트 중 일부가 내용에 따라 예측 가능 해지면 해시 테이블의 위치 분포가 더 이상 "무작위"가되지 않고 결과적으로 일부 셀이 다른 셀보다 더 빨리 오버플로되어 해시 테이블의 성능에 부정적인 영향을 미칩니다. .

비트가 어떻게 든 상관 관계가 있다면이 상관 관계를 사용하여 손상된 파일을 복구 할 수 있습니까?

이것은 완전히 다른 주제입니다.
하나는 CRC로 손상된 입력을 복구하지 않습니다. CRC는 오류를 감지 할 수만 있고 복구 할 수는 없습니다.

자가 복구 데이터는 주제이며 컨볼 루션 코드와 같은 다른 (그리고 훨씬 더 계산적으로 관련된) 기술을 사용합니다. 이것은 훨씬 더 복잡합니다.

이러한 시나리오를 확인할 수 있습니까?

1. LZ4에는 각 데이터 블록에 대한 콘텐츠 체크섬이 있습니다. 1GB 파일의 10 ^ 6 패킷이 있다고 가정합니다.
   충돌 확률은 1 / 2 ^ 32 = 0.0000000002입니다. 즉, 10 ^ 10 (이 거대한 크기) 패킷을 보내면 두 번의 충돌 (Pigeonhole 원칙에 따라)이있을 수 있지만이 양보다 적게 보내면 확률이 모든 오류를 감지하고 디코더가 체크섬을 계산하여 패킷 체크섬과 비교하기 위해 충돌이 크게 감소합니다. 이것이 맞습니까?
2. 콘텐츠 체크섬은 압축 된 파일에 대한 체크섬을 계산합니다 (선택 사항이며이를 사용하여 순서가 맞지 않는 것을 감지하거나 충돌 확률을 줄일 수 있습니다 (CC를 사용하기 전에 충돌 확률은 1/2 ^ 32이고 그러면 1/2 ^ 64.)

설명 된 시나리오는 다음과 같습니다.

• LZ4 압축 데이터가 손상됨 (이미 그 자체로는 매우 드문 이벤트 임)
• 해시 충돌로 인해 감지되지 않은 손상이 남아 있습니다.

LZ4 프레임 형식은 32 비트 해시 인 XXH32 동반 체크섬으로 사용합니다.
기본적으로 전체 프레임의 콘텐츠,보다 정확하게는 프레임의 _uncompressed_ 콘텐츠 (압축 해제 후)에 적용되어 전송 및 디코딩 프로세스를 모두 검증합니다.
또한 선택적으로 각 블록에 적용 할 수 있으며,이 경우 각 블록의 _compressed_ 내용을 체크섬합니다.
둘 다 누적 될 수 있습니다.

감지되지 않은 상태로 유지하려면 손상이 ___all___ 해당하는 체크섬을 성공적으로 통과해야합니다.
블록 체크섬이 활성화되어 있고 손상이 완전히 단일 블록 내에 있다고 가정하면 블록과 프레임 체크섬을 모두 통과 할 가능성은 실제로 1 / 2^32 x 1 / 2^32 = 1 / 2^64 입니다.

이제 여러 손상 이벤트가 있거나 하나의 큰 손상된 섹션이 연속 블록을 포함하기 때문에 손상된 데이터가 여러 블록에 상주하는 경우 _ 손상이 감지되지 않은 상태로 유지되는 것이 더 어렵습니다 _. 관련된 각 블록 체크섬과 충돌을 생성해야합니다.
예를 들어, 손상이 2 개의 블록으로 확산되었다고 가정하면이 손상이 탐지되지 않은 채로 남아있을 가능성은 1 / 2^32 x 1 / 2^32 x 1 / 2^32 = 1 / 2^96 입니다. 천문학적으로 작습니다.

각 손상된 블록이 압축 해제 프로세스에 의해 해독 불가능한 것으로 감지 될 수 있다는 사실을 계산하지 않습니다.

예, 블록과 프레임 체크섬을 결합하면 손상 이벤트를 감지 할 가능성이 크게 높아집니다.

설명 된 시나리오는 다음과 같습니다.

* LZ4-compressed data being corrupted (which is already a pretty rare event by itself)

* Corruption remaining undetected due to hash collision.

LZ4 프레임 형식은 32 비트 해시 인 XXH32 동반 체크섬으로 사용합니다.
기본적으로 전체 프레임의 콘텐츠,보다 정확하게는 프레임의 _uncompressed_ 콘텐츠 (압축 해제 후)에 적용되어 전송 및 디코딩 프로세스를 모두 검증합니다.
또한 선택적으로 각 블록에 적용 할 수 있으며,이 경우 각 블록의 _compressed_ 내용을 체크섬합니다.
둘 다 누적 될 수 있습니다.

감지되지 않은 상태로 유지하려면 손상이 _ 모든 _ 적용 가능한 체크섬을 성공적으로 통과해야합니다.
블록 체크섬이 활성화되어 있고 손상이 완전히 단일 블록 내에 있다고 가정하면 블록과 프레임 체크섬을 모두 통과 할 가능성은 실제로 1 / 2^32 x 1 / 2^32 = 1 / 2^64 입니다.

이제 여러 손상 이벤트가 있거나 하나의 큰 손상된 섹션이 연속 블록을 포함하기 때문에 손상된 데이터가 여러 블록에 상주하는 경우 _ 손상이 감지되지 않은 상태로 유지되는 것이 더 어렵습니다 _. 관련된 각 블록 체크섬과 충돌을 생성해야합니다.
예를 들어, 손상이 2 개의 블록에 퍼져 있다고 가정하면이 손상이 탐지되지 않은 채로 남아있을 가능성은 1 / 2^32 x 1 / 2^32 x 1 / 2^32 = 1 / 2^96 입니다. 천문학적으로 작습니다.

각 손상된 블록이 압축 해제 프로세스에 의해 해독 불가능한 것으로 감지 될 수 있다는 사실을 계산하지 않습니다.

예, 블록과 프레임 체크섬을 결합하면 손상 이벤트를 감지 할 가능성이 크게 높아집니다.

LZ4를 즉석에서 사용할 수 있습니까? 내 말은, 데이터를 확보하자마자 데이터를 압축 / 압축 해제하는 것입니다. 어떻게 든 파이프 라이닝입니다.
xxHash는 어떻습니까?

LZ4를 즉석에서 사용할 수 있습니까? 내 말은, 데이터를 확보하자마자 데이터를 압축 / 압축 해제하는 것입니다.

이것이 스트리밍 모드입니다. 네 가능합니다.

xxHash는 어떻습니까?

프레임 체크섬은 지속적으로 업데이트되지만 프레임 끝에서만 결과를 생성합니다. 따라서 프레임 이벤트가 끝날 때까지 비교할 체크섬 결과가 없습니다 (스트림은 여러 개의 추가 된 프레임으로 구성 될 수 있지만 일반적으로 그렇지 않습니다).

대조적으로 블록 체크섬은 각 블록에서 생성되므로 스트리밍 중에 정기적으로 생성되고 확인됩니다.

두 체크섬 모두 XXH32 합니다.