CRC가 MD5 / SHA1보다 사용하기에 더 적합한시기는 언제입니까?

CRC가 MD5 / SHA1보다 사용하기에 더 적합한시기는 언제입니까?

---

MD5 또는 SHA1과 같은 최신 해싱 함수와 비교하여 오류 감지에 CRC를 사용하는 것이 언제 적절한가요? 전자는 임베디드 하드웨어에서 구현하기가 더 쉽습니까?

---

CRC는 네트워크 간섭, 라인 노이즈, 왜곡 등 발생할 수있는 데이터의 임의 오류를 감지하는 데 적합합니다.

CRC는 MD5 또는 SHA1보다 계산이 훨씬 덜 복잡합니다. MD5와 같은 해시 함수를 사용하는 것은 임의 오류 감지에 과잉 일 수 있습니다. 그러나 모든 종류의 보안 검사에 CRC를 사용하는 것은 MD5와 같은보다 복잡한 해싱 기능보다 훨씬 안전하지 않습니다.

그리고 그렇습니다. CRC는 임베디드 하드웨어에서 구현하기가 훨씬 쉬우 며 IC에서 다양한 패키지 솔루션을 얻을 수도 있습니다.

---

CRC는 의도하지 않은 데이터 변경에 대비하여 설계되었습니다. 즉, 의도하지 않은 오류를 감지하는 데는 좋지만 데이터가 악의적으로 처리되지 않도록하는 방법으로는 쓸모가 없습니다.

이것도 참조 하십시오 .

---

이 PHP 코드의 모든 줄을 1.000.000 루프로 실행했습니다. 결과는 주석 (#)으로 표시됩니다.

hash('crc32', 'The quick brown fox jumped over the lazy dog.');#  750ms   8 chars
hash('crc32b','The quick brown fox jumped over the lazy dog.');#  700ms   8 chars
hash('md5',   'The quick brown fox jumped over the lazy dog.');#  770ms  32 chars
hash('sha1',  'The quick brown fox jumped over the lazy dog.');#  880ms  40 chars
hash('sha256','The quick brown fox jumped over the lazy dog.');# 1490ms  64 chars
hash('sha384','The quick brown fox jumped over the lazy dog.');# 1830ms  96 chars
hash('sha512','The quick brown fox jumped over the lazy dog.');# 1870ms 128 chars

내 결론 :

• http://en.wikipedia.org/wiki/Cyclic_redundancy_check 가 필요 하고 보안에 신경 쓰지 않을 때는 "crc32b"를 사용하십시오 .

• 보안 계층을 추가해야 할 경우 "sha256"이상을 사용하십시오.

• "md5"또는 "sha1"은 다음과 같은 이유로 사용하지 마십시오.

  1. 보안에 관한 일부 보안 문제
  2. CRC 만 있으면 해시 문자열이 길고 "crc32b"보다 느립니다.

---

CRC 해시가 해시 테이블에 얼마나 부적절한 지 보여주는 연구 결과가 있습니다 . 또한 알고리즘의 실제 특성에 대해서도 설명합니다. 이 연구 에는 다른 해시 알고리즘에 대한 평가도 포함되며 유지하기에 좋은 참고 자료입니다.

해시에 대한 CRC 관련 결론 :

CRC32는 해시 테이블 사용을위한 것이 아닙니다. 이 목적으로 사용할 이유가 없으므로 그렇게하지 않는 것이 좋습니다. CRC32를 사용하기로 결정했다면 키 옥텟이 공급되는 것과 반대의 끝에서 해시 비트를 사용하는 것이 중요합니다.이 끝은 특정 CRC32 구현에 따라 다릅니다. CRC32를 "블랙 박스"해시 함수로 취급하지 말고 범용 해시로 사용하지 마십시오. 각 응용 프로그램의 적합성을 테스트하십시오.

최신 정보

사이트가 다운 된 것 같습니다. 인터넷 아카이브 사본이 생각을.

---

구현, 속도 및 안정성에 대한 CRC 정보는 CRC 오류 감지 알고리즘에 대한 간단한 안내서를 참조하십시오 . CRC에 모든 것이 있습니다.

누군가가 데이터를 악의적으로 수정하려고 시도하지 않는 한 CRC 변경으로 충분하지 않습니다. "좋은"(표준) 정치를 사용하십시오.

---

보호하려는 것이 무엇인지 말하지 않습니다.

CRC는 악성 시스템 수정을 방지하는 대신 우발적 인 데이터 손상을 방지하기 위해 임베디드 시스템에서 종종 사용됩니다. CRC가 유용한 장소의 예는 시스템 초기화 중에 펌웨어 손상을 방지하기 위해 EPROM 이미지를 검증하는 것입니다. 시스템 부트 로더는 응용 프로그램 코드에 대한 CRC를 계산하고 코드를 실행하기 전에 저장된 값과 비교합니다. 우발적 인 프로그램 손상 또는 다운로드 실패 가능성을 방지합니다.

FLASH 또는 EEPROM에 저장된 구성 데이터를 보호하기 위해 CRC를 유사한 방식으로 사용할 수도 있습니다. CRC가 올바르지 않으면 데이터가 유효하지 않은 것으로 플래그 될 수 있으며 기본 또는 백업 데이터 세트가 사용됩니다. 장치 오류로 인해 또는 구성 데이터 저장소를 업데이트하는 동안 사용자가 전원을 차단 한 경우 CRC가 유효하지 않을 수 있습니다.

해시는 다중 비트 오류가있는 CRC보다 손상을 감지 할 가능성이 더 높다는 의견이 있습니다. 이것은 사실이며, 16 비트 또는 32 비트 CRC 사용 여부에 대한 결정은 사용중인 손상된 데이터 블록의 안전 결과와 2 ^ 16 또는 2 ^ 32 확률의 1을 정당화 할 수 있는지 여부에 달려 있습니다. 데이터 블록이 잘못 선언 된 것으로 유효합니다.

많은 장치에는 표준 알고리즘을위한 내장 CRC 생성기가 있습니다. Texas의 MSP430F5X 시리즈에는 CRC-CCITT 표준의 하드웨어 구현이 있습니다.

---

그것은 모두 요구 사항과 기대에 달려 있습니다.

다음은 이러한 해시 함수 알고리즘 간의 간단한 차이점입니다 .

CRC (CRC-8 / 16 / 32 / 64)

• 암호화 해싱 알고리즘 이 아닙니다 (순환 중복 검사를 기반으로하는 선형 함수를 사용함)
• 9, 17, 33 또는 65 비트를 생성 할 수 있음
• 암호화를 보장하지 않으므로 암호화 목적으로 사용되지 않습니다.
• ^{2006 년} 쉽게 뒤집을 수 있기 때문에 디지털 서명에 사용하기에 부적합합니다 .
• 암호화 목적으로 사용해서는 안됩니다.
• 다른 줄이 충돌을 일으킬 수 있습니다.
• 1961 년에 발명되어 이더넷 및 기타 여러 표준에서 사용됩니다.

MD5

• 암호화 해시 알고리즘입니다.
• 128 비트 (16 바이트) 해시 값 (32 자리 16 진수) 생성
• 암호화 해시이지만 보안이 걱정된다면 더 이상 사용되지 않는 것으로 간주됩니다.
• 동일한 MD5 해시 값을 가진 알려진 문자열이 있습니다.
• 암호화 목적으로 사용될 수 있습니다.

SHA-1

• 암호화 해시 알고리즘입니다.
• produces a 160-bit (20-byte) hash value known as a message digest
• it is a cryptographic hash and since 2005 it's no longer considered secure,
• can be used for encryption purposes,
• an example of a sha1 collision has been found
• first published in 1993 (as SHA-0), then 1995 as SHA-1,

• series: SHA-0, SHA-1, SHA-2, SHA-3,

  In summary, using SHA-1 is no longer considered secure against well-funded opponents, because in 2005, cryptanalysts found attacks on SHA-1 which suggests it may be not secure enough for ongoing use^schneier. U.S. NIST advise that federal agencies should stop using SHA1-1 for application which require collision resistance and must use SHA-2 after 2010^NIST.

Therefore, if you're looking for simple and quick solution for checking the integrity of a files (against the corruption), or for some simple caching purposes in terms of performance, you can consider CRC-32, for hashing you may consider to use MD5, however if you're developing professional application (which should be secure and consistent), to avoid any collision probabilities - use SHA-2 and above (such as SHA-3).

Performance

Some simple benchmark test in PHP:

# Testing static text.

$ time php -r 'for ($i=0;$i<1000000;$i++) crc32("foo");'
real    0m0.845s
user    0m0.830s
sys     0m0.008s

$ time php -r 'for ($i=0;$i<1000000;$i++) md5("foo");'
real    0m1.103s
user    0m1.089s
sys     0m0.009s

$ time php -r 'for ($i=0;$i<1000000;$i++) sha1("foo");'
real    0m1.132s
user    0m1.116s
sys   0m0.010s

# Testing random number. 

$ time php -r 'for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'
real    0m1.754s
user    0m1.735s
sys     0m0.012s\

$ time php -r 'for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'
real    0m2.065s
user    0m2.042s
sys     0m0.015s

$ time php -r 'for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'
real    0m2.050s
user    0m2.021s
sys     0m0.015s

---

Related:

• What’s the difference between md5(), crc32() and sha1() crypto on PHP?

---

CRC32 is faster and the hash is only 32bits long.

Use it when you just want a quick and light checksum. CRC is used in ethernet.

If you need more reliability it's preferable to use a modern hashing function.

---

Only use CRC if computation resources are very tight (i.e. some embed environments) or you need to store/transport many output values and space/bandwidth is tight (as CRCs are usually 32-bit where an MD5 output is 128-bit, SHA1 160 bit, and other SHA variants up to 512 bit).

Never use CRC for security checks as a CRC is very easy to "fake".

Even for accidental error detection (rather than malicious change detection) hashes are better than a simple CRC. Partly because of the simple way a CRC is calculated (and partly because CRC values are usual shorter than common hash outputs so have a much smaller range of possible values) it is much more likely that, in a situation where there are two or more errors, one error will mask another so you end up with the same CRC despite two errors.

In short: unless you have reason not to use a decent hash algorithm, avoid simple CRCs.

---

I came across a use of CRC recently which was smart. The author of the jdupe file duplication identification and removal tool (the same author of the popular exif tool jhead) uses it during the first pass through the files. A CRC is computed on the first 32K of each file to mark files that appear to be the same, also the files must have the same size. These files are added to a list of files on which to do a full binary comparison. It speeds up checking large media files.

---

CRC32 is way faster and sometimes has hardware support (i.e. on Nehalem processors). Really, the only time you'd use it is if you're interfacing with hardware, or if you're really tight on performance

---

Lets start with the basics.

In Cryptography, a hashing algorithm converts many bits to fewer bits through a digest operation. Hashes are used to confirm integrity of messages and files.

All hashing algorithms generate collisions. A collision is when several many-bit combinations produce the same fewer bit output. The cryptographic strength of a hashing algorithm is defined by the inability for an individual to determine what the output is going to be for a given input because if they could they could construct a file with a hash that matches a legitimate file and compromise the assumed integrity of the system. The difference between CRC32 and MD5 is that MD5 generates a larger hash that's harder to predict.

When you want to implement message integrity - meaning the message hasn't been tampered with in transit - the inability to predict collisions is an important property. A 32-bit hash can describe 4 billion different messages or files using 4 billion different unique hashes. If you have 4 billion and 1 files, you are guaranteed to have 1 collision. 1 TB Bitspace has the possibility for Billions of Collisions. If I'm an attacker and I can predict what that 32 bit hash is going to be, I can construct an infected file that collides with the target file; that has the same hash.

Additionally if I'm doing 10mbps transmission then the possibility of a packet getting corrupted just right to bypass crc32 and continue along the to the destination and execute is very low. Lets say at 10mbps I get 10 errors\second. If I ramp that up to 1gbps, now I'm getting 1,000 errors per second. If I ram up to 1 exabit per second, then I have an error rate of 1,000,000,000 errors per second. Say we have a collision rate of 1\1,000,000 transmission errors, Meaning 1 in a million transmission errors results in the corrupt data getting through undetected. At 10mbps I'd get error data being sent every 100,000 seconds or about once a day. At 1gbps it'd happen once every 5 minutes. At 1 exabit per second, we're talking several times a second.

If you pop open Wireshark you'll see your typical Ethernet header has a CRC32, your IP header has a CRC32, and your TCP Header has a CRC32, and that's in addition to the what the higher layer protocols may do; e.g. IPSEC might use MD5 or SHA for integrity checking in addition to the above. There are several layers of error checking in typical network communications, and they STILL goof now and again at sub 10mbps speeds.

Cyclic Redundancy Check (CRC) has several common versions and several uncommon but generally is designed to just tell when a message or file has been damaged in transit (multiple bits flipping). CRC32 by itself is not a very good error checking protocol by today's standards in large, scalar enterprise environments because of the collision rate; the average users hard-drive can have upwards of 100k files, and file-shares on a company can have tens of millions. The ratio of hash-space to the number of files is just too low. CRC32 is computationally cheap to implement whereas MD5 isn't.

MD5 was designed to stop intentional use of collisions to make a malicious file look benign. It's considered insecure because the hashspace has been sufficiently mapped to enable some attacks to occur, and some collisions are predictable. SHA1 and SHA2 are the new kids on the block.

For file verification, Md5 is starting to be used by a lot of vendors because you can do multigigabyte files or multiterrabyte files quickly with it and stack that on top of the general OS's use and support of CRC32's. Do not be surprised if within the next decade filesystems start using MD5 for error checking.

---

CRC code is simpler and faster.

For what do you need any?

참고URL : https://stackoverflow.com/questions/996843/when-is-crc-more-appropriate-to-use-than-md5-sha1