The problem with most encryption strategies nowadays is that they require third-party software and/or services, require maintenance of additional keys and/or secrets, and provide an awful user experience.

Earlier this year, I started wondering why we couldn’t simply encrypt data with pre-existing secrets, the passwords users already have for logging into their Drupal sites. They shouldn’t have to deal with public and private keys and other cryptographic details. So I did some research, and was happy to discover that the security model is already in existence. The folks at ownCloud have not only published it (Data Encryption Model 1.1 and 2.2); they’ve already implemented it in their product. What’s even better is that the product is also written in PHP like Drupal, and has an open-source license. So the ideas and code can be reused.

Not too long after I made this discovery, the Drupal community was looking for project ideas for Google’s Summer of Code (GSOC). So I added mine to the list. There were several students interested in the topic, and wrote proposals to match. Talha Paracha’s excellent proposal was accepted, and he began in earnest. With Adam Bergstein (nerdstein) and I mentoring him, Talha successfully worked though all phases of the project. For details, please see his blog posts.

Now that GSOC 2016 has come to a close, we have a full project release for the Pubkey Encrypt module. It’s currently in beta, awaiting community review before we publish a production-ready version. We’ve included an architecture document, user stories, and usage documentation. There’s also a video! Please take the time to experiment with the module, and create tickets for any issues that you find.

At the time of this writing, only field data can be encrypted via the Field Encryption module. The File Encryption module is still in development, but as soon as it’s released, it should work with Pubkey Encrypt as well.