3 ms·

> I feel like the properties of CRC make them superior for that task in most cases though. THIS IS FALSE. Please do not ever do this. Why not? For example, by

by IncRnd 4y ago

> I feel like the properties of CRC make them superior for that task in most cases though. THIS IS FALSE. Please do not ever do this. Why not? For example, by controlling any four contiguous bytes in a file, the resultant 32bit CRC can be forced to take on any value. A CRC is meant to detect errors due to noise - not changes due to a malicious actor. Program design should not be done based upon one's feelings. CRCs absolutely do not have the required properties to detect duplication or to preserve integrity of a stored file that an attacker can modify.

dragontamer 4y ago
> THIS IS FALSE. Please do not ever do this. Why not? For example, by controlling any four contiguous bytes in a file, the resultant 32bit CRC can be forced to take on any value. And SHA1 is now broken like this, with collisions and so forth. Perhaps it's not as simple as just 4 bytes, but the ability to create collisions is forcing this retirement. If adversarial collisions are an issue, then MD5 and SHA1 are fully obsolete now. If you don't care for an adversary, might as well use the cheaper, faster CRC check. ------ CRC is now more valid use case than SHA1. That's the point of this announcement.
- IncRnd 4y ago
  > CRC is now more valid use case than SHA1. That's the point of this announcement. No. That isn't the point of this announcement. This announcement codifies a transition time for SHA-1 use in SBU and has nothing to do with a CRC.
  - Dylan16807 4y ago
    The point of the announcement is to give a timeline to start treating SHA1 as having no real security. This is relevant to when you'd choose CRC, because it also has no real security.
    - IncRnd 4y ago
      > The point of the announcement is to give a timeline to start treating SHA1 as having no real security. That's also false. There is a large body of knowledge here that you aren't expressing in your comments. That leads me to see that you are unfamiliar with the purposes of hash functions and their utility in real world situations. The announcement refers to the transition timeline to stop using SHA-1, preferring the SHA-2 and SHA-3 families. However, the recommendations for years from NIST have been not to use SHA-1. For example SP 800-131Ar2 discusses not to use SHA-1 for digital sig gen and that digital sig ver is only acceptable for legacy uses. The recommendation would have been for years to not use SHA-1 at all, except for this carve-out to handle already stored data that uses SHA-1. The remaining use cases cover protocol use, such as TLS, where SHA-1 is used as a component in constructs and not solely as a primitive.
      - Dylan16807 4y ago
        > That leads me to see that you are unfamiliar with the purposes of hash functions and their utility in real world situations. Don't post like this, please.

by IncRnd 4y ago

dragontamer 4y ago

> THIS IS FALSE. Please do not ever do this. Why not? For example, by controlling any four contiguous bytes in a file, the resultant 32bit CRC can be forced to take on any value. And SHA1 is now broken like this, with collisions and so forth. Perhaps it's not as simple as just 4 bytes, but the ability to create collisions is forcing this retirement. If adversarial collisions are an issue, then MD5 and SHA1 are fully obsolete now. If you don't care for an adversary, might as well use the cheaper, faster CRC check. ------ CRC is now more valid use case than SHA1. That's the point of this announcement.

IncRnd 4y ago
> CRC is now more valid use case than SHA1. That's the point of this announcement. No. That isn't the point of this announcement. This announcement codifies a transition time for SHA-1 use in SBU and has nothing to do with a CRC.
- Dylan16807 4y ago
  The point of the announcement is to give a timeline to start treating SHA1 as having no real security. This is relevant to when you'd choose CRC, because it also has no real security.
  - IncRnd 4y ago
    > The point of the announcement is to give a timeline to start treating SHA1 as having no real security. That's also false. There is a large body of knowledge here that you aren't expressing in your comments. That leads me to see that you are unfamiliar with the purposes of hash functions and their utility in real world situations. The announcement refers to the transition timeline to stop using SHA-1, preferring the SHA-2 and SHA-3 families. However, the recommendations for years from NIST have been not to use SHA-1. For example SP 800-131Ar2 discusses not to use SHA-1 for digital sig gen and that digital sig ver is only acceptable for legacy uses. The recommendation would have been for years to not use SHA-1 at all, except for this carve-out to handle already stored data that uses SHA-1. The remaining use cases cover protocol use, such as TLS, where SHA-1 is used as a component in constructs and not solely as a primitive.
    - Dylan16807 4y ago
      > That leads me to see that you are unfamiliar with the purposes of hash functions and their utility in real world situations. Don't post like this, please.