Encryption, Development and AES

If the custom module wasn't enough, I'm now wondering off into encryption land.  A quick scouting of the System.Security.Cryptography namespace shows me a ton of stuff to play with.

Ooo, AES.  I like AES.  It runs on my router(s) @ home and is viciously annoying to crack (TKIP f0r t3h w1n!!!11).  Cool, let's use that, its good enough for top secret docs for the gov so it should be good enough for me.  But, as with anything else, there's a catch or ...20.  Here's some basic considerations.

Will this data be searched? 

Searching encrypted data is a royal PITA and a huge overhead.  Example : saving data to a db with encryption happening in the business layer.  A perfectly viable user says to the application "hey, find this" -- you cannot directly ask the database to find it, it is impossible, so every search that happens comes across, ALL OF IT (say 2 million records), decrypts, the search happens, find the records necessary and passes that on.  Not very reasonable nor scalable.  2nd option for this is do it on the sql server itself.  Fundamentally I have a problem with this for 2 reasons.  1, a purely architecture standpoint, this should never be passed off to the data source.  In the real world, it's probably ok to offload some of that overhead, but still, using the OSI model alone says "no no" -- encryption happens in the presentation level and offloading it means you pass though all 7 layers ONCE before you encrypt -- bad bad bad.  2nd, unless the data connection between app/server is encrypted to hell and back itself, your encryption is trumped and effectively worthless.

How much protection is necessary?

The question of the ages.  Understanding the CISSP-ism of protection and risk management: the amount of protection spent on it should be equal to the amount of total loss of one breach by the inverse of the possibility of recurrence.  So say the data is worth 10 million dollars for ONE loss.  The probability of loss is once every 5 years.  10m/5y = 2 million a year should be spent to protect it.  No really.  Now, if there's no REAL value to the data, ie, its personal junk you keep at home for giggles, then whatever the server can handle works fine.  Otherwise, use reasonable + 1.

I'll stop there.  Other questions can range from "Who needs access to it?" to "Where will the server be physically housed" -- but thats somewhat outside of the scope of this post.  Not saying they're unimportant, just "too much" for this post.  I think my first task will be working on getting something simple to encrypt, like a file or a string and work up from there to see how much overhead this thing creates.