If you’ve missed it there is great article entitled Keep it secret, keep it safe by Eric Lippert. Essentially it attempts to dissect the essence of typical crypto issues in plain English (i.e. crypto for dummies). He did a great job of explaining the difficulties in key management, worth a read.

I found it particularly interesting that he brought up this topic since just days ago I released a “SecureTransfer” class. I’ll get more into the details of that later, but it is interesting here because it happens to be very susceptible to the very issue he warns about. To put the problem in simple terms:

The best implementations of cryptography out there are only as secure as their key storage.

This is most certainly true for the SecureTransfer client/server classes. That doesn’t mean that implementing a secure communication channel is easy. Far from it. It just means that *if* you’ve implemented a secure channel it’s most obvious attack vector is to crack the key store.

Key storage for HttpClone

This very problem was one of the first things I had to address with HttpClone (which is now serving this website). To publish content from my local machine over HTTP I needed to know the server’s public key, and the server needs to know my local public key. In addition both client and server also have to store their own private keys.

So I asked myself what kind of assurances do I want regarding key security for HttpClone? It turns out that simply placing the keys in the web server’s /bin directory is probably all that is required. I mean to say if they can modify files on my web server’s bin directory the game is already lost. They can freely change the assemblies, web.config, etc and serve up any malicious content they want.

In the end I chose to allow an added a level of password security to the private key file and then store that password elsewhere. Why? Well you only need to remember back to last year at this time when Microsoft released this annoucement: “Important: ASP.NET Security Vulnerability“. One of the possible gains from this attack was being able to read any file in the web directory (web.config included). Due to this and the potential of a co-hosted site not running ASP.NET being hacked I thought adding the extra layer was worthwhile.

For HttpClone’s purposes it’s still not necessary to further protect the server’s private key. This is due in part to the fact that the data being sent (a copy of a public website) is not private and does not need to be secure. In fact the only reason for involving cryptography at all is for authorization not privacy.


Yes this site is still using wordpress, in fact, I’m writing this in wordpress right now.  The interesting thing is I’ve completely uninstalled wordpress and MySql from my production server.  I know crazy huh?

So if I’ve peaked your curiosity you’ll want to stay tuned.  Right now I don’t have time for a lot of details, but what I can tell you is this:

  • Search still works
  • RSS still works
  • Postback still works
  • All the wordpress admin goodies still work

How?  Well I’m using a new project I started called HttpClone to create a snap-shot of the site.  From there I can pretty much do anything i want to it, including:

  • Rename it to a different domain
  • Add, edit, or remove content
  • Remove and insert html tags
  • Index the content with Lucene.Net
  • View, modify, validate and track down links

Once I’m happy with the changes being made I run a publish command and presto-changeo it’s live!

The project is definately still ‘Alpha’ material but the server-side of things should be solid enough for most uses. I’ve actually been running this site on early versions for two weeks now without issue. In the bargain the site should be around 3x-5x faster than when wordpress was serving the content directly.


A very minor update to the library this past weekend.

  • Addition of Cyrpto.SecureTransfer to provide file transfers via shared public keys.
  • The Crypto.AESCryptoKey now has ToArray() and FromBytes() like other keys.
  • HashStream can now aggregate read/write calls to actual storage stream while computing the hash.
  • The Crypto.Hash class received a new method, Combine(…)
  • Html.XmlLightElement and related classes are now fully modifiable.
  • BPlusTree.Options now supports a ReadOnly property to ensure no writes at the file handle level.