Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You are dangerously bad at cryptography

happybearsoftware.com

Post reply on HN
Print view View original

161–170 of 174 posts

Re: You are dangerously bad at cryptography

#161

Post by JacobiX »

betterunix wrote: post #15
e1ven wrote: post #7

So, sure. I'll admit that I'm bad at cryptography. You win! But the problem is, the world needs more, not less, crypto. We need to integrate crypto into more places, not run and hide and declare it too hard every time we come across it. Is it easy to screw up? Sure. So is manually allocating memory. But we use higher level languages to help protect us from ourselves. So too can we use higher-level libraries to help p…

What we really need is a cryptography language, to do for cryptography what SQL does for databases. I should be able to say, "Messages have this form, and they need to be encrypted end-to-end with authentication and without surreptitious forwarding," and have the right components assembled for me. Unfortunately, our understanding of cryptography is not well-developed enough to create such a system, and so we still fu…

Cryptol is a DSL that simplifies the specification of a cryptographic algorithm http://corp.galois.com/cryptol/

Re: You are dangerously bad at cryptography

#162

Post by AlexDanger »

agwa wrote: post #71
megrimlock wrote: post #18

His insight that crypto is hard because you don't get feedback when you mess up is good. It made me wonder what other domains are like that -- domains where correctness seems within reach, yet there are subtle aspects that are hard to state. Some that come to mind: * Concurrency. It's easy to introduce race conditions, livelocks, or deadlocks without even knowing. They are often difficult to observe or reproduce, and…

Along the lines of of your examples, I would add distributed systems. Still, cryptography is much, much worse than all these examples for a simple reason: with a sufficient amount of testing for functionality you can convince yourself that you've gotten things like concurrency correct, or at least correct enough that it won't be a problem most of the time. You can't do that with security - instead of testing for func…

Rumsfeld sums up the problem rather succinctly: http://www.brainyquote.com/quotes/quotes/d/donaldrums148142....

I think Netflix and its Chaos Monkey software is a very effective way of dealing with the 'unknown unknowns' of distributed systems.

Although obviously this approach doesnt work with cryptography systems. They call it Chaos Monkey (opposed to Genius Monkey) for a reason.

Re: You are dangerously bad at cryptography

#164

Post by tptacek »

jarrett wrote: post #157
tptacek wrote: post #102

Earlier quoted context omitted.

The world might need more working crypto. The world doesn't need more broken crypto. Broken crypto isn't just a step on the path to working crypto; it's an opportunity for people to get hurt. The bet I'm making right now is that if people get a little bit of crypto literacy, they'll stop being so excited about deploying crypto in their applications. Implementing a bunch of crypto attacks has the effect of making you…

After having this debate with you two or three times now, I'm starting to realize that we both want the same thing: Good libraries like Keyczar that just do the right thing by default. I would argue that there is a second side to the solution: Authors of more low-level crypto libraries (like OpenSSL) should very prominently warn users that said libraries are easy to misuse, and they should point users in the directio…

Absolutely. Strong agree!

Re: You are dangerously bad at cryptography

#165

Post by ygra »

rwg wrote: post #150
dsl wrote: post #80

Earlier quoted context omitted.

Just curious how far the Excel hacker(s) got... Also, have you made any hires from the contest yet?

The Excel thing started out as someone else's funny tweet and turned into me riding the bomb down while waving my cowboy hat, Slim Pickens style. This tweet started the ball rolling: https://twitter.com/sachinag/status/329701402546941953 The spreadsheets use no VBA or AppleScript or external code -- just Excel formulas and the functions Excel 2008 offers. I submitted the first four spreadsheets along with my "real" (…

Honestly, this is awesome. As someone who once wrote MT-19937 in Windows batch files (and started a bignum lib in those too) I love seeing tools applied to problems that seem totally wrong for it.

Re: You are dangerously bad at cryptography

#166

Post by ramblerman »

megrimlock wrote: post #18

His insight that crypto is hard because you don't get feedback when you mess up is good. It made me wonder what other domains are like that -- domains where correctness seems within reach, yet there are subtle aspects that are hard to state. Some that come to mind: * Concurrency. It's easy to introduce race conditions, livelocks, or deadlocks without even knowing. They are often difficult to observe or reproduce, and…

"Thinking Fast and Slow" tackles this issue.

Doctors who asses xray fotos for cancer usually get feedback ~6 months later. What's worse is they become more confident in their abilities as they age, and subsequently diverge from the standard checklists inexperienced doctors follow. This leads to even worse results from doctors with 10-15 years of experience.

The opposite case is surgeons who gain immediate feedback and generally become better with experience.

Re: You are dangerously bad at cryptography

#167

Post by sirclueless »

StavrosK wrote: post #55
jarrett wrote: post #53

This argument keeps coming up, and while its premises are valid, its conclusion never sits right with me, namely: "Don't use cryptography." That advice isn't practical for developers. There are plenty of systems we have to design where crypto is not optional. Examples: * Storing passwords. You can't store them in plaintext. * Signing requests (like in the OP's example). What are the alternatives? You can store some k…

There aren't any, learn how the libraries work and use them. I agree with your point, in that respect. Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed.

> Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed.

Not necessarily good enough. If you just sign a cookie that says userid=42, anyone who ever manages to read it can now authenticate as your user whenever they like. You just turned any session hijacking attack into an account hijacking attack.

Do what tptacek says, "just use random tokens to key a serverside session store" and don't write your own crypto.

Re: You are dangerously bad at cryptography

#168

Post by StavrosK »

sirclueless wrote: post #167
StavrosK wrote: post #55

Earlier quoted context omitted.

There aren't any, learn how the libraries work and use them. I agree with your point, in that respect. Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed.

> Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed. Not necessarily good enough. If you just sign a cookie that says userid=42, anyone who ever manages to read it can now authenticate as your user whenever they like. You just turned any session hijacking attack into an account hijacking attack. Do what tptacek says, "just use random tokens to key a serversid…

Yeah, both this and the original article are vulnerable to replay attacks. A token is much better, but there are times when you don't want to hit the DB, such as for non-critical data like displaying the user's name on the page. Signing a cookie is reasonable then.

Re: You are dangerously bad at cryptography

#169

Post by Nelson69 »

tptacek wrote: post #164
jarrett wrote: post #157

Earlier quoted context omitted.

After having this debate with you two or three times now, I'm starting to realize that we both want the same thing: Good libraries like Keyczar that just do the right thing by default. I would argue that there is a second side to the solution: Authors of more low-level crypto libraries (like OpenSSL) should very prominently warn users that said libraries are easy to misuse, and they should point users in the directio…

Absolutely. Strong agree!

How would this 'warning' look?

I think labeling 'expert' is almost like an attractant for many of the folks that shouldn't bother. Likewise, there are some good users of OpenSSL, the rumors of it being "bad" or "insecure" would be damaging.

I'm not saying it's a bad idea exactly, just if you discover the way to word the warning to prevent people who don't understand that they're newbies from doing newbie stuff with it, you'll be on to something. I say you put that label on C compilers too.

Re: You are dangerously bad at cryptography

#170

Post by TikiTDO »

scythe wrote: post #70
megrimlock wrote: post #18

His insight that crypto is hard because you don't get feedback when you mess up is good. It made me wonder what other domains are like that -- domains where correctness seems within reach, yet there are subtle aspects that are hard to state. Some that come to mind: * Concurrency. It's easy to introduce race conditions, livelocks, or deadlocks without even knowing. They are often difficult to observe or reproduce, and…

The biggest candidate: * Pure mathematics: Consider e.g. the difficulty in verifying the recent proofs of Fermat's Last Theorem (Wiles-Taylor-Frey theorem?), the Poincaré conjecture (Perelman-Hamilton-Thurston theorem?), and now the ABC conjecture (Mochizuki-Szpiro theorem?): there is essentially no indication of the correctness of a mathematical proof besides simply having a whole lot of smart people look at it and…

I feel a major problem with mathematical proofs is that the language of these proofs is so complex that in order to understand what it even says you have to be extremely smart, and willing to put in a huge amount of time in the first place.

A proof is in effect a "program" that describes the logical conditions of whatever it is trying to show. Invalid proofs are those with "bugs". Perhaps if the language of math was a bit clearer, it would not be such a difficult to understand field.

Post reply on HN