And like I said before CRC is a code that 7zip uses to identify each file. CRC stands for Cyclic Redundancy check, which is a code 7zip uses to detect accidental changes to raw computer data.
CRCs are specifically designed to protect against common types of errors on communication channels, where they can provide quick and reasonable assurance of the integrity of messages delivered. However, they are not suitable for protecting against intentional alteration of data. Firstly, as there is no authentication, an attacker can edit a message and recalculate the CRC without the substitution being detected. This is even the case when the CRC is encrypted, leading to one of the design flaws of the WEP protocol.[3] Secondly, the linear properties of CRC codes even allow an attacker to modify a message in such a way as to leave the check value unchanged,[4][5] and otherwise permit efficient recalculation of the CRC for compact changes. Nonetheless, it is still often falsely assumed that when a message and its correct check value are received from an open channel then the message cannot have been altered in transit.[6]
Cryptographic hash functions, while still not providing security against intentional alteration when used in this manner, can provide stronger error checking in that they do not rely on specific error pattern assumptions.[citation needed] However, they are much slower than CRCs, and are therefore commonly used to protect off-line data, such as files on servers or databases.
When stored alongside the data, CRCs and cryptographic hash functions by themselves do not protect against intentional modification of data. Any application that requires protection against such attacks must use cryptographic authentication mechanisms, such as message authentication codes.
To sum it all up here is a link to all you need to know about CRC. http://en.wikipedia.org/wiki/Cyclic_redundancy_check Next time you might want to try a little research before criticizing people and taking sides with someone when you clearly have no idea what you are talking about.
CRCs are specifically designed to protect against common types of errors on communication channels, where they can provide quick and reasonable assurance of the integrity of messages delivered. However, they are not suitable for protecting against intentional alteration of data. Firstly, as there is no authentication, an attacker can edit a message and recalculate the CRC without the substitution being detected. This is even the case when the CRC is encrypted, leading to one of the design flaws of the WEP protocol.[3] Secondly, the linear properties of CRC codes even allow an attacker to modify a message in such a way as to leave the check value unchanged,[4][5] and otherwise permit efficient recalculation of the CRC for compact changes. Nonetheless, it is still often falsely assumed that when a message and its correct check value are received from an open channel then the message cannot have been altered in transit.[6]
Cryptographic hash functions, while still not providing security against intentional alteration when used in this manner, can provide stronger error checking in that they do not rely on specific error pattern assumptions.[citation needed] However, they are much slower than CRCs, and are therefore commonly used to protect off-line data, such as files on servers or databases.
When stored alongside the data, CRCs and cryptographic hash functions by themselves do not protect against intentional modification of data. Any application that requires protection against such attacks must use cryptographic authentication mechanisms, such as message authentication codes.
To sum it all up here is a link to all you need to know about CRC. http://en.wikipedia.org/wiki/Cyclic_redundancy_check Next time you might want to try a little research before criticizing people and taking sides with someone when you clearly have no idea what you are talking about.
, tjue links send me to the front page...
