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

81–90 of 174 posts

Re: You are dangerously bad at cryptography

#81

Post by tptacek »

dsl wrote: post #78
betterunix wrote: post #15

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.

NaCl and Keyczar are both good options. We also tend to recommend that people simply use PGP for data at rest, and TLS for data in motion. Neither are perfect, but both are subjected to intense scrutiny by researchers.

Re: You are dangerously bad at cryptography

#82

Post by [deleted] »

jdbernard wrote: post #52
wzdd wrote: post #41

I'm just curious: the obvious response to the first problem (message extension attack) is to include the message length in the message. If this wouldn't work, could an expert please tell me why? Edit: To be specific, I was thinking of a Pascal-style length-at-start arrangement. It's clear that if you put the length at the end you may be vulnerable to exactly the same attack!

The attacker just needs to include the updated length, which he can likely calculate since the shared secret is probably the same length for all accounts-even if it is not he only needs it for this request--and he knows the length of the parameters and their values. It would take some guesswork and trial and error to nail it down, and the attacker would have to guess that the length was included in the first place. A…

[deleted]

Re: You are dangerously bad at cryptography

#83

Post by tptacek »

dsl wrote: post #80
tptacek wrote: 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…

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

All I'm going to say here is that you would not freaking believe how far the Excel guy has gotten. No VBA, either; it's pure spreadsheet cells.

Yes, we've hired from the challenges (I don't like thinking of it as a contest; I think of it more as an extremely engaging blog post).

Re: You are dangerously bad at cryptography

#84

Post by bashinator »

jiggy2011 wrote: post #44

I would break the levels of crypto knowhow down thusly: 1) End user level: You want to buy things online, you should know to check for the padlock icon. 2) Deployment level: You run an online shop using an off the shelf eCommerce system. You should buy an SSL cert and know how to install it on your web server of choice. You should also know the difference between a public and private key (and hence why you should nev…

Funny story - quite a few years back I was a sysadmin for a company that was compiling their own PHP with a couple of patches. When I asked about it, my co-worker said it was to suppress some warnings that were spamming the logs whenever someone created an account.

Yes, those warnings were telling us that we weren't using an initialization vector (IV, aka a salt) when hashing the passwords. Facepalm. I suppose that demonstrates the dangers of developers thinking they should be diving into level 3), and also the benefit of (my) being aware of more of the theory than we should have been implementing ourselves.

Yes, I filed a bug to start using hashes, re-hash all our users' passwords, and get rid of the patch. This was also well before those massive GPU cracking systems, so everything turned out fine.

Re: You are dangerously bad at cryptography

#85

Post by LaGrange »

jiggy2011 wrote: post #48
LaGrange wrote: post #40

Earlier quoted context omitted.

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…

Economics is also an excellent example. Nobody knows how to do it properly, even establishing direct cause and effect is basically impossible so we just iterate through progressively less broken solutions.

"progressively less broken solutions"

Now that's a controversial statement if I've ever seen one.

Re: You are dangerously bad at cryptography

#86

Post by tptacek »

venomsnake wrote: post #49

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.

Re: You are dangerously bad at cryptography

#87

Post by tptacek »

wzdd wrote: post #41

I'm just curious: the obvious response to the first problem (message extension attack) is to include the message length in the message. If this wouldn't work, could an expert please tell me why? Edit: To be specific, I was thinking of a Pascal-style length-at-start arrangement. It's clear that if you put the length at the end you may be vulnerable to exactly the same attack!

MD4, MD5, SHA1, and all the SHA2 variants use a structure called Merkle Damgard, which does include the message size. Most are vulnerable to length extension attacks. SHA3 (Ketchup) is not vulnerable to length extension attacks, because resistance to length extension was a design criteria for the SHA3 contest.

Edit: Doh, SHA2-224 and SHA2-384 are truncated and aren't vulnerable

Re: You are dangerously bad at cryptography

#88

Post by [deleted] »

bazzargh wrote: post #50
wzdd wrote: post #41

I'm just curious: the obvious response to the first problem (message extension attack) is to include the message length in the message. If this wouldn't work, could an expert please tell me why? Edit: To be specific, I was thinking of a Pascal-style length-at-start arrangement. It's clear that if you put the length at the end you may be vulnerable to exactly the same attack!

I'm not an expert, but I can see a problem with schemes along those lines. MD5 (and similar) extension attacks also take advantage of the padding added after the thing you want to hash; so eg Secret: secret Message: foo&bar Let's include the length and hash 'secretfoo&bar13' What you actually hash is 'secretfoo&bar130x80...padding...0x20'. What the attacker sees as the 'known hash' includes this padding. When you per…

[deleted]

Re: You are dangerously bad at cryptography

#89

Post by tptacek »

[deleted] wrote: post #82
jdbernard wrote: post #52

Earlier quoted context omitted.

The attacker just needs to include the updated length, which he can likely calculate since the shared secret is probably the same length for all accounts-even if it is not he only needs it for this request--and he knows the length of the parameters and their values. It would take some guesswork and trial and error to nail it down, and the attacker would have to guess that the length was included in the first place. A…

[deleted]

The attacker doesn't "update" the length. The attacker appends data to the message, which has the effect of turning the previously stamped message length into just another bunch of bits in the middle of the message, and then includes their own message length at the end. The final message must accurately represent the length of the original message including the shared secret, so there's trial and error involved, but it's just trials of "possible length of the shared secret".

Again, this works on MD4, MD5, SHA1, and all the SHA2's.

You shouldn't have deleted your comment. You're not expected to know this stuff. Very few people, relative to the whole industry, or even relative to the number of programmers who end up trying to build crypto, actually do know how a length extension attack works.

Re: You are dangerously bad at cryptography

#90

Post by jiggy2011 »

bashinator wrote: post #84
jiggy2011 wrote: post #44

I would break the levels of crypto knowhow down thusly: 1) End user level: You want to buy things online, you should know to check for the padlock icon. 2) Deployment level: You run an online shop using an off the shelf eCommerce system. You should buy an SSL cert and know how to install it on your web server of choice. You should also know the difference between a public and private key (and hence why you should nev…

Funny story - quite a few years back I was a sysadmin for a company that was compiling their own PHP with a couple of patches. When I asked about it, my co-worker said it was to suppress some warnings that were spamming the logs whenever someone created an account. Yes, those warnings were telling us that we weren't using an initialization vector (IV, aka a salt) when hashing the passwords. Facepalm. I suppose that d…

Once you are choosing salts that is almost level 4 knowledge. This is one of the problems with "raw" PHP development, there's no way to say "this is a password field, make it secure" only "hash this with algorithm X".

To be fair though , I believe recent releases have addressed this and frameworks like symphony give you a default user class to inherit from that does things sensibly. It also sticks a seed for the salt directly in the config file (where devs will see it) and says "make sure you set this randomly and keep it secret".

Post reply on HN