Live data from Hacker News

You are dangerously bad at cryptography

happybearsoftware.com

121–130 of 174 posts

Re: You are dangerously bad at cryptography

#121
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 the world needs is more managers that hire engineers instead of lawyers when someone points out to them that their crypto is broken.

Re: You are dangerously bad at cryptography

#122
post #70

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…

If I understood your proposed system correctly, the following seems to be a deal-breaking weakness: Given a number of polynomials representing encrypted messages, (x-z) is a common factor of all of them. The GCD of a set of polynomials can very efficiently be computed. Thus, an attacker observing different messages encrypted with the same key over time gets a better and better idea of what the key is (how quickly depends on the messages: two plaintext messages that happen to give coprime polynomials M_1(x) and M_2(x) would be enough to get the key).

Re: You are dangerously bad at cryptography

#123
post #77

Note: we're still running these challenges: http://www.matasano.com/articles/crypto-challenges/ The current standings are: * level 0 (4362 players), * level 1 (335 players), * level 2 (123 players), * level 3 (40 players), * level 4 (21 players), * level 5 (23 players), * level 6 (32 players) We're still donating $20 to PIH or Watsi for everyone who finishes all 6 sets. The top languages finishers are using are (in o…

Is that the number of people working on that level, or the number of people who've finished that level? My guess was the former, but if so, how many people have finished level 6? And if it's the latter, how many people have started level 0 but not finished?

I'm also curious what the stats look like for how long people are taking to complete each level.

Re: You are dangerously bad at cryptography

#124
post #14

Then there is the question; Is your app likely to ever be attacked at all? By someone good? With a lot of time? If not, perhaps hiring a cryptography expert is overkill, and you are better off just using whatever your framework offers, or integrate some library yourself. You are not a bank.

This is a very dangerous question. Thinking like this leads to huge security vulnerabilities in important systems. A better question is "What is the worst thing that could possibly happen if this system were successfully attacked?" If the answer is anything bad, it is probably best to assume someone will try to attack it.

As for the second part of the question, are we talking about the same internet? Because the one I'm on appears to be full of technically savvy people with loads of free time.

Re: You are dangerously bad at cryptography

#125
post #86

Few thoughts - why MD5 in the example at all? I thought that SHA-2 was the go to for hash functions nowadays. And a question on the timing attack - how real it is? Because in the response time you have a lot of random variables which with the current fast servers will take more time than the calculation itself. You receive request - how fast it will go trough the loadbalancer is random, then you must read the shared…

SHA2 has the same problems.

To be more accurate, SHA-224, SHA-512/384, and SHA-512/256 don't suffer from length extension attacks. The rest of the SHA2 family (256 and 512) do. Of course, SHA-256 and SHA-512 are more popular than their truncated variants...

Re: You are dangerously bad at cryptography

#126

Earlier quoted context omitted.

btw: isn't the scheme you posted vulnerable to replay attacks too? Much easier than the timing attack. edited to add: don't mean this as a nitpick. I've seen that very mistake made by two S&P 500 companies that had 'homebrew' SSO we had to integrate with.

> btw: isn't the scheme you posted vulnerable to replay attacks too? Much easier than the timing attack. Yep, probably. In fact now that I look at it definitely, I should have gone with that instead! I forget who said this but basically any feature that exists in TLS that doesn't exist in your hand-rolled authentication scheme is a vulnerability.

Does peer review count as a feature?

Re: You are dangerously bad at cryptography

#127
post #11

Earlier quoted context omitted.

Is there a repository or central location of the established and well tested solutions for developers to use? Where does one start?

Some ideas, depending on what you need (I can't say how good these are): http://www.keyczar.org http://nacl.cr.yp.to https://github.com/jedisct1/libsodium http://www.gnupg.org

Thanks. These are straight crypto frameworks which are a good start.

Re: You are dangerously bad at cryptography

#128

Earlier quoted context omitted.

Is there a repository or central location of the established and well tested solutions for developers to use? Where does one start?

One of the problems with cryptography is that "solutions" are not as generally applicable as one might want. There are a lot of assumptions that are made, and violating those assumptions is usually a disaster. For example, when it comes to encryption, it is typically assumed that all messages are the same length. If your application does not make this guarantee, encryption may not provide you with any security. You c…

That makes sense in terms of no standard libraries. But how about design patterns for common scenarios, eg. securing REST apis, User authentication/Login/Signup, Payment information handling etc, all in one place.

Does it become less secure if everyone follows standard design patterns?

Re: You are dangerously bad at cryptography

#129

Earlier quoted context omitted.

Try Dan Boneh's crypto course on coursera [1]. It covers quite a lot of ground, both practical and theoretical, and includes programming exercises similar to the matasano puzzles. Without a doubt it's one of the best courses of the dozen MOOCs I've taken. There's also a followup course [2] (I haven't taken it yet personally, but I believe the currently scheduled run will be the first). Interestingly enough, there's a…

Glad that you like Dan Boneh's crypto class. I made the programming exercises :-).

They were very well done, and I loved the course overall, so congrats. I like how Dan knows how to preemptively answer every question I had.

Re: You are dangerously bad at cryptography

#130
post #77

Note: we're still running these challenges: http://www.matasano.com/articles/crypto-challenges/ The current standings are: * level 0 (4362 players), * level 1 (335 players), * level 2 (123 players), * level 3 (40 players), * level 4 (21 players), * level 5 (23 players), * level 6 (32 players) We're still donating $20 to PIH or Watsi for everyone who finishes all 6 sets. The top languages finishers are using are (in o…

Hmm, nobody has tried using Brainfuck yet...
Post reply on HN