Algorithms Supported by CryptoCollaboration

Some people have emailed me expressing an interest in CryptoCollaboration, wanting to know the specific encryption algorithms that are going to be supported. For the time being, in order to satisfy the requirements for my dissertation, only secret-key encryption (symmetric) algorithms are going to be in the initial release.


String support will be added shortly afterwords, however it is currently beyond my workload in order to support it.

The following I have already finished coding to compensate for, and are included in the bundled release:

Data Encryption Standard (DES) – 64-bit encryption
RC2 – 128-bit encryption
Rijndael – 256-bit encryption
TripleDES – 192-bit TripleDES encryption

I might be adding others in future releases, but for the time being those are the ones that are going to be supported. If there are situational benefits that mandate other schemes, I would be interested to hear the business case.

I also finished the multi-threading for the encryption/decryption routines in order to optimize file IO operations, which was a pain in the butt. I am probably going to release this source before the actual solution source to get feedback since threading isn’t one of my strong suits. If you know threading pretty well, and have 45 minutes, I would love to run some code by you.

It would also be interesting to see how the general population thinks that the encryption should be invoked. I am using it as a context menu item right now that pops up a progress window post encryption event capture. Here are two little screenshots, even though they really don’t give much away about the actual functionality:

Starting the encryption process on a document:

Encryption Complete Window:

(Yeah, I haven’t gotten it to encrypt the actual filename yet :-) )

The actual settings for encryption are maintained in a hidden menu. I really hate this approach so will be changing it shortly to something else once I think of something that is more clever.


5 thoughts on “Algorithms Supported by CryptoCollaboration”

  1. It strikes me that one of the things I’m sure customers would ask for straight away is for all items being uploaded into a particular Library to be encrypted. User invocation allows the possiblity of the user forgetting.

    If you encrypt the list item name, how will anyone know what the item is when they want to decrypt it?

    Oh, and a suggestion – If using Rijndael at the appropriate settings to match the AES spec, I’d call it ‘AES’ encryption.(Given you’re using a 256 bit key, means just setting the block size to 128). For a start, non-Dutch can pronounce it, and it is the ‘Advanced Encryption Standard’, which will have more traction with customers.

  2. Interesting! I hadn’t thought about doing that, but what a great idea! (encryption enabling a document library), I will have to see if I can make that happen (I would imagine that I can trap the appropriate events to trigger this functionality).

    The list item stuff people had just asked about, I agree with you, it is a silly request. I think the string encryption *might* (big might) happen for columns, but I am not sold on the idea, or the amount of work I would have to be forward to get it to work correctly.

    Thank you for the recommendation as well for the localization stuff, I hadn’t thought about how to appropriately handle it, mostly because for this first revision I am just really pushing to get my grade out. Once I get that taken care of though, the sky is the limit with this thing!

  3. No problem, I’m full of good ideas. No, actually, we’d a request for tender that was asking for something similar to what you’re doing, and encryption enabling a document library struck me as a possible. I’m not sure how the key management would work, though. I’m guessing you’d be stuck with a block cipher, where everyone allowed to view documents knows the password. It’d probably also need a ‘change all passwords’ function.

    Triggering is actually pretty straight forward. You just need an event handler feature. There are lots of articles about them – and I knocked one up fairly quickly (a morning) so it can’t be too bad.

    Of course, if you’re dealing with Office 2007 files, which are just zips, and thus supports AES, maybe just using client application encryption would be enough?

    Encryption of data in a list column, though, that is an interesting idea. Where can I use that…? Not sure.

    Re: localisation – it’s more of a branding thing. AES is more known by pointy-haired-bosses…

    Don’t know if you’d find some encrption speed tests I did interesting:

  4. Handling the encryption event, you are right, could be done through a new list definition that used a document library as its ancestral type so I could set the event handlers in a re-distributable package. It could be done by passing in the Microsoft.SharePoint.SPItemEventProperties object to represent the event handler calling the asynchronous after event (ItemAdded) for when a document is added to a document library. I think that would work out just fine, and making it a list definition would make deploying as a SharePoint Feature a breeze.

    The key management portion is going to be key to getting this really cookin, in terms of both getting the search to work correctly with encrypted documents as well as managing the encryption / decryption routines performed against a document library. I am getting near the point where that is going to become a large issue.

    I read through your post on encryption tests, this was something I planned on doing, but I am glad that I found someone else that did it instead. I may end up using your site as a reference (if its ok) for my final paper since I will have to present the emperical performance implicaitons of whatever route pans out to be the best!

Leave a Reply

Your email address will not be published. Required fields are marked *