5 ms·

> This post should be called "Go 1.1 old broken crypto performance" ;-) If you're designing a new system, there's no sane reason to use MD5, SHA1, or RC4.* I t

> This post should be called "Go 1.1 old broken crypto performance" ;-) If you're designing a new system, there's no sane reason to use MD5, SHA1, or RC4.* I think your post is being downvoted because it seems to conflate cryptographic primitives with tools that you can use without modification to safely store a password.

dchest 14y ago
I ported scrypt to Go (https://code.google.com/p/go/source/browse/scrypt/scrypt.go?repo=crypto https://code.google.com/p/go/source/browse/scrypt/scrypt.go?...), so I know how to store passwords ;-) This has nothing to do with passwords. You can read about brokenness of RC4, MD5, or SHA1 in their respective Wikipedia articles.
- carbocation 14y ago
  First, thanks for your contribution. Second, I didn't downvote you. Third, the question was never whether you knew how to store a password. There are many reasons to need to be able to use even 'broken' primitives (esp. for compatibility with legacy apps or conversion), which makes them valuable (or at least necessary) for some apps. This is why I was guessing that your post was focused on passwords.
  - dchest 14y ago
    I understand. I also said that there's no reason to use them for _new_ systems. BTW, suggested reading: http://cr.yp.to/talks.html#2013.03.12 http://cr.yp.to/talks.html#2013.03.12 ("Failures of secret-key cryptography").
    - carbocation 14y ago
      Gulp. You did; I missed it! My apologies. And thanks for that link. Slide 313 is terrifying.
kzrdude 14y ago
No. MD5 and RC4 are legacy crypto. In use, but shouldn't be used for new software. (And none of them were ever viable for your usage example).
- mtourne 14y ago
  The crypto scheme used should depend on the importance of what you want to protect. For instance, I think using md5 for a secure token that will expire in a few minutes is reasonable.
  - dchest 14y ago
    What's reasonable about it? Why not use a non-broken hash algorithm?
    - mtourne 14y ago
      they're small and easy to compute. I'm not talking about signing my microsoft update cert with md5() here. By all means, I do encourage you to get a valid token for the next 20 minutes, find a collision attack and get a secure token that will work for another timestamp "sometime in the future" (without passing the captcha!) on the system I'm building..
      - dchest 14y ago
        Need small output? Truncate the output of SHA-256. What "easy to compute" means? Performance? Use BLAKE2. Code complexity? sha256() is only 3 letters more than md5() (you're probably not writing your own implementation). Asking other people (especially, not professional cryptographers) to try to break your system which knowingly uses insecure primitives is an awful way to evaluate system security.
tptacek 14y ago
A better reason to downvote that comment (which I didn't do) is that the performance of important cryptosystems is limited by MD5, SHA1, and RC4 performance. Cryptosystems like, say, TLS. Fun fact, by the way: there aren't any practical attacks on HMAC-MD5.

dchest 14y ago

I ported scrypt to Go (https://code.google.com/p/go/source/browse/scrypt/scrypt.go?repo=crypto https://code.google.com/p/go/source/browse/scrypt/scrypt.go?...), so I know how to store passwords ;-) This has nothing to do with passwords. You can read about brokenness of RC4, MD5, or SHA1 in their respective Wikipedia articles.

carbocation 14y ago
First, thanks for your contribution. Second, I didn't downvote you. Third, the question was never whether you knew how to store a password. There are many reasons to need to be able to use even 'broken' primitives (esp. for compatibility with legacy apps or conversion), which makes them valuable (or at least necessary) for some apps. This is why I was guessing that your post was focused on passwords.
- dchest 14y ago
  I understand. I also said that there's no reason to use them for _new_ systems. BTW, suggested reading: http://cr.yp.to/talks.html#2013.03.12 http://cr.yp.to/talks.html#2013.03.12 ("Failures of secret-key cryptography").
  - carbocation 14y ago
    Gulp. You did; I missed it! My apologies. And thanks for that link. Slide 313 is terrifying.

kzrdude 14y ago

No. MD5 and RC4 are legacy crypto. In use, but shouldn't be used for new software. (And none of them were ever viable for your usage example).

mtourne 14y ago
The crypto scheme used should depend on the importance of what you want to protect. For instance, I think using md5 for a secure token that will expire in a few minutes is reasonable.
- dchest 14y ago
  What's reasonable about it? Why not use a non-broken hash algorithm?
  - mtourne 14y ago
    they're small and easy to compute. I'm not talking about signing my microsoft update cert with md5() here. By all means, I do encourage you to get a valid token for the next 20 minutes, find a collision attack and get a secure token that will work for another timestamp "sometime in the future" (without passing the captcha!) on the system I'm building..
    - dchest 14y ago
      Need small output? Truncate the output of SHA-256. What "easy to compute" means? Performance? Use BLAKE2. Code complexity? sha256() is only 3 letters more than md5() (you're probably not writing your own implementation). Asking other people (especially, not professional cryptographers) to try to break your system which knowingly uses insecure primitives is an awful way to evaluate system security.

tptacek 14y ago

A better reason to downvote that comment (which I didn't do) is that the performance of important cryptosystems is limited by MD5, SHA1, and RC4 performance. Cryptosystems like, say, TLS. Fun fact, by the way: there aren't any practical attacks on HMAC-MD5.