Hacker News new | comments | show | ask | jobs | submit login

Great slides, some comments though.

I feel they focus too much on "use process X and algorithm Y".

The difficulty is not to choose the algorithm or the process, but to understand what kind of problem you're dealing with in the first place. In other words: threat modeling. There isn't a single slide about threat modeling, unless I'm mistaken.

If your error boils down to using SHA-1 instead of SHA-256, that's trivial to fix and you won't be exposed to real world attacks anytime soon.

Talking about side channel attacks on a hyperthreaded core is just going to confuse the audience. This is a very sophisticated attack that require the attacker to be able to run code on the target machine. If that's your only vulnerability, consider yourself happy.

The difficulty is not to choose the algorithm or the process, but to understand what kind of problem you're dealing with in the first place.

I agree, up to a point. But there's no way you can teach that sort of understanding in 1 hour. :-)

The purpose of this talk was to provide a checklist for developers of what they should and should not be doing.

But, for instance, you recommended CTR-mode AES-256, but didn't discuss:

* How to set the counters so that counter/IV can't collide and destroy your security

* What metadata your messages need to include to make them not replayable

* How to canonicalize your messages so that the process of packing, authenticating, encrypting, decrypting, and unpacking doesn't change the intent of a message.

I think that may be what the grandparent comment is getting at.

Excellent points. I would much rather have seen a talk on the hard issues such as these. Choosing an algorithm is simple if you already handle the above issues -- you've already heard a lot about AES by then. On the other hand, choosing AES-CTR as Colin recommends in the talk without handling the above issues is exactly where most developers are today.

Put another way: find me one crypto library or application implementing CTR mode that got all the above issues right but used a poor block cipher (not AES or 3DES).

That's where we disagree. I think checklists are not the way one should approach a problem.

You don't want developers to follow a checklist, you want them to use their intelligence.

One hour is enough to make developers realize they know nothing about cryptography. Once they reach that point, they will be on the right path (ie really learn about the topic or ask someone who knows).

The most common error isn't improperly used algorithms or techniques, it's improperly used cryptography.

Example: securing a file with AES-CTR and having the password hardcoded in the binary.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact