If you're enough of an Office crypto geek to stay on top of the most recent changes in MS-OFFCRYPTO, you already know about some of this, but my assumption is that most people aren't going to want to parse something that hard to read. What we're doing is introducing some substantial improvements in our encryption in Office 2007 SP2, which are known to MS-OFFCRYPTO as 'ECMA-376 Agile Encryption'.
Our goal as a company is to make all of our encryption agile. Many government customers have requirements to use encryption algorithms specific to their own governments, and we'd like to eventually get to a point where (for example) Office 16 can emit a document with improved encryption that Office 2007 can just pick up and use. In Office, our first attempt at this was how we created password verifiers – we let you use any hashing algorithm we can support on the operating system, and the spin count is also agile. I don't think we created a way to configure Office 2007 to emit password verifiers with a configurable spin count, but if one shows up with a higher spin count created by a future version, it should work – which was the short-term goal.
The encryption we used in Office 2007 for the new file format is pretty robust – even with very advanced techniques, Elcomsoft reports getting around 5000 cracks/sec. Compare this to Acrobat 9, which allows 74.5 million cracks/sec – meaning it takes about 15,000 times more computing power to crack a password on an Office 2007 document than an Acrobat 9 encrypted PDF. If you're interested in the details of where Adobe made some mistakes, check out With 256-bit encryption, Acrobat 9 passwords still easy to crack. Our default encryption uses an iterated SHA-1 hash with an iteration count of 50,000, and AES128 as the encryption algorithm. In order to check a password on our system, you have to perform 50,002 SHA-1 hashing operations, and 2 AES128 decryptions. On Acrobat 9, that's just one SHA-256 hashing operation. To make matters worse, SHA-256 is more efficient than SHA-1. To be fair, we very nearly made the same error until our tester found the problem and I fixed it prior to release. The key here is that when a password is used to protect something, that's going to be the weakest link, and using more bits for the encryption algorithm will not make anything harder to access. Breaking the encryption itself (assuming a modern block cipher) isn't feasible. Brute-forcing the password is feasible, so the order of the day is one of the least well regarded of the Saltzer and Shroeder design principles – work factor. If you can't absolutely stop something, make it so much work that it isn't worth it.
With the new encryption, we're introducing a bunch of very cool stuff:
If you're running on Vista, this means you can use anything that you can write a CNG plug-in to support, which means we'll be able to support Suite-B compliant encryption. To be clear, if you're using a strong password, the existing Office 2007 encryption will do a very good job, but you're restricted to one set of algorithms, and you're missing cipher block chaining and integrity protection.
The reason we're shipping this in a service pack is that we'd like customers to be able to be Suite-B compliant using Office 2007 SP2, or use other private encryption mechanisms. The second reason is that we need Office 2007 SP2 users to be able to consume encrypted documents created by Office 14 when we ship it. We do have some more cool stuff we're working on and I'll blog about that when we get closer to being able to release Office 14. When I first came to Office, we had some fairly awful encryption (see Office Crypto Follies), and with the help of a PM who also serves on the Microsoft crypto board, and some really great devs and testers, I think we now have a first-class product with some of the best document encryption in the industry.