If you've dealt with symmetrical algorithms, such as DES, 3DES or Rijndael, you're probably aware that you must supply a key and and IV to encrypt/decrypt. If you're not aware of this, you shouldn't be writing code that works with cryptography :). Everyone knows what the key is, but what's the IV? IV stands for initialization vector. IVs are used to “jump start” the cipher stream. Not clear? It helps to understand how to look at a cipher.

Think of a cipher as a random mapping from a piece of plaintext to a piece of ciphertext. Most modern ciphers are block ciphers: they work on n-bit blocks of plaintext at a time. Thus we can imagine a cipher such as Rijndael (which uses 128-bit blocks) to have a huge dictionary: one entry for every possible plaintext and it's corresponding ciphertext. In reality, there's not that much memory available, so instead the ciphertext is computed.

So lets take a sample message: “Hi Bob, how are you?” We'll split that into blocks: “HiBob HowAr eYou?”. With a particular key, the ciphertext might be “LaAHz IAtXm LyJxr”. Everything's nice and safe. Now, let's send another message: “Hi Bob, game?” This becomes “HiBob Game?”, and ciphertext “LaAHz KozhW”. Notice a problem? Since the first two blocks have the same plaintext, they will have the same ciphertext. If an attacker knows the format of the message, he can start to guess the first part of our messages (since “HiAlice” and “HiEve” would have different first blocks). This can get worse.

Imagine that the messages are orders, and the first block is the item number, the second the price, and the third the quantity. Now an attacker can determine (say by entering an order and looking at the output -- called a chosen plaintext attack) which ciphertexts correspond to which items/prices/quantity. Modification of the messages can be stopped by a digital signature algorithms. But what about reading? Enter the cipher mode.

The cipher mode I've been describing is ECB, Electronic Code Book. It's exactly as it sounds -- basically a big lookup. Each block is processed by itself. As shown, this isn't very secure for most applications. The most basic improvement is the CBC mode. (There are other modes as well, but CBC works for this article.)

CBC stands for Cipher Block Chaining. CBC takes the ciphertext of the previous block, and XORs it with the current plaintext block before encrypting it. Thus the ciphertext block for “10000” won't always be the same, but it'll depend on what the preceeding plaintext is. So, the message “12345 10000 29500” will have completely different ciphertext than “54321 10000 29500”.

So, using the previous block is easy, but what about the first block? This is where the IV is used. The IV is the “previous encryption“ for the first block. So when we encrypt “HiBob“, we're going to first XOR “HiBob“ with our current IV.

IVs are not sensitive. You do not need to hide the IV. Many times, a unique message ID is used as an IV, since many applications require a unique ID anyways. It's perfectly fine to send along the IV as the first piece of ciphertext. Thus, we read the first block, and use that as the IV when decrypting. This makes managing the IV very simple, since it's right there with the message.

However, just remember to never reuse an IV! If you reuse an IV, it defeats the purpose, since the benefit of the IV is negated. Any given plaintext will always be the same with a given key and IV. But since IVs aren't sensitive, and easy to manage, this shouldn't be an issue.

Are you a strong ASP.NET tester or developer? If so, I might have a job for you. We're currently looking for a tester with strong development skills who can create and automate test cases for an ASP.NET application. Strong coding skills in C# as well as understanding of ASP.NET, HTML and SQL are required. We're also looking for strong developers to join an existing team and work on a medium-sized project.

If you are interested, drop me a line: mgg AT atrevido . net.

Quite some years ago (8 or 9?), I played a game called One Must Fall, a cool robot melee fighter game. Now they released a new version with cool effects, Internet play, and so on: One Must Fall:Battlegrounds. I just recently learned it was shipping (they did good job of press before it shipped, but I never heard about it after it shipped). My copy finally arrived in the mail today. I start it up, check it out, and after winning a level, the game quits with this message box:
---------------------------
Protection Error
---------------------------
Debugger detected  - please close it down and restart! Windows NT users: Please note that having the WinIce/SoftIce service installed means that you are running a debugger!
---------------------------
OK  
---------------------------
This is wrong. I work from home, as well as play games from home. I've got a few debuggers installed (not SoftICE though). At the time, I had Visual Studio closed, and hadn't been running the debugger since my machine started. But what's worse is that apparently they thought this perfectly acceptable! Note that this doesn't stop piracy *AT ALL*. Experienced crackers are going to crack the game, and serious “pirates” are going to apply patches. Having a CD check stops “casual piracy”. Having a debugger check stops wannabe crackers from cracking. That's it!

I've emailed support with my current plan of action: Try a pirated version and if that doesn't work, return it for a refund (something publishers don't like). Sigh.

Update: Well, I reluctlantly installed a crack from a game backup site. And guess what? It works just fine. No more debugger complaints (and I get to take the CD out too).

Last update: Got in touch with one of the developers. At first, they thought it was a problem with DirectX, or the video card or likewise, since their code doesn't do any checking. However, they were using SafeDisc (which is less safe than rolling your own, since there are a few tools that instantly remove SafeDisc). However, after I told them that a pirate crack makes the game run, he said he'd get me an unprotected version. Hey, at least their support is good!

At the PDC '03, and the time after it, it seemed like Microsoft was really liking ATI. I remember using their cards a long time ago, and it was a very bad experience. So, I've been quite loyal to nVidia for the past while, since they hadn't disappointed majorly... until a few days ago. I just left for a trip, and was counting on using Remote Desktop to get access to VS, Outlook, etc. while on the road.

I connect to my machine from my laptop. User... pass.. applying settings -- window closes. Try again. On another machine. Try with a different user (perhaps the profile was messed up...). All the same. After login, the window closes.

Google group search for “remote desktop closes”... and tada! Are you using nVidia's drivers? Guess what? Their drivers install a service and yep, that service kills remote desktop. Stop the service, and you're set. Well, I'm 3000 miles away from my computer, so that's pretty hard (two firewalls, so I can't connect to SQL Server and run a extended procedure or likewise).

Apparently, this is nothing that new (judging from Google groups), but I don't remember nVidia mentioning this in their release notes. Why can't hardware vendors just make drivers? That's all I need. Drivers and an optional configuration app. Seems like this trend is only getting worse...

I've been very, very busy lately, and my wrists have been hurting (spend over $100 getting a “keyboard manager”). However, among the things I've been doing, I've been involved in a usability study with the Visual Studio team. Basically, we meet over live meeting with my desktop shared, so they can watch how I use Visual Studio. This helps figure out if I'm using the new features correctly, or if the design could be clearer. I like it cause I can make very direct feedback and hopefully improve the product for others! Speaking of feedback, the new default for strings in Whidbey is maroon (at least on the build I just installed) -- I made this suggestion to someone who works in that area about two months ago -- so they ARE listening! :)

Whidbey has a host of new features. So many aspects have been fixed up so when you use it, you just have to say “Oh sweet, that's nice!”. There's been a lot of coverage of the “big” new features, like generics and in C#, refactorings, and that's well deserved. However, there's been a ton of work on the day-to-day stuff as well. The #1 top thing I miss when using Everett is auto-Intellisense, for lack of a better name. In VS2005, Intellisense activates on a single keystroke (most of the time), and the list is complete: even keywords are listed. I think preprocessor directives are the only things not available (I've put in a wish :)). It might not seem like a big deal, but it is definately the top thing I notice line-by-line when working in VS2003. CodeRush (www.devexpress.com) helps a bit, but still doesn't come close to how great Intellisense is in VS2005.

Ever write a short main method to test something out? You try something, and write the output to the console. Or perhaps you have extra debugging info going to the console while your program runs. I've been annoyed a lot when I run my console app, and VS opens a new console window for 1 second, and then the program closes, and I can't see the result. I also hate having to switch back and forth between VS and the console app while running.

Visual Studio 2005 takes care of this, with the new “Console” debugging window. As far as I can tell, the console streams are mapped to this pane inside Visual Studio, so you can dock it, have it as a document window, or however you want. Afrer your program runs and exits, the data will still be there.

Do note that not all the new Whidbey console features are supported, since it's not a “true” console window (you can't use the Win32 console functions on it). But for basic console work, it does the trick.

Just recently, I had three great things happen. Actually, I think there were some others, but I've since forgotten them (I wanted to write this post a week ago).

1: My wife finally got to Atlanta. After some issues with INS (grrr) and Delta (grrrrr), we finally got her up to Atlanta from Guatemala on a six-month visa. No more sleeping under my desk.

2: Code Center Premium access. I got my smart card and account info, and now I'm in. The complete Windows source code, including the .NET Framework. Now I can browse the source, as well as doing just-in-time source debugging on Windows and .NET. Swweeeeeet. Had I had this years ago, I'd have saved myself so many headaches (as well as written much better code!).

3: Renewal in the Microsoft MVP Program. Lots of goodies (like source licensing), as well as access to a lot of great information and contacts.

On Friday, I had some issues with Visual Studio setup. I was trying to add some features, however VS wasn't liking my MSDN source (I guess I used a different MSI to install before, and the MSDN MSI was different). PSS couldn't resolve it with their cool little MSI tools, so a re-install was in order.

I was hesistant, since I have some add-ons, lots of customizations, and things like VSIP installed. Well, even after the full uninstall-reinstall, all my settings and addons were retained. I'm exceedingly impressed.

I also spent this weekend coding on my wife's laptop. She only has the framework, no SDK, so it was quite an interesting experience. I couldn't use ILDASM (*gasp*), and had no docs. I was also using CSC and Notepad. Getting back into VS2005 feels *really* good now :).

So I've been worried that the NT password hashing calcuation is: MD4(passwordInUnicode). Yes, that's right. No salt or anything. As you might be imagining, this is bad. I was wondering how this can be mitigated, short of extra physical security (smart cards, for instance). I found that there is a way to cipher the passwords on disk: SYSKEY.

SYSKEY is running by default on Windows 2000+ machines. Basically it encrypts the password hashes with RC4, meaning the attacker must break the RC4 encryption. However, by default, SYSKEY runs in Mode 1, which stores the RC4 as an LSA secret, so it's trivial to get it out. So, if someone has physical access to your machine, SYSKEY doesn't do much.

However, there are additional modes. These allow you to use a password to derive the RC4 key. The password must be entered when the machine starts up. The other mode generates a random RC4 key, and stores it on a floppy disk. The floppy must be present when booting.

To enable these, just run SYSKEY (Start -> Run: Syskey). Select the mode [and password]. Enjoy a more secure computer.

I was just opening up some of the BCL code in VS2005. Wow, do I love this product. I just noticed some new things on the document tabs:
  “Close all but this”
  “Show File In Explorer”

When I've got a lot of files open that aren't part of a solution (like the framework sources), that last item is really nice. As is the former item, as you can imagine. Now if I could just get the tabs to open in the right order -- the tabs are organized by some kinda MRU system, which I find rather annoying.

Just 3 out of 10 million new things in the new IDE. Got a cool tip/trick (or a change you dislike) for the Community Technical Preview? Leave a comment.

So, why do we care about multiple iterations, good salting, etc.? Isn't a simple MD5 hash enough?

http://www.whitehat.co.il/forum_viewtopic.php?14.149

Yes, that's right. Rainbow tables (almost 120GB in total), so that passwords like “!BinM,$YuSt.b7“ can be easily cracked -- If you are using LM hashes. The newer NT hashes don't have this problem yet.

That's another thing to consider when determining password strength requirements. Normally we can say “Oh, doing n steps will take at least x time, and passwords expire in x/16 time, so we're safe.“ However, if our apps are designed in a way that allows someone to precompute an attack and make a time tradeoff, our password strength versus time no longer means anything.

Update: Edited article because as far as I can tell (they won't answer my inquiries) these tables do not attack NT hashes, only the weaker LM hashes (no surprise).