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!

Share

Ok, Seriously. CryptoCollaboration V4 Is Released

Yeah, so I kinda of missed my target dates for revision 0.0.0.4, but it was for a good purpose. I stepped back and added the need exception handling within the interface, and cleaned a lot of the unnecessary garbage code up. The file encryption should be working pretty good now with reasonable speed depending on document content length and file format.

You can download the release here.

Share

CryptoCollaboration Version 0.0.0.4 (New) Being Released

* THIS WILL BE RELEASED MARCH 26, 6:00 p.m. PST *

**For more information regarding this project, releases (both past and current), and screen-shot diaries of CryptoCollaboration in action, please visit:

http://www.codeplex.com/CryptoCollaboration ** 

Yeah I know, quick turn around considering the traditional life cycle regarding software revisions, but I have received some great feedback since the initial release, some of it enhancement requests similar to plans that I had in the beginning. As any developer knows when you get the request for something that you really were excited to write into the next revision, it is really encouraging to get those requests in, finish them, and get them tested by the greater community.Anyways, there have been some big changes in the software, some of it not noticeable however a lot of it is pretty easy to spot.

The largest changes you will see functionality are:

1) Support for File Encryption

Yup, I had the time to adjust the code in order to support this since it was the largest request. Now, as opposed to just encrypting native field data out of orthodox SharePoint lists, you can encrypt contents as they appear in documents. In the next revision, this will extended in order to encrypt attachments on list items once the file encryption methods have been tested enough so I am comfortable reusing said methods. This has been tested with standard text documents (those made out of NotePad), as well as Microsoft Word documents (which for the record was a pain in the ass). I haven’t really pushed the size limits on it, but it should support relatively large documents.

2) Code Cleanup

This was targeted to reduce the size of the shared sister assemblies in the overall deployment package. If you do a file comparison between the two, you will notice that the package is about half the size. I also used some Xenocode components in order to compress the shared sister assemblies which further reduced the size of the elements.

3) Encryption Performance

Some of the encryption routines had some new threading introduction in order to support faster operations on data. Although I was unable to get empirical, tangible metrics regarding the differences between the revisions however the performance is noticeable directly in within the interface so is comparable.

4) More Reliable Trimming Of Interface Elements

Per some feedback, there were some malformed elements being returned within the interface that is usually conditionally queried and displayed. These errors were corrected and now the interface should be relatively consistent as far as functionality-trimming is concerned. This should reduce the user confusion that might normally be experienced through the CryptoCollaboration operations interface.

5) Exception Handling Additions

I have made the initial changes in order to support more robust exception handling, however it is still somewhat lacking for what I normally endorse. There were some very specific exception handling classes developed, some as for validation of encryption keys and initialization vectors; however they are not 100% due to time constraints and priorities for the current revision. I still have to go through and add more exception handling to be 100%, which I might use log4net for, but I am leaning towards just writing a some simple custom classes for since the product is pretty specific in its purpose.

Share