We have a new version of MS-OFFCRYPTO out. The big change is that how CryptDeriveKey was documented on MSDN was incorrect, we copied it, which made our document also incorrect. As it turns out, CryptDeriveKey always uses the same code path for AES as it does as if the hash output is shorter than the needed key. Several people have written me about this, which I do appreciate – it's how we first knew about the problem and got it fixed. If you're trying to make something work with Office 2007 encryption, get the new version.
There's also some interesting stuff that gives a preview of how we'll be doing encryption in the future. Some of this will change in the next update, but the general outline still holds. Some neat stuff that I'll talk about in more detail later – don't have time today.
The other thing that came to my attention is that there's a really interesting blog – the "Engineering Windows 7" blog. Today's entry is written by someone I've known the longest at MS – Larry Osterman. You can read his post here - http://blogs.msdn.com/e7/archive/2008/10/15/engineering-7-a-view-from-the-bottom.aspx. The overall blog is some interesting stuff, and explains a lot of why we make certain trade-offs.
A quick story about Larry that's funny in hindsight. Back around 1997, I was working at ISS, and one of our devs had a VPN into our corporate network. Everything on the ISS corporate network at the time was subject to abuse/testing by the ISS Internet Scanner, and I was dev lead on the Windows version. Our dev had is POP3 server keep falling over, the service would hang, and he had to restart his server. Since we tested the scanner many times per day, his server fell over a lot. We got to the bottom of it, and it had a simple buffer overrun. Since ISS has always done responsible disclosure (before it even had a name), the dev called the company responsible, and they didn't do anything. So I called them, trying to explain how serious this was. They replied to my e-mail by telling me that buffer overruns on Windows were not exploitable (ROTFLMAO, yeah, right – even in 1997, we knew better). I tried in vain to convince them that this was something serious, and told them I would go public with an advisory if they didn't do something.
Finally, it became apparent they weren't going to do anything – they'd quite rudely told me I didn't know what I was talking about, they wouldn't fix it, and that was that. So I wrote up an advisory – pretty informal stuff by today's standards – and because I don't encourage criminal activity, I didn't bother to create an exploit – I just said it crashed, looked exploitable, and the company wouldn't fix it, so your only real option was to use someone else's product. As soon as I did that, I got a very special letter from the company's legal department the very next day. Sigh. One of the reasons I came here – everything I ever asked Microsoft to fix when I was at ISS eventually did get fixed, so I've liked Microsoft's attitude towards fixing security issues since I first interacted with Jim Kelly (another story here) back in early 1996. If you search BUGTRAQ archives on my name and POP3, you might be able to dig up the only time I've ever gone public without a fix.
A public discussion ensued, I think on the old NTBUGTRAQ list. The company continued to assert I was an idiot and the problem wasn't exploitable (simple stack overrun), and Larry came to my defense, which I've always appreciated.
An interesting thing about Larry's blog post – Steven Sinofsky used to run Office. How Larry describes Windows 7 working now is how Office has run for quite a while, thought the "feature crew" concept was new to the O12/Office 2007 development cycle. It works well, and makes life as a dev much better than some other experiences I've had, and also helps ship more predictable, higher quality code, which benefits everyone.