Ask HN: Current Crypto Best Practices • Hacker News Board

Re: Ask HN: Current Crypto Best Practices

#41

Post by cheeze » Wed, Apr 05, 2017, 5:39 PM UTC

tptacek wrote: post #30

deckar01 wrote: post #22

Earlier quoted context omitted.

Those challenges teach vulnerabilities in old, low level cryptographic primitives. As much as I enjoyed those challenges, they are not a good place to start for a developer trying to build a secure application.

Low level, yes. But, old? We cover AES, HMAC, stream ciphers, GCM, RSA, DH, SRP, and elliptic curves. The criteria for inclusion on the first 6 sets of challenges was "had to be something we took advantage of on the job at Matasano". It's not textbook stuff. Part of the point of the crypto challenges was to illustrate why people shouldn't work directly with low-level primitives, as a sort of antidote to the kind of a…

The first set of problems are all very simple, but you have to start somewhere.

I'm not sure that the cryptopals chalelnges are the best way to learn exactly how you should be implementing everything, but I've found the knowledge that I gained from doing the challenges very applicable in my daily job and definitely helped further my understanding of crypto in a way that reading a book just couldn't do.

Re: Ask HN: Current Crypto Best Practices

#42

Post by BoppreH » Wed, Apr 05, 2017, 5:42 PM UTC

mataug wrote: post #6

mistat wrote: post #2

The golden rule about storing a password is to not store a password... I can't wait till SQRL takes off

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.

Note the protocol has been improved since then, for example by adding revocation features.

Re: Ask HN: Current Crypto Best Practices

#43

Post by hueving » Wed, Apr 05, 2017, 5:49 PM UTC

jjperezaguinaga wrote: post #13

If you come from a computer science/math background, and want an intro to cryptography in general, I can strongly recommend the Coursera course from Stanford University by professor Dan Boneh - https://www.coursera.org/learn/crypto . To really understand the implementations of security libraries and tools, one should be at least familiar with the fundamentals and terminology of crypto. Otherwise you are blindly encry…

TBH this doesn't really give you anything about best practices though. It's a bunch of base theory without anything about timing analysis, etc. It's nice to know information but I don't think it makes you a better 'secure' programmer.

Re: Ask HN: Current Crypto Best Practices

#44

Post by astockwell » Wed, Apr 05, 2017, 5:56 PM UTC

pc86 wrote: post #37

tptacek wrote: post #28

Earlier 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]);

"Just use bcrypt" (or scrypt). Salting is baked in.

Re: Ask HN: Current Crypto Best Practices

#45

Post by tptacek » Wed, Apr 05, 2017, 5:56 PM UTC

schoen wrote: post #39

pc86 wrote: post #37

Earlier quoted context omitted.

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?

There's that, but more generally and importantly, application developers who take special measures to generate salts tend not to be using secure password hashing algorithms --- the libraries for things like bcrypt tend to handle this for you.

Re: Ask HN: Current Crypto Best Practices

#46

Post by rqebmm » Wed, Apr 05, 2017, 6:29 PM UTC

hueving wrote: post #43

jjperezaguinaga wrote: post #13

If you come from a computer science/math background, and want an intro to cryptography in general, I can strongly recommend the Coursera course from Stanford University by professor Dan Boneh - https://www.coursera.org/learn/crypto . To really understand the implementations of security libraries and tools, one should be at least familiar with the fundamentals and terminology of crypto. Otherwise you are blindly encry…

TBH this doesn't really give you anything about best practices though. It's a bunch of base theory without anything about timing analysis, etc. It's nice to know information but I don't think it makes you a better 'secure' programmer.

This was a complaint I heard from several people I work with who took the course.

Re: Ask HN: Current Crypto Best Practices

#47

Post by tptacek » Wed, Apr 05, 2017, 6:32 PM UTC

baby wrote: post #33

tptacek wrote: post #27

Earlier quoted context omitted.

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 prot…

There's more recommendations I could make; for instance, I talk about DH here but not about authenticated key exchanges. But at some point I'm no longer providing simple "right answers" and instead am writing a half-assed book on modern crypto that I'm not qualified to offer.

The more important bit here is that I was updating Colin Percival's recommendations, which didn't include a KDF or an AKE. :)

Re: Ask HN: Current Crypto Best Practices

#48

Post by tptacek » Wed, Apr 05, 2017, 6:35 PM UTC

tlrobinson wrote: post #12

mistat wrote: post #2

The golden rule about storing a password is to not store a password... I can't wait till SQRL takes off

Is that at all likely? Looks like SQRL was published in 2013... and this is the first I've heard of it.

No, it is not at all likely.

Re: Ask HN: Current Crypto Best Practices

#49

Post by schoen » Wed, Apr 05, 2017, 6:53 PM UTC

tptacek wrote: post #45

schoen wrote: post #39

Earlier quoted context omitted.

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?

There's that, but more generally and importantly, application developers who take special measures to generate salts tend not to be using secure password hashing algorithms --- the libraries for things like bcrypt tend to handle this for you.

Maybe akin to the "typing the letters A-E-S" in https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...?

Re: Ask HN: Current Crypto Best Practices

#50

Post by kyrre » Wed, Apr 05, 2017, 7:04 PM UTC

qjighap wrote: post #18

jjperezaguinaga wrote: post #13

If you come from a computer science/math background, and want an intro to cryptography in general, I can strongly recommend the Coursera course from Stanford University by professor Dan Boneh - https://www.coursera.org/learn/crypto . To really understand the implementations of security libraries and tools, one should be at least familiar with the fundamentals and terminology of crypto. Otherwise you are blindly encry…

I loved the first crypto course. I have been enrolled in the crypto2 class for several years now. I hope they finally offer the course, but I have low hopes.

any day now :^)