May be on a tangent and a shameless plug, but I just posted https://news.ycombinator.com/item?id=14042150 this morning.
Underlock is a small Ruby library that helps with Encrypting/Decrypting of files and other data.
Ask HN: Current Crypto Best Practices
31–40 of 71 posts
Re: Ask HN: Current Crypto Best Practices
#32I made this a while ago: http://howtostoreapassword.com. Still relevant I think. :)
I should probably update it to use one of the more modern algos, but the availability of good bcrypt libraries makes it solid advice still.
Re: Ask HN: Current Crypto Best Practices
#33Earlier quoted context omitted.
The original from tqbf: https://gist.github.com/tqbf/be58d2d39690c3b366ad It's definitely completely relevant today. Find out what you want to do and check that list. A few things I would update: * password handling -> Scrypt or Argon2 * Client-server application security -> TLS or Noise * Hashing/HMAC algorithm -> Blake2/prefix-MAC or KangarooTwelve/KMAC * Fingerprint -> TupleHash * key derivation -> HKDF or SHAKE o…
Why would you make those updates? I like Noise more than I like TLS, but if you look at the recommendation where it says "use TLS" and ask yourself "how would I as a Python application programmer actually use Noise", I don't see the applicability. Similarly: I like Blake2 more than I like SHA-2, but SHA-2 is universally available and strong (in the context of those recommendations, I also didn't want to explain the d…
> "how would I as a Python application programmer actually use Noise", I don't see the applicability.
Depending on who that list is for I could agree with you.
This recommendation comes from the fact that I'm seeing a LOT of companies who want to have their own secure protocol on top of whatever protocol and end up re-inventing the wheel to avoid the bloatness of TLS. Noise is a good advice for these custom made protocols. I wouldn't replace TLS in the advice, but add a note: "if you really do not want TLS, there is Noise, but that's it!
> Similarly: I like Blake2 more than I like SHA-2, but SHA-2 is universally available and strong
Agree, but if we want to move to nicer/stronger algorithms we must start recommending them at some point. I want to see a push for Argon2/Blake2/SHA-3 in general.
> part of the point of recommending SHA-2 was to recommend against Keccak
Ah well, Keccak is so interesting (not only for hashing) that I would be sad if it end up not being used in the next decades to come. If you're feeling this way because of the efficiency: that's why I recommended KangarooTwelve, if you're feeling this way because of the crappy spec: alright you win.
> I don't think I actually made a key derivation or fingerprint recommendation. I like HKDF!
What are you waiting for! :)
Re: Ask HN: Current Crypto Best Practices
#34I'm currently building a community website for these kind of questions (storing password, constant-time token comparison), the design is pretty raw for the moment: https://sqreen.github.io/DevelopersSecurityBestPractices/saf...
The code examples are in Python, but I plan to add pages in other languages.
Re: Ask HN: Current Crypto Best Practices
#35May be on a tangent and a shameless plug, but I just posted https://news.ycombinator.com/item?id=14042150 this morning. Underlock is a small Ruby library that helps with Encrypting/Decrypting of files and other data.
Unfortunately, I think libsodium remains a categorically better answer for this problem.
Re: Ask HN: Current Crypto Best Practices
#36Dan Boneh's Coursera course is ideal for any beginner. Cryptography Engineering by Schneier et al. is good, as is Ross Anderson's Security Engineering, but both are fairly dated.
The OWASP guidance is OK for a quick access to best practices, but insufficient for rigorous learning.
Cryptography takes time to digest the fundamentals and recognise how new concepts are both beneficial and, vitally, disadvantageous; sadly, there is no cheat sheet or quick fix.
Source: computer security PhD student.
Re: Ask HN: Current Crypto Best Practices
#37OWASP has some nice guidelines on a lot of topics, including storing passwords. Start at https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
OWASP's cryptography advice is almost invariably awful, and that password storage thing is among the worst of it. It's better now than it was when it recommended against password hashes (note that it still recommends "cryptographically strong salts") but remains factually incorrect in more than one place, including the notion that PBKDF2 is better than bcrypt (the opposite is true).
Agree that OWASP's crypto advice is generally garbage, but is there a better salt policy than what they have?
[protected form] = [salt] + protect([protection func], [salt] + [credential]);Re: Ask HN: Current Crypto Best Practices
#38Earlier quoted context omitted.
It won't. See http://security.blogoverflow.com/2013/10/debunking-sqrl/ for a myriad of reasons. I've also come to realize that one should take everything that SG says with a large table spoon of salt.
Why is that? I've heard lots of people saying that, but not had any concrete reasons why. As far as I know, he's generally correct about the things he discusses. And pretty good at making technical discussions interesting.
Re: Ask HN: Current Crypto Best Practices
#39Earlier quoted context omitted.
OWASP's cryptography advice is almost invariably awful, and that password storage thing is among the worst of it. It's better now than it was when it recommended against password hashes (note that it still recommends "cryptographically strong salts") but remains factually incorrect in more than one place, including the notion that PBKDF2 is better than bcrypt (the opposite is true).
Agree that OWASP's crypto advice is generally garbage, but is there a better salt policy than what they have? [protected form] = [salt] + protect([protection func], [salt] + [credential]);
I assume tptacek's objection is that salts need to be unique (at most, unpredictable enough to discourage precomputation), and don't need to be produced by a CSPRNG.
Edit: or maybe something else from the editorial history of the document?
Re: Ask HN: Current Crypto Best Practices
#40[deleted]