It’d be interesting to see how it works, but if it lives up to it’s promise, that’s a very cool product!

Comments from my old blog:

Product has launched and the feedback has been great. I think we have lived up to the promises.

By Brett Campbell at 16:06:35 Tuesday 24th April 2007

Right, some context. The customer needed something straight forward - notification emails to be send out to users about the items on this list. Initially, the plan was to use the workflow in MOSS for this. Sure, doing ‘digest’ emails would require a custom step - and I still think that this would be a good feature to have - but that all seemed possible. (By digest email, I mean having one email which said ‘You have 3 items deal with - A, B and C’, rather than seperate emails for each one’)

However, the Delay steps in Beta 2 TR - which we were supposed to be releasing onto - didn’t seem to work properly. Certainly, I had consistent problems with them - see elsewhere on this blog, and I know that other developers have posted describing the same problem - they just never return from ’sleeping’.

So, ultimately we ditched workflow due to time constraints - which is a real shame, as I think it’s great. Anyway, I then looked at having some sort of timed job or similar. I’ve built these for Open Text’s Livelink system, and it’s pretty straight forward there. I thought it couldn’t be hard for SharePoint 2007. Well, it isn’t, but there wasn’t any documentation or blog postings out there about it - and time was pressing now.

I then looked at how you’d do this for SharePoint 2003 - and as Andrew Connell notes, this was a scheduled .exe (uck) or a Windows Service (a little less uck).

(Actually, a digression here - I don’t actually mind CRON jobs. In some ways I’m a bit of a luddite, so just saying ‘run this command at this time’ is the sort of thing that appeals to me over more sophisticated (and complex) approaches like, well, Windows Services. However, I detest the user interface for Windows Scheduled tasks. The wizard doesn’t make all the options available to you obvious. You can’t edit the main features of the tasks in an ‘Excel like’ view. If you do want to edit properties, it item-by-item, with lots of flicking between tabs. And part of me rather thinks that some sort of calendar view might be useful - especially if you could get a consolidated view from across numerous servers! )

Back to the point. So, I built a Windows service, and it worked. Sadly, though, it had a huge memory footprint - 60Mb! This is acceptable when it’s actually doing something, perhaps, but not for the hours it spends waiting between sending these emails.

Eventually, I realised what was happening. To access the SharePoint object model, the service was using the Microsoft.SharePoint DLL. This in turn was loading other SharePoint assemblies. Next thing you know, it’s loaded 60Mb into the application domain - and the stuff remains there until the service is restarted.

The answer to that was to pull all the bits that use the SharePoint assemblies into a separate application domain, and have the service load, use and unload that app domain.

Anyway, in hindsight:

1. I would use a windows scheduled task for this rather than a service. This is despite the fact that the service can be administered more easily.
2. I would use the SPJobDefinition to create a service in SharePoint itself rather than either of the other two approaches.
3. It’s obvious that the SharePoint dll was going to cause other assemblies to be loaded and to use up lots of memory. It’s worth remembering that, and avoiding having them sit in memory if not doing anything.

• Developers make rubbish testers. We know our own code too well, and already have expectations of how things should work.
• Testing has too many variables for any reasonable size application. You can’t test exhaustively. Equally, testing only what you think needs testing will also miss things. I’m beginning to think some automated, semi random testing (if you can) is the way forward - and you’ll still miss things.
• Specialist testers are good. I’m convinced a specialist would see what I’ve missed, and have good ideas over how to test generally. I don’t think I’m alone in that..
• Automated test is not a panacea… I really don’t see how it could apply in this case, at least not without a unit test program that could create database records, read a SharePoint library, and read an exchange server. All reasonable - but how do I then test the test app? ‘Cos it’s a complicated as my actual application.
• … and Unit testing isn’t a panacea either… I know, they’re related, but this does at least imply that you’re testing, well, small units of code. That relies on problems not occuring because of mismatches in the interoperation between units.
• … and with them both, you have to remember that you’re designing the tests. If you didn’t think of the case to handle it in your code, do you think you’ll think of it to test for it?

All that said, my application seems to work pretty well. Just there was a lot of manual cross referencing of results to check things worked, so I had a lot of time to think.

I’d really like a project where I can get thoroughly stuck into unit testing. Didn’t use it in this one, but I did think about how I would’ve done it - and I suspect I’d have missed one of the bugs I found. I suspect that unit testing’s main advantages are in forcing developers to actually think up front (sometimes rare), and in ensuring a consistent public interface despite internal changes. But I don’t see how you can get away from the fact that someone has to site and decide what to test - and that way things can be missed..

Thus, I decided to benchmark the Symmetric alogrithms in the .NET Framework - DES, Triple DES, RC2 and Rijndael. To make life interesting, I thought I’d try them with differenct key sizes and block sizes, and cipher modes.

So, I’ve linked to definitions of these factors, but for those who don’t want to read vast chunks of Wikipedia, here are my (simplified) definitions. For anyone really interested in learning how to program with encryption properly (and in learning why their 128 bit key probably isn’t 128 bits strong) I can strongly recommend the book ‘Practical Cryptography’ by Bruce Schneier and Niels Ferguson.

Symmetric ciphers are ones like you used when you were a kid. You have some operation that turns a message into garbage, and then the reverse of that operation turns that garbage into a message. Some algorithms don’t have a reverse - they are asymmetric ciphers, and are a whole different kettle of fish.

Keys are the password you use with your cipher. For example, if you’re cipher as a kid was to shift all letters in the alphabet, then the key might be the numbers of characters shifted. Big keys are harder to break. Think of it as being just like a password or PIN number. If I tell you that my PIN is 4 digits, you might be tempted to guess all 10,000 possibilities, and on average you’d figure my PIN out after 5000 tries. If my PIN was 8 digits, then there is 100,000,000 options - and you’re less likely to try all the possibilities, eh?

Block sizes. Well, okay, some ciphers work on blocks of data, rather than each byte (or each ‘letter’). These are block ciphers. There are also stream ciphers, where each byte is encrypted one by one. Anyway, in block ciphers there is a limit to how much data can be encrypted without ‘leaking’ information. Larger block sizes can encrypt more data without that leakage. (That’s not to say that the block has been decrypted, but an attacker could start to learn things about the contents of that block.)

Cipher modes don’t really have a parallel with how you did codes as a kid. I guess I would describe it that if the cipher is about how you make an apparently random set of bits, then the cipher mode is about how you then use them. There are lots of different modes, but the .NET framework classes only seem to support 3 - ECB (Electronic Cookbook), CBC (Cipher block chaining) and CFB (Cipher Feedback).

So, what are the algorithms:

• DES - An old encryption standard, now regarded as offering poor security, but so widely used that it is still in operation as a legacy system.
• Triple DES - An improved version of DES, made by essentially applying the DES 3 times.
• RC2 - A moderately old encryption algorithm. Flexible key lengths, but short block size.
• Rijndael (aka AES) - The latest encryption standard. The Rijndael algorithm was selected from several as part of a competition. It wasn’t regarded as the most secure, but it was quite quick. The Advanced Encryption Standard (AES) is actually a subset of Rijndael.

The Test

I found a nice text file - “The complete works of Shakespeare” - as my test data.

For each algorithm, for each mode, key and block size, the test program encrypted and decrypted the data twenty times, and reported the average ‘time’ for each operation. I was using the Win32 QueryPerformanceCounter function, which doesn’t really return a time so much as cycles. However, all the tests were done on the same machine, so they’ll do just fine for comparison purposes.

Results

With the several factors tested, there are many ways of slicing the data. It’s worth noting that these results are pretty rough, as the times taken also include file IO operations, and with any modern PC there’s also something else happening at any single time. Also, the times are the total time taken to encrypt and decrypt, which might not be the same for each operation. Treat the results as a loose guide.

First let’s look at the raw results. You can get the results here (Excel file).

Unsurprisingly, DES is fastest - given it’s age, and the low level of security it offers now. Triple DES with the longest key it supports was generally slowest. RC2 covered the full range of results, which is also unsurprising, given it’s flexibility, and Rijndael sort of falls in the middle.

The first thing I noticed was how few tests there were using DES or Triple DES. RC2 and Rijndael are much more flexible in their use.

Next, it’s interesting to note that RC2, DES and Triple DES using Cipher Feedback Mode (CFB) were all very, very slow. They all seem to suffer very badly using CFB.

So, excluding the CFB results then (as they are so exceptionally slow), what do the other results show? Well, Rijndael does not suffer so badly in CFB, although CFB is slower.

ECB appears slightly slightly faster in the table, though examining the CBC Mode Graph shows little difference.

To compare the modes, I looked at just the operations done with the Rijndael cipher.

Again, we see little difference between ECB and CBC, so I guess there’s no reason not to use the more secure CBC mode over ECB (for an example of it’s weakness see here). Also, for 128 bit blocks (as required by the AES standard), CFB is as quick as ECB.

Rijndael is not great in CFB mode with blocks of longer than 128 bits.

Okay, so let’s focus on just one mode (CBC) and look at the results shown in the CBC Mode Graph. Well, it’s interesting to note that RC2 with a 112 bit key was quite quick - faster than with some shorter keys. However, it’s only about 6.5% longer to use 128 bit Rijndael - which is a key that is 14% longer. Doubling the key with Rijndael to 256 was only 10% longer than 128.

Longer blocks take longer to encrypt and decrypt. 64 bit blocks seems a little short these days, only being safe for up to a couple of hundred megabytes. 128 bits seems more reasonable. 256 bits seems excessive. Rijndael seems to have little penalty for using 256 bits over 128, though if you do, you’re not using an AES standard encryption.

Conclusion

DES and Triple DES are old. DES isn’t secure, and Triple DES doesn’t seem to offer much given Rijndael and RC2 being much faster than it.

In terms of cipher modes, these classes only seem to support ECB, CFB anc CBC. ECB is generally regarded as being a poor mode - it’s not very secure. CFB was typically slower than CBC, and as Microsoft have already implemented the classes, some of the advantages CFB (i.e. encryption and decryption being identical operations) have been lost.

So, then examining Rijndael in CBC mode, well, there is little penalty for using 256 bit keys or 256 bit blocks. However, it’s probably worth sticking to 128 bit blocks as 1) it is plenty, and 2) it is AES compatible.

All in all, I was surprised by how similar a lot of the results were for different algorithms, and I was surprised by how slow some of the CFB mode operations were.

To be honest, I can’t really think of a reason not to use Rijndael with 128 bit blocks, in CBC mode. Unless time is a really critical factor, 256 bit keys are stronger. Finally, the RijndaelManaged class in the framework is a managed class, rather than a wrapper for a COM object.

So, the winner is Rijndael!

Comments from my old blog:

This is a very informative article. I have just started looking into encryption, and I have come across nothing on the internet that is as concise as your article.
Will you be doing something similar with asymmetric encryption as well?

By Firoz at 06:22:04 Friday 9th February 2007

Yup, well, at some point. The truth is, in the .NET 2.0 framework, there isn’t a lot of other asymmetric algorithms. RSA is about it. I think in the .NET 3.0 framework there is elliptical curve, and that would be interesting…

So, yes, when I get around to it.

By Andy B at 10:09:43 Friday 13th April 2007

I guess the lesson is to always maintain redundancy. Fortunately, the guys writing Firefox (presumably ‘cos they had problems with the bookmarks too) took to storing backups of the bookmark file - and that has worked nicely in this instance.

Anyway, it’s enough to put me off - I shall be looking for something else. I gather that Delicious (insert your own dots) has a good Firefox plugin, and works by tagging, which is good also. I’m just a wee bit worried as I really want to have a heirarchy too - so I can drill down, rather than just getting a ‘pool’ of matching tags.