3 ms·

> Yes, MD5 is safe for this use Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according t

by lucb1e 5y ago

> Yes, MD5 is safe for this use Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according to Wikipedia) cryptographers recommended upgrading to SHA-1 in 1996 already? This project's first commit was well, well beyond the deprecation of MD5. It's a bit safer than but also not entirely unlike putting a Windows 7 on the internet just because there are no known exploits in an up-to-date 7 system currently.

dogma1138 5y ago
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.
  - thomashabets2 5y ago
    > when every library already ships more modern alternatives. Kernel needs support. This cannot be done in user space.
thomashabets2 5y ago
I'm not finding ways to to use MD5. TCP MD5 is supported on Linux and BSDs, and TCP-AO isn't. TCP MD5 has been used for decades to protect BGP, and exactly because it's still safe there's been no push to add TCP-AO. And it inherently requires kernel support, because it's part of TCP, not the application. I would have preferred TCP-AO (RFC5925), not TCP MD5 (RFC2385), but the former is not supported anywhere. See more at https://blog.habets.se/2019/11/TCP-MD5.html https://blog.habets.se/2019/11/TCP-MD5.html (I should have added this link in my comment, but I forgot I wrote a blog post on the topic)

by lucb1e 5y ago

dogma1138 5y ago

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.
- thomashabets2 5y ago
  > when every library already ships more modern alternatives. Kernel needs support. This cannot be done in user space.

thomashabets2 5y ago

I'm not finding ways to to use MD5. TCP MD5 is supported on Linux and BSDs, and TCP-AO isn't. TCP MD5 has been used for decades to protect BGP, and exactly because it's still safe there's been no push to add TCP-AO. And it inherently requires kernel support, because it's part of TCP, not the application. I would have preferred TCP-AO (RFC5925), not TCP MD5 (RFC2385), but the former is not supported anywhere. See more at https://blog.habets.se/2019/11/TCP-MD5.html https://blog.habets.se/2019/11/TCP-MD5.html (I should have added this link in my comment, but I forgot I wrote a blog post on the topic)