Who would benefit from a TrueCrypt API?

On my drive back from the client to my hotel, I was thinking. Wouldn’t it be cool if Seafile could synchronize to encrypted containers? From there I started thinking about what would be required to pull this off. Firstly, you would have to extend Seafile to support an attribute that lets Seafile know if the storage location was available or not, and then you would have to have something that could manage the encrypted container.

This led me to another idea: giving TrueCrypt an API. At the moment, version 7.1A, it does not provide an API to do so. However, it does provide an interface (GUI for Windows, and CLI+GUI for Linux) and a system level driver. If we were able to extend TrueCrypt to accept commands via an API just consider the possibilities:

  1. Other applications would be able to securely store your files
  2. Seafilecould download and synchronize to a secure location
  3. Shell extensions could be written for file managers to package folders into TrueCrypt encrypted files.

Ok, that isn’t as impressive of a list as I thought it would be. However, I am confident that there are more use cases out there.

There is a current attempt to do just this. It is by nightnic, however it only targets the Windows platform. One of the bigger hindrances of making your own API for TrueCrypt is that the source isn’t very extendable. For a user to include the API custom support, he or she would have to compile the source and patch in the API source. Additionally, from the looks of it TrueCrypt has a legal document in front of the source that may scare away those who wish to extend TrueCrypt.