4 ms·

Cryptographers usually recommend switching to function X for usecase Y. Despite SHA1 today and MD5 for even longer being “insecure” for some use cases there ar

Cryptographers usually recommend switching to function X for usecase Y. Despite SHA1 today and MD5 for even longer being “insecure” for some use cases there are plenty of usecases for which they are still secure and will remain so. The reason for a wide deprecation is that most people can’t evaluate a hash function or an encryption algorithm in context well so it’s easier to say simply don’t use X. RSA is also crap for many things and it’s slowly but surely being deprecated but it doesn’t mean it’s completely broken for every usecase. Just to be clear I’m not stating that MD5 is necessarily safe for the usecase the GP states it is.

lucb1e 5y ago
Okay but that doesn't explain why it makes sense to still pick an algorithm that more and more holes are being found in when every library already ships more modern alternatives. It would be better to remove the old MD5 code so we can't accidentally have someone use it for use-cases for which it isn't secure, but if people are pedantic about "but for this case I can still use it! Let me just do that!" that will just never happen and we're stuck with MD5 indefinitely.
- dogma1138 5y ago
  I’m not going to evaluate if MD5 is safe for “tcpauth” even if I was competent enough to do so. If confidentiality isn’t a factor (since any hush function that is fast m enough to brute force isn’t going to be particularly secure) and if integrity cannot be compromised through collisions then the hash function is safe for this usecase. Why use MD5? It’s relatively easy to implement securely m, there are a lot of safe implementations and it’s fast. This is why CRC32 is still used today also.
  - mlyle 5y ago
    CRC32 is used for its error detection properties which exceed those of a cryptographic hash of the same length (and, to boot, it's cheaper, too). There's no reason to choose MD5 over SHA-1. It's less secure and slower and there's plenty of free implementations of SHA-1. Ideally you'd use SHA-256, because of (smaller) security concerns with SHA-1, but it is a small touch slower than MD5.
    - boring_twenties 5y ago
      MD5 is quite a bit faster on my machine. % for i in md5 sha1 sha256 sha512; do echo -n "$i: "; time ${i}sum test.bin > /dev/null ; done md5: ${i}sum test.bin > /dev/null 1.37s user 0.13s system 99% cpu 1.501 total sha1: ${i}sum test.bin > /dev/null 1.84s user 0.12s system 99% cpu 1.952 total sha256: ${i}sum test.bin > /dev/null 4.43s user 0.16s system 99% cpu 4.593 total sha512: ${i}sum test.bin > /dev/null 2.69s user 0.12s system 99% cpu 2.810 total Surprisingly, SHA256 is much slower than SHA512 here.
      - mlyle 5y ago
        OK, I measured a dozen machines, and I found a very mixed picture using 'openssl speed'. - Lots of modern x86 machines with SHA-NI that were typically 50-300% faster than MD5 - Older Intel machines, where SHA1 was generally slightly faster, with one or two exceptions where the reverse was true. - ARM machines with good SIMD/NEON where the NEON implementation of SHA1 was 30-40% faster than MD5. - Embedded ARM machines with bad SIMD/NEON where it was pretty much a tie. - A few ARM machines-- most notably Broadcom chipsets in the Raspberry Pi, where MD5 wins big a large margin. - Embedded MIPS 24k, where MD5 won by 33%. Then I found http://bench.cr.yp.to/results-hash.html http://bench.cr.yp.to/results-hash.html , which bears out what I'd measured. In any case, I don't think "speed" is any reason to select MD5, unless maybe if you're on MIPS 24k.
        thomashabets2 5y ago
        It's not about speed. It's about kernel support. And RFC2385 has kernel support and TCP-AO does not. See other comments.
      - NovemberWhiskey 5y ago
        >Surprisingly, SHA256 is much slower than SHA512 here. SHA512 is expected to be faster than SHA256 on modern 64 bit architectures due to fewer rounds per byte.
        boring_twenties 5y ago
  - thomashabets2 5y ago
    No, "why use MD5" is because MD5 is the only one supported by kernels. And it has to be supported by kernels in order to allow any realistic use of a BGP daemon. I thought this should be clear from the fact that it protects against RST packets. Nothing on an application layer can do that. I wish I could edit that comment because while I expected people to go "oh, I didn't know TCP had that!", multiple commenters seem to have not read past "MD5" and assumed that this is pure application-level.
- thomashabets2 5y ago
  > when every library already ships more modern alternatives. Kernel needs support. This cannot be done in user space.

lucb1e 5y ago

Okay but that doesn't explain why it makes sense to still pick an algorithm that more and more holes are being found in when every library already ships more modern alternatives. It would be better to remove the old MD5 code so we can't accidentally have someone use it for use-cases for which it isn't secure, but if people are pedantic about "but for this case I can still use it! Let me just do that!" that will just never happen and we're stuck with MD5 indefinitely.

dogma1138 5y ago
I’m not going to evaluate if MD5 is safe for “tcpauth” even if I was competent enough to do so. If confidentiality isn’t a factor (since any hush function that is fast m enough to brute force isn’t going to be particularly secure) and if integrity cannot be compromised through collisions then the hash function is safe for this usecase. Why use MD5? It’s relatively easy to implement securely m, there are a lot of safe implementations and it’s fast. This is why CRC32 is still used today also.
- mlyle 5y ago
  CRC32 is used for its error detection properties which exceed those of a cryptographic hash of the same length (and, to boot, it's cheaper, too). There's no reason to choose MD5 over SHA-1. It's less secure and slower and there's plenty of free implementations of SHA-1. Ideally you'd use SHA-256, because of (smaller) security concerns with SHA-1, but it is a small touch slower than MD5.
  - boring_twenties 5y ago
    MD5 is quite a bit faster on my machine. % for i in md5 sha1 sha256 sha512; do echo -n "$i: "; time ${i}sum test.bin > /dev/null ; done md5: ${i}sum test.bin > /dev/null 1.37s user 0.13s system 99% cpu 1.501 total sha1: ${i}sum test.bin > /dev/null 1.84s user 0.12s system 99% cpu 1.952 total sha256: ${i}sum test.bin > /dev/null 4.43s user 0.16s system 99% cpu 4.593 total sha512: ${i}sum test.bin > /dev/null 2.69s user 0.12s system 99% cpu 2.810 total Surprisingly, SHA256 is much slower than SHA512 here.
    - mlyle 5y ago
      OK, I measured a dozen machines, and I found a very mixed picture using 'openssl speed'. - Lots of modern x86 machines with SHA-NI that were typically 50-300% faster than MD5 - Older Intel machines, where SHA1 was generally slightly faster, with one or two exceptions where the reverse was true. - ARM machines with good SIMD/NEON where the NEON implementation of SHA1 was 30-40% faster than MD5. - Embedded ARM machines with bad SIMD/NEON where it was pretty much a tie. - A few ARM machines-- most notably Broadcom chipsets in the Raspberry Pi, where MD5 wins big a large margin. - Embedded MIPS 24k, where MD5 won by 33%. Then I found http://bench.cr.yp.to/results-hash.html http://bench.cr.yp.to/results-hash.html , which bears out what I'd measured. In any case, I don't think "speed" is any reason to select MD5, unless maybe if you're on MIPS 24k.
      - thomashabets2 5y ago
        It's not about speed. It's about kernel support. And RFC2385 has kernel support and TCP-AO does not. See other comments.
    - NovemberWhiskey 5y ago
      >Surprisingly, SHA256 is much slower than SHA512 here. SHA512 is expected to be faster than SHA256 on modern 64 bit architectures due to fewer rounds per byte.
      - boring_twenties 5y ago
- thomashabets2 5y ago
  No, "why use MD5" is because MD5 is the only one supported by kernels. And it has to be supported by kernels in order to allow any realistic use of a BGP daemon. I thought this should be clear from the fact that it protects against RST packets. Nothing on an application layer can do that. I wish I could edit that comment because while I expected people to go "oh, I didn't know TCP had that!", multiple commenters seem to have not read past "MD5" and assumed that this is pure application-level.
thomashabets2 5y ago
> when every library already ships more modern alternatives. Kernel needs support. This cannot be done in user space.