Next Revision Of CryptoCollaboration (V5)

I am almost done with the next revision of CryptoCollaboration, which will now make the revision count up to 5. Within a week. Yeesh. I need to get a hobby :)

Anyways, the largest changes are conditional standard encryption of attachments using the same process that is available when files are encrypted in a document library. Therefore, you will notice different interface elements when attachment elements are found within a list item, which allows you to optionally encrypt them. Some people have emailed me asking if they can use different encryption algorithms for this, right now honestly I don’t see building that in being very useful, so I am skipping it for now. If I was going to do selectable objects / encryption algorithms, I think I will instead just put some CheckBox controls or something within the operations interface that lets you select ALL fields that you want to encrypt. I will step back and look at that at a later date.

I am looking into other encryption routines to integrate into the overall application as well. I already have all the ones that the .NET framework natively supports, as well as wrote the code to have BlowFish in there. Now I am also considering putting TwoFish in the application as well. Twofish is a symmetric key block cipher whose block size consists of 128 bits supporting sizes up to 256-bit keys. I had originally wanted to include this algorithm in the initial release, but was having performance problems with my approach. I know that it is generally considered to be much less efficient than Rijndael when leveraging 128-bit keys, but it is supposed to be notably faster with 256-bit keys. Unfortunately this wasn’t my experience, so I would have to step back and rework some of my approaches to get this to work correctly.

I am still looking for more feedback on the application itself. If you want to email me directly, you can just use the contact page on the main site and avoid having to open your email client.

Thanks to everyone for their feedback thus far!


CryptoCollaboration Client Testing / Encryption Optimization

I am working on benchmarking some of the CryptoCollaboration encryption algorithms in order to optimize performance in relation to the threading that is required. It is pretty tough in order to balance out what is optimal, but it is coming along pretty nicely.Because this is solely a proof of concept, it shouldn’t really be that big of a deal, but I am finding I have to make modifications to the asymmetric encryption engine in order to continually optimize the actual encryption process. I have certain criteria that I am targeting which are required for this to be actually considered for production use. Although I should probably spend some time writing out the business cases of it, meh, hopefully when I release it I can get someone else to give me some material about that.

I am using this small WinForms client in order to test it out locally as I push builds out into the receivers that are normally called since it is easier for test and deployment; just using two text files for the testing. One of the text files is used for the document input (plain-text), and other is used for document output (encryption). Afterwards, the outputs can be reversed and re-input back into the client program, which can harness opposing methods. Looking at the client, it should be somewhat clear how this could be instead be architected through a receiver structure that will trip the relevant encryption events upon file upload. Although there has to be compensation in the encryption program as such (clearly running encryption algorithms via client trapped event through a web browser is a little bit different than running through a WinForms program), from my initial testing through integration with SharePoint it still is relatively effective.

So these are my two text files that I am using, one is meant to house the plain text and the other is meant to act as the destination for the encrypted text.

The MyTestDecrypted.txt file has 1KB because it contains the string “Adam Buenz”.

Now that I have my two files that I want to throttle the threading for in order to optimize the encryption data, the next part that I have to do is start the actual encryption process.

So I am going to take the decrypted text document as a parameter, and the encrypted output as the results file, and I am going to encrypt the document with the passphrase string “adambuenz”. I am also going to choose Rijndael as my encryption scheme, although there are several other encryption options that I built into the shared encryption library that will eventually be packaged and delivered.

Once the encryption routine is selected, I am going to trip the encryption process and collect my relevant metrics. After I collect my metrics, I am going to verify that the text was indeed encrypted.

I have collected my metrics, and it appears that the encrypted text was accomplished successfully. Alright!

The routines that are responsible for this can be seen within the relevant sequence diagrams that depict how the actual encryption process progressions. I have two methods that will get the encryption class and another that will get the hash class.

Get the Hash Class:

(Select For Larger Image)

Get The Encryption Class:

(Select For Larger Image)

Invoking the Encryption Routine:

(Select For Larger Image)

Then Calling This Routine:

There is also some exception handling that had to be integrated in order for this to work correctly:

So, this is where I am at with the thing. In the next post regarding this, I am going to be going to be releasing the common library along with the related receivers in a SharePoint solution file. Although it will allow the creation of an “Encrypted Enabled” document library, I still haven’t written the decryption CEB that will open a new application page, pop-up, or whatever that will allow the passphrase to be entered in order to trip the decryption process.

Yeah, it will only be 50% of the solution. But I want to test things gradually with this and optimize each as I encounter them. Either way, for those with a test environment that contribute to the testing, your name will be included within the final paper.


Class Architecture That Builds CryptoCollaboration

I went through a class architecture / code review of CryptoCollaboration this afternoon. Taking some feedback from Andy (his site is located here), I have been able to build and deploy a SharePoint list definition with the relevant event handlers that upon upload, will encrypt a document. There is also the option within a pre-exisiting document library to enable the cryptographic feature of CryptoCollaboration, in order to encrypt document on a point-to-point basis.
There are several classes that build the CryptoCollaboration solution. In order to handle the events that happen with the cryptographic events in SharePoint, there is a class builds up an encryption factory inheriting from the System.EventArgs base class. This is an important class to CryptoCollaboration because inheriting from System.EventArgs is because it allows the creation of generic handling, and is a convenient option to use for future expansion of further events (such as string encryption with lists). The ExtendInfo property that returns an object also allows for a certain level of customization, which is important for my current circumstances. Of course, the status of the encryption calls into this class in order to gather the status of the encryption process by use of a delegate.

In order to handle exceptions that occur within CryptoCollabortion, there are several class that inherit from the ApplicationException base class. Such as exceptions as invalid file input / out and password length follow this convention. The reasons why I love to handle exceptions this way is explained in this post.

The main encryption processing is handled with the CryptoCollaboration main component class. The main component class is the real worker bee of the entire encryption process sinking that happens through the entire process. This class contains the Encrypt() and Decrypt() methods, as well as intializing the relevant encryption algorithms out of the System.Security.Cryptography namespace. Out of the same namespace, within the same class, the relevant hashing functionality is called. All of the relevant property validation is also handled within this class.

All of this is pretty high level, and the entire solution is constantly being developed against. I am sure some of it will change when it is actually released, and since it will be open-source, will make a lot more sense when it is released.

I am making good progress on it (the CAPTCHA Field Control is taking some of my time) and it should be out relatively soon.