Live data from Hacker News

You are dangerously bad at cryptography

happybearsoftware.com

111–120 of 174 posts

Re: You are dangerously bad at cryptography

#111
post #99
post #69

Earlier quoted context omitted.

It does matter what hash function you use, though. MD5 and SHA-512 are both vulnerable to length extension, but there are other hash functions that are not, like SHA-512/256, SHA-3 or BLAKE. The documentation for both Keccak and BLAKE2 recommend prefixing a fixed-length key to the message to do MAC, pretty much like in the vulnerable example, but with a better hash function.

> other hash functions that are not, like SHA-512/256 I think you meant SHA-224/384. Both SHA-512 and -256 are vulnerable to length extension because their internal state is dumped and resumable. With SHA-224/384, you only get a truncated state (from 256- and 512-bits respectively), which you can't pick up and resume.

I do mean the hash function "SHA-512/256", as defined in FIPS 180-4 [1]. It is basically a version of SHA-512 that truncates the final result to 256 bits (Like SHA-384). It is not vulnerable to length extension, because unlike SHA-256, the final hash does not contain enough state to continue hashing.

I wouldn't consider SHA-224 immune to length extension since it only truncates 32 bits, which is low enough to brute force.

[1] http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIP...

Re: You are dangerously bad at cryptography

#112
post #110
post #67

Earlier quoted context omitted.

The world needs more broken crypto like a dissident strapped to a chair in a concrete cell in South America needs another car battery alligator clipped to their fingers. How about, if the world really needs more cryptography, the people who bring it to us take the time to become just a little bit literate in how crypto is actually attacked, instead of pretending like they understand it just because they were able to…

Honestly, one of the big problems is that people confuse crypto primitives with crypto schemes. Developers need schemes, not primitives. Some people, who know what they're doing, need the primitives, but they are by far and away the exception. AES is a crypto primitive, AES-CTR-CBCMAC (aka, AES-CCM, but spelled out to emphasize the complexity of it) is a scheme. And even then you have key distribution problems, which…

> AES is a crypto primitive, AES-CTR-CBCMAC (aka, AES-CCM, but spelled out to emphasize the complexity of it) is a scheme.

In this particular example, the 'schemes' you point out didn't fair that well in pretty much every single codebase I've seen them implemented in after I finished set two of the crypto challenges.

Re: You are dangerously bad at cryptography

#113

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…

Outside of computing: health and diet. Sure, you get some feedback, but you also can screw up things in some ridiculously slow-acting way. Pharma companies (are supposed to) monitor drug use for decades after introduction for the same reason. Construction. Just build that chunk out of two steel beams instead of one, and witness it work perfectly until someone decides to throw a party on that balcony. Or witness your…

> health and diet. Sure, you get some feedback, but you also can screw up things in some ridiculously slow-acting way.

This makes me think of the primal diet and coconut oil (saturated fat). The current arguments are that good saturated fats don't cause heart disease but (roughly) sugar does.

Re: You are dangerously bad at cryptography

#114
post #78

Earlier quoted context omitted.

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…

http://nacl.cr.yp.to/ NaCl is well implemented cryptographic functions designed to be easy to use and fast. As opposed to something like OpenSSL that gives you nine million options, NaCl just does what is best.

I do not think the problem is with how many options we are presented with, but rather with the difficulty of figuring out what primitives are actually needed to solve a particular problem, and how to compose those primitives. Do you need digital signatures? Do you need a hash function? Do you need to establish a common random string before the system can be used? It is very easy to assemble a system that appears secure (it's encrypted and signed!) but that does not actually provide any meaningful security (oh no, we actually needed non-malleable commitments!).

A high-level language could help quite a bit, because it would help programmers abstractly specify the needs of the system rather than getting lost in the details of which operations to choose. Maybe you really only need to sign and encrypt your messages. Maybe you need to sign, encrypt, then sign again. Maybe you do not need signatures at all, but you need to use a non-malleable cipher and a few rounds of communication (e.g. to make a deniable authentication protocol). The next generation of security problems will not be solved by slapping on encryption and digital signatures; we are going to need to pay increasing attention to higher-level issues.

Re: You are dangerously bad at cryptography

#115

I'm bad at crypto. I'm well aware that I'm bad at crypto. In fact, I would venture to guess that I know next to nothing about it. The problem isn't that I don't know what I don't know...the problem is that I don't know what (or whom) I can trust. And that is the bigger problem with crypto. It would be nice if we had resources that could tell us not only the best practices, but what their downfalls are and their relat…

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 also an upcoming security course (with no date planned yet) which will cover the application programming part of security and will be co-taught by him. [3]

[1] https://www.coursera.org/course/crypto [2] https://www.coursera.org/course/crypto2 [3] https://www.coursera.org/course/security

Re: You are dangerously bad at cryptography

#116

I'm bad at crypto. I'm well aware that I'm bad at crypto. In fact, I would venture to guess that I know next to nothing about it. The problem isn't that I don't know what I don't know...the problem is that I don't know what (or whom) I can trust. And that is the bigger problem with crypto. It would be nice if we had resources that could tell us not only the best practices, but what their downfalls are and their relat…

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 :-).

Re: You are dangerously bad at cryptography

#117
post #100

Earlier quoted context omitted.

I didn't think so, but I mentioned it because the Wikipedia article on Merkle-Damgård hashes ( http://en.wikipedia.org/wiki/Merkle–Damgård_construction ) talks about length extension attacks only in the context of hash collisions: "Length extension — once an attacker has one collision, he can find more very cheaply."

That's actually a relatively new finding, and a very cool attack (I assume we're talking about Joux multicollisions).

Multi-collisions is another thing. What Wikipedia means is that once you find m and m' s.t. H(m) = H(m'), then you've also found the collision H(m || X) = H(m' || X) for whatever X, i.e., unlimited collisions.

Re: You are dangerously bad at cryptography

#118

I completely agree with this and have just released a session-cache for python that completely ignores encryption and just stores uuid in a cookie, and relies on server side lookups for session work.

Make sure you are using HTTPS exclusively so you aren't vulnerable to Firesheep-style attacks.

Re: You are dangerously bad at cryptography

#119
post #111
post #99

Earlier quoted context omitted.

> other hash functions that are not, like SHA-512/256 I think you meant SHA-224/384. Both SHA-512 and -256 are vulnerable to length extension because their internal state is dumped and resumable. With SHA-224/384, you only get a truncated state (from 256- and 512-bits respectively), which you can't pick up and resume.

I do mean the hash function "SHA-512/256", as defined in FIPS 180-4 [1]. It is basically a version of SHA-512 that truncates the final result to 256 bits (Like SHA-384). It is not vulnerable to length extension, because unlike SHA-256, the final hash does not contain enough state to continue hashing. I wouldn't consider SHA-224 immune to length extension since it only truncates 32 bits, which is low enough to brute f…

Ahh, quite right. Sorry about that. And yeah, I agree on SHA-224; it's okay in certain circumstances (you're rarely going to be able to pull off 2^31 (average) requests), but it's almost definitely not the right choice.

Re: You are dangerously bad at cryptography

#120
post #110

Earlier quoted context omitted.

Honestly, one of the big problems is that people confuse crypto primitives with crypto schemes. Developers need schemes, not primitives. Some people, who know what they're doing, need the primitives, but they are by far and away the exception. AES is a crypto primitive, AES-CTR-CBCMAC (aka, AES-CCM, but spelled out to emphasize the complexity of it) is a scheme. And even then you have key distribution problems, which…

> AES is a crypto primitive, AES-CTR-CBCMAC (aka, AES-CCM, but spelled out to emphasize the complexity of it) is a scheme. In this particular example, the 'schemes' you point out didn't fair that well in pretty much every single codebase I've seen them implemented in after I finished set two of the crypto challenges.

Besides the usual IV hygiene, what's wrong with CCM? Or are you singling out the separate primitives AES-CTR and CBC-MAC?
Post reply on HN