3 ms·

I found this, which says that the SHA algorithm allows for truncation: https://csrc.nist.gov/publications/detail/sp/800-107/rev-1/final https://csrc.nist.gov/pu

I found this, which says that the SHA algorithm allows for truncation: https://csrc.nist.gov/publications/detail/sp/800-107/rev-1/final https://csrc.nist.gov/publications/detail/sp/800-107/rev-1/f...

Dylan16807 4y ago
Not just allows, it becomes more secure when you truncate.
- neon_electro 4y ago
  Care to elaborate? This is not something I would've intuited.
  - bawolff 4y ago
    Presumably they are referring to length extension attacks. You can't pull them off if you truncate. https://en.m.wikipedia.org/wiki/Length_extension_attack https://en.m.wikipedia.org/wiki/Length_extension_attack Generally though length ext attacks have a solution - HMAC, which is much more secure than truncate. The more you truncate, the more vulnerable you are to birthday attacks (practically speaking you would have to truncate quite a lot)
    - kzrdude 4y ago
      The canonical solution is SHA-512/256 i.e 512 truncated to 256 bits where "nothing is lost" compared to SHA-256 and something is gained. It might even be faster (due to the 64-bit word formulation of SHA-512) in some implementations.
      - NovemberWhiskey 4y ago
        Generally is faster (fewer rounds per byte). If you have 256 bits available for your hash and you're on a 64 bit architecture, I've yet to see a case where you're not better off for performance and security choosing SHA-512/256 over SHA-256, assuming you have the choice.
        ztorkelson 4y ago
        Is this still true? I understood SHA256 to be faster than SHA512 due to hardware acceleration on current CPUs; dedicated instructions exist for the former but not the latter.
        NovemberWhiskey 4y ago
        It seems like it's not true on a MacBook with the Apple M1 processor; SHA-256 is now significantly faster. It still seems to be true on a couple of Intel machines I have access to.
        bawolff 4y ago
        Googling i noticed there seems to be a bug in openssl where it does not use optimized sha-512 on m1 (but does for sha256) - https://github.com/openssl/openssl/issues/14897 https://github.com/openssl/openssl/issues/14897 so that might be the explanation. Also i think the length of the input matters when comparing sha256 vs sha512.
- tatersolid 4y ago
  Truncated SHA-* hashes are more secure against length-extension attacks, but are very much less secure against collision and pre-image attacks (which are more important in most scenarios).
  - Dylan16807 4y ago
    But also, 256 is overkill for collisions and pre-image. There's a point where truncating starts to make it weaker, but when you first start chopping off bytes the benefits outweigh the drawbacks.

I found this, which says that the SHA algorithm allows for truncation: https://csrc.nist.gov/publications/detail/sp/800-107/rev-1/final https://csrc.nist.gov/publications/detail/sp/800-107/rev-1/f...

Dylan16807 4y ago

Not just allows, it becomes more secure when you truncate.

neon_electro 4y ago
Care to elaborate? This is not something I would've intuited.
- bawolff 4y ago
  Presumably they are referring to length extension attacks. You can't pull them off if you truncate. https://en.m.wikipedia.org/wiki/Length_extension_attack https://en.m.wikipedia.org/wiki/Length_extension_attack Generally though length ext attacks have a solution - HMAC, which is much more secure than truncate. The more you truncate, the more vulnerable you are to birthday attacks (practically speaking you would have to truncate quite a lot)
  - kzrdude 4y ago
    The canonical solution is SHA-512/256 i.e 512 truncated to 256 bits where "nothing is lost" compared to SHA-256 and something is gained. It might even be faster (due to the 64-bit word formulation of SHA-512) in some implementations.
    - NovemberWhiskey 4y ago
      Generally is faster (fewer rounds per byte). If you have 256 bits available for your hash and you're on a 64 bit architecture, I've yet to see a case where you're not better off for performance and security choosing SHA-512/256 over SHA-256, assuming you have the choice.
      - ztorkelson 4y ago
        Is this still true? I understood SHA256 to be faster than SHA512 due to hardware acceleration on current CPUs; dedicated instructions exist for the former but not the latter.
        NovemberWhiskey 4y ago
        It seems like it's not true on a MacBook with the Apple M1 processor; SHA-256 is now significantly faster. It still seems to be true on a couple of Intel machines I have access to.
        bawolff 4y ago
        Googling i noticed there seems to be a bug in openssl where it does not use optimized sha-512 on m1 (but does for sha256) - https://github.com/openssl/openssl/issues/14897 https://github.com/openssl/openssl/issues/14897 so that might be the explanation. Also i think the length of the input matters when comparing sha256 vs sha512.
tatersolid 4y ago
Truncated SHA-* hashes are more secure against length-extension attacks, but are very much less secure against collision and pre-image attacks (which are more important in most scenarios).
- Dylan16807 4y ago
  But also, 256 is overkill for collisions and pre-image. There's a point where truncating starts to make it weaker, but when you first start chopping off bytes the benefits outweigh the drawbacks.