So I'm looking at the feedback on my and J's MSDN mag article: http://msdn.microsoft.com/msdnmag/issues/04/11/CryptoUtility/default.aspx 

I noticed that there are many "9" ratings, and many "1" ratings.  Love or hate, I guess.  There are only a few text comments giving us an indication one way or another.

0)  "Your timing is perfect! Thank you for producing this type of depth in your article. I am in the process of doing almost the exact same thing but had limited myself to the exposed framework classes. Showing how to use the DPAPI w/PInvoke properly is a huge advantage. My customer thanks you.":  This poster rated us a "9", THANK YOU sir!  There were many other similar comments.  But I want to focus on the less positive posts so we get some debates going....

1)  AES vs. Rijndael key/block sizes:  One common technical objection is that we say Rijndael has 9 permutations of key size and block size; the posters say no, AES allows only three, with block size fixed at 16 bytes and keys of 16, 24, and 32 bytes.  We allude to the fact that AES is a subset of Rijndael but we weren't explicit enough.  Just know that in the article, we talk about Rijndael and use its full complement of block/key combinations.  THANKS to Harold Andrews for pointing this out.  Harold--what's the PhD in?

2)  " come to find information that will allow me to write code to solve a solution. I don't feel I learned enough to incorporate the CryptoUtility into our application":  Hm, tough one.  Please take the time to unzip CryptoUtility, and note that it contains a DOCS folder.  In there, you will find a CHM file (the CS one is _corrupt_, I think, but the VB one is complete) and a Word doc with very detailed usage instructions for CryptoUtility which we've given to two customers for their admins/developers to put it into practice.  Of course we also give VB and C# code.  NOTE it was originally written in C#; I apologize if there are stylistic nuances in the VB that don't ring true to that language's style!

3)  "Gee... Astonishing content, but you should have put a link to a simpler, more straightforward solution, so that a developer looking for some security would put it to work in a couple of minutes"  OK:  Unzip the CryptoUtility download.  Then, open the solution file; you'll notice there's a Setup and Deployment project.  If you build it, it generates an MSI.  You can then use that MSI to install the full source and binaries of CryptoUtility.  Also, we include the CryptoAdminUtility, which consumes an XML file to do a complete setup with all the COM+, ACL's, registry, etc etc.  Plus, there's a GUI if you want to do it manually!  Oh and yeah, there's full source code, extensively commented....Dude, more than that and you'd have to actually PAY ME! :)

4)  "Would've been nice if the authors mentioned the original developers of the DPAPI wrapper class (See "How To: Create a DPAPI Library")..."  Please look in the source code of DpapiCryptographer.cs or .vb, where we give extensive credit and links to the originators of the PInvoke signatures we used.  However, our DPAPI implementation is significantly different and improved upon others we have used.  Most notably, we optimized/simplified the exception paths.  AND, we clean up unmanaged buffers/handles diligently, which many other implementations do not--and hence leak those entities.  So ours is evolutionary enough that we don't credit the code, just the PInvoke heritage.

5)  (greatly shortened, ellipses are mine; edited to fit this blog) "The article misses the problem... I can rip this article to shreds...no discussion of how the key gets to all parties who will be encrypting and decrypting data...key must travel over some medium between the client and the server......there is no question that a grid of zombies or hardware routinely available on college campuses can be used to break AES keys in a reasonable period of time... Any XP or 2003 LAN that has been running for over 3 days must be considered to have all passwords and user ID's comprom"  Well.  What can I say.  A lucid, very lengthy, and totally incorrect not to mention completely misinformed post.  So, there are AES-breakers on college campuses, ZOMBIES in fact!  Well that's it then.  I am pulling all my money out of the bank, and hiding it under my mattress.  Some suggested reading for these points:  Bruce Schneier, Kerberos, our article (again, seems to have missed some points)...

6)  The best post:  "the reason Rijndael uses different numbers of rounds with various block sizes is to provide an equivalent level of security at each block size; a larger block sizes makes certain attacks easier, hence the addition of extra rounds for an equivalent "safety margin". So 256-bit block Rijndael is not trivially more secure than 128-bit block Rijndael (aka AES) as this article suggestsI don't have a super-excellent answer to this yet.  Can some reader knowledgeable in this arcana clarify? 

My take on it is:  larger block sizes increase cryptanalytic success linearly, whereas more rounds increase cryptanalytic difficulty exponentially. 

All the attacks on Rijndael I've read about are at 6 to 9 rounds, and those are barely less than the key space.  MANY "attacks" are rumor and conjecture.  The soundest imply something like 8000 multivariate equations of 1600 variables, but I am NOT a mathematician, just a developer.

So I don't have a definitive answer to the last post (#6).  I'm standing by the implication we make in the article, that Rijndael's larger number of rounds with greater block size more than compensates, and in fact make it more secure at those block sizes (assuming also larger key size) than at smaller sizes...but if someone can make a solid factual argument to the contrary, we'll get the MSDN folks to post a correction.

 

Cheers!

Michael