Why Isn't My Encryption.. Encrypting?

It's as true in life as it is in client-server programming: the only secret that can't be compromised is the one you never revealed.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/05/why-isnt-my-encryption-encrypting.html

Off-topic.

An attacker could simply submit the form as many times as she likes

Why she? I fail to understand this bit of English usage.

Can someone explain?

Why she? I fail to understand this bit of English usage.

Thank you AndrÈ for raising this question! I think he is referring to Eve, the evil eavesdropper. But it’s so biblical, patriarchal, typical and annoying.

http://xkcd.com/177/
http://en.wikipedia.org/wiki/Alice_and_Bob

Salt??? This isn’t a hash–this is a cipher.

Assuming you’re changing the value of this salt each time, I think the phrase you’re looking for in this context is an initialization vector: http://en.wikipedia.org/wiki/Initialization_vector

My favorite is when people want to encrypt things by XORing against a fixed string: perl -le ‘print for map ord, split //, secret ^ foobar’ looks pretty random, but if the plaintext has a bunch of spaces (as they often do): perl -le 'print secret ^ ', oops, there is they key (uppercased, but still).

So, you mean it’s just in order not to look sexist?

In the name of not being sexist writers are committing errors to the English language. He is either masculine or neuter. She is always feminine.

In the name of political correctness we are slowly destroying our language. Bah!!

Fun fun fun, this is the stuff I love.

Coda Hale’s advice is pretty good, but I understand entropy to be something different. If there are 40 bits of entropy in the world hello (there aren’t but for example’s sake) then md5(hello) doesn’t suddenly give me 128 bits of entropy. You don’t get entropy by passing it through functions, you can only get it from randomness. Which is why your key shouldn’t be any sort of string at all, but rather a completely random byte array (from some secure source of randomness - just ask Debian).

Don’t feel bad Jeff, that’s not nearly as bad as the multi-million dollar blunder I found last week (linked in my name) - you were just protecting our precious Rep :wink:

@jake
Why would you use part of the password as a salt? I’m no crypto expert but that sounds like a complete WTF to me.
What’s wrong with just using a random number?

Looks like CBC is going to need some explaining as well.

CBC combines the output of the previous cipher block with the current plain text block before encrypting. An IV is required for encrypting the initial block.

CBC is actually quite robust for errors during transmission. A 1 bit error in one block will result in that block decrypting to garbage, and the same bit flipped in the subsequent block.

Because of this property, it is possible to change the plaintext without knowing the key. CBC+block wide salt = particularly bad news. Since you don’t validate the salt, an attacker can modify the first 8 characters of the string. More advanced attacks are possible if the user collects a sufficient amount of cipher text blocks with known plaintext.

In general the following rules should be followed when using a cipher in CBC mode:

  1. Use a randomly choosen unique salt
  2. Sign both the salt and the message with a good HMAC
  3. Use strong validation of the decrypted input

Also, for disk encryption use a cipher mode meant for it, like XTS.

@Joshua

CBC and CTR can seek as well.

@Mark She is always feminine.

Except when she is a ship, boat, or other vessel. Or sometimes a gun, cannon, or other weapon. Or the sea. Or nature.

http://en.wikipedia.org/wiki/She

I have purchased a number of books over the years, but none come close to my first purchase Applied Cryptography by Bruce Schneier
http://www.schneier.com/book-applied.html

The best part about the book is that it is 90% processes and 10% code.

That is - Encryption is NOT a computer task, it is a process in which computers play a role.

It describes how people could/can hack your communication, and therefore how to best stop it. I’ve never made the mistake you outlined only because I read this book cover to cover before writing a single line of security code.

It also introduces concepts such as how secret you need something to be. If you use standard technologies for encryption, then you can expect the data will be cracked quite easily in about 5 years (computers doubling in speed at approx. 18 months). Using moderately advanced encryption techniques, and you are looking at 10-15 years.

Using very time consuming methods, you might get decades (depending on when quantum computing comes out). The point is - if you don’t want people to know about it, don’t store it!

But most encryption that people deal with is in the moment, were the details of a login, transaction, etc. are needed to be kept secret. This is easily handled.

BUT - just remember, security on a computer is like physical security. Even if you implement the best security available, if someone wants it enough and has the resources, they will get what they are after. It’s just a matter of making it so difficult and time consuming that it isn’t worth their while.

Honestly, I’m getting very uninterested in your blog.

The last couple blog are abundantly obvious to anyone with a modicum of computer science education. I mean basic things like formal logic, discrete math, algorithmic thinking/analysis, and cryptography.

Why is it again that you don’t seem to support the need for basic computer science education for programmers?

This is like one of the softball easy questions that shows up on the first midterm of a Computer Security or Cryptography course.

Sorry to say this Jeff, but if you don’t know what ECB is, and if you use 3DES in new code, then you don’t have a reasonable grasp of encryption concepts.

This is literally first-week material in any Cryptography course.

You have no idea what you’re talking about, do you, Jeff.

Buy and read a good cryptography book… instead of reinvent the wheel.

Yet again, Jeff Atwood demonstrates how incredibly ill-informed he is. First it’s NP-completeness, then it’s using a English dictionary word as a password, now it’s using 3DES in ECB mode. This guy is a clown.

Christ, you guys are a bit harsh. Sure, he didnt know that you’re not supposed to use 3DES in ECB mode.
Guess what, neither did I until I read this. Probably because I never took a crypto elective, and to date have not yet had to implement any crypto at lower than library level. Id say my ignorance is forgivable.

All of you experts that know everything about everything perhaps shouldnt read a blog pitched at the rest of us?

At the very least its taught a bunch of mortals like me(well at least one :p) that we should be very cautious about doing any lower-level crypto, which is a good thing.