3 ms·

When will CRC32c (also used in https://en.wikipedia.org/wiki/Ethernet_frame#Frame_check_sequence https://en.wikipedia.org/wiki/Ethernet_frame#Frame_check_seq...

When will CRC32c (also used in https://en.wikipedia.org/wiki/Ethernet_frame#Frame_check_sequence https://en.wikipedia.org/wiki/Ethernet_frame#Frame_check_seq... ), MD5, etc get removed? Sure they aren't supported for _security_ use, and should not be used by anything new. However the algorithms will likely continue to exist in libraries of some sort for the foreseeable future. Maybe someday in the distant future they'll just be part of a 'legacy / ancient hash and cryptography' library that isn't standard, but they'll continue to be around. SO many things also already standardize on SHA1 (or even weaker hashes) as a (non-security) anti-collision hash for either sharding storage sets (host, folder, etc) or just as already well profiled hash key algos.

unscaled 1y ago
The difference that you've already noted here is that the X-Browser-Validation is new. It doesn't have to keep using SHA1, MD5 or CRC-32 to maintain compatibility with a protocol spec that predates the existence of newer algorithms.
- mjevans 1y ago
  The header is new, but what's it working with on the server side? Were there any other considerations for the selection of the value? Though in contrast to that, sometimes the criteria is just that a given number of bits aren't useful, so the output of a different hash is truncated to the desired size. Maybe part of the driving criteria os compatibility with E.G. the oldest supported Android version? Or maybe some version of Windows seen in legacy devices in poor countries? There might be good reasons beyond just 'header is new, everything must be state of the art'.
Retr0id 1y ago
CRC was never a cryptographic hash so there is no need to deprecate it. MD5 (and SHA1) is already absent or deprecated in many cryptography libraries, e.g. https://cryptography.io/en/latest/hazmat/primitives/cryptographic-hashes/#sha-1 https://cryptography.io/en/latest/hazmat/primitives/cryptogr... Every time someone uses MD5 or SHA1 for something that isn't legacy-backcompat, they further delay their deprecation/removal unnecessarily.

unscaled 1y ago

The difference that you've already noted here is that the X-Browser-Validation is new. It doesn't have to keep using SHA1, MD5 or CRC-32 to maintain compatibility with a protocol spec that predates the existence of newer algorithms.

mjevans 1y ago
The header is new, but what's it working with on the server side? Were there any other considerations for the selection of the value? Though in contrast to that, sometimes the criteria is just that a given number of bits aren't useful, so the output of a different hash is truncated to the desired size. Maybe part of the driving criteria os compatibility with E.G. the oldest supported Android version? Or maybe some version of Windows seen in legacy devices in poor countries? There might be good reasons beyond just 'header is new, everything must be state of the art'.

Retr0id 1y ago

CRC was never a cryptographic hash so there is no need to deprecate it. MD5 (and SHA1) is already absent or deprecated in many cryptography libraries, e.g. https://cryptography.io/en/latest/hazmat/primitives/cryptographic-hashes/#sha-1 https://cryptography.io/en/latest/hazmat/primitives/cryptogr... Every time someone uses MD5 or SHA1 for something that isn't legacy-backcompat, they further delay their deprecation/removal unnecessarily.