I was checking in on plans for the Drupal 8 port. Is this in progress?

If not, I'd like to build one. I'm also happy to maintain it long term with co-maintainership.


Deciphered’s picture

Hi Adam,

As per my response to your email:


Field encrypt isn’t actually one of my modules, it’s just something that I was required to pick up due to the needs of a client, and given the size of my module portfolio I could only prioritise the port if my client where to be looking at a Drupal 8 version.

Additionally, the Field Encrypt module is dependent on the Encrypt module, and wouldn’t warrant a port until the Encrypt module has been ported.

In general I would have no issue providing co-maintainership to this module, but as I said, it isn’t my module, so I would recommend making the request to tedbow or caiovlp, but if you don’t hear anything from them within a respectable amount of time, let me know and I will make the call.

tedbow’s picture

I made you a co-maintainer. I don't really have time right now for this project and I am not using it in any projects.

I switch it from "seeking co-maintainers" now. You can switch it back and respond to requests if you want.


nerdstein’s picture

@tedbow - Thanks! I appreciate it

nerdstein’s picture

Some updates:

Substantial progress has been made in a shared repo.


Dan Montgomery did some substantial legwork here and deserves recognition for his efforts. I'd like to add him in as a co-maintainer if you are OK with it, @tedbow

tedbow’s picture

Yeah, I don't really have an opinion about this project because of lack of time.

I am ok with whatever anybody who is a current maintainer wants to do as far as adding new maintainers, whatever.

nerdstein’s picture

Awesome, thanks. I'll take care of it

adaddinsane’s picture

Hi @nerdstein

As the original writer on field_encrypt I'm happy for someone to take on the D8 conversion, and looks like it's going to be critical with new legislation saying that all personal data must be encrypted (because it's impossible to prevent hacking).

I've given this some thought and I don't think the field approach is logical for D8, but I'm open to negotiation. (At least we won't have to worry about broken-but-popular modules like profile2 and webform.)

Hitting the system at the DB field layer seems the simplest (encrypt everything) but I can see some people would still prefer the original approach. Maybe it's two modules.

pandaeskimo’s picture

Hello, this is Dan.

The progress on field_encrypt stalled along with changes to the encrypt module. I'd be happy to get feedback on the work and not upset if it gets tossed. I learned a lot. At the high level, the work I did provides processing of fields based on pluggable mappings. The actual encryption system is easy to swap out and that's what was changing in the encrypt module.

Moving forward, it looks like there aren't many people currently available to work on this module. Hopefully this leaves a trail to the github project and someone can pick up there if it makes sense.

nerdstein’s picture

Encrypt is close to being released and I'm happy to pick up where Dan left off. It might not be immediate.

Slurpee’s picture

@nerdstein, did you pick up where Dan left off? Are you interested in mentoring a Google Summer of Code student this summer for this project? Maybe you can work together making the module more robust than ever?

colan’s picture

Speaking of GSOC, I've got an idea.

The problem with Encrypt as a crypto API module, as of when I lasted looked at it, is that it's not very secure. It stores the keys on the server which is like "storing the keys to your house under your Welcome mat".

I propose that we work towards a better security model, one in which secrets are not stored anywhere on the server. We already have such secrets anyway, user passwords. We simply need to use them to manage encrypted assets. What I'm proposing is actually ownCloud’s Data Encryption 2.0 Model. Let's get this done in Drupal, ideally for both field data and files.

To start, we'd need an API module that provides the encryption engine, key storage and CRUD. Then, modules such as this one (for field data) and one for files could make use of it.

So I'm thinking we could either add this functionality to Encrypt (if it will work with the existing D8 model, and the folks working on it support the endeavour), or build another API module for D8. This should work well with the new Field Encryption D8 port as "[t]he actual encryption system is easy to swap out" as per #8.

Given that ownCloud already has this up & running, they're a PHP project, and they're open source, we would simply need to take what they're doing (the code), and re-purpose it for Drupal. I think this would make a great GSOC project. I'd be happy to help with project goals and mentoring.


nerdstein’s picture

The issue you noted is actually with the Key module, which is a dependency of the Encrypt module. And, it's not accurate.

Your assumptions about the implementation is not correct - Key has two plugin systems that allows for any type of integration of Key storage. We do have a "configuration" key storage plugin, which is of low security (key values can be stored and exported as CMI), but we make it clear of the potential security risks. CMI itself is usually protected and wouldn't actually be exposed in the manner you suggest. To make one point explicit: we do not store Keys/key values from the Encrypt API.

We have many other preferred Key storage plugins already available to store a key within the filesystem of the server (outside of the docroot ideally) and another one that integrates with an external Key service (lockr concept).

I strongly recommend you evaluate the architecture of the Encrypt and Key plugins. I think the time would be best spent evaluating how to leverage these APIs to come up with a sound strategy for Field Encrypt. I'm not overly confident that Field Encrypt will need to be prescriptive of the actual encryption method configuration, as long as it sets one and effectively encrypt/decrypts field values.

The respective field_encrypt and file_encrypt would invoke the configured encryption methods (using the Encryption services) within the respective hooks (field CRUD for field_encrypt and file CRUD for file_encrypt).

nerdstein’s picture

We are quite close to our first Encrypt alpha release, found here:


This would be a stability marker for us to proceed on field_encrypt (which I am still planning to be heavily involved with).

Any progress to help get some analysis started toward the aforementioned goal would be great. And, any development contributions thereafter would be awesome. We will probably leverage GitHub for the collaborative aspects of Pull Requests.

rlhawk’s picture

Encrypt has supported a pluggable system for key storage since 7.x-2.0 and, as nerdstein mentioned, the key management functionality is migrating out of Encrypt into its own module. There are already some implementations of off-site key storage and encryption: Townsend Security Key Connection and Lockr.

A module that integrates ownCloud with the Key and Encrypt APIs would be welcome.

colan’s picture

Thanks for the above info! I was basing what I wrote earlier (#11) on the project page, but it looks like I read it too quickly. Although there is text such as,

By default, this module uses a key that is stored in your database while the main use of this module is to store encrypted data in the database. This is actually just an example of obfuscation because if the database itself is compromised all the necessary parts are available to retrieve that data (even if it requires more effort to do that).

...there are warning messages about this. But perhaps the page can be reworded to emphasize the possibility of using off-site key storage.

So you folks recommend a separate module for the ownCloud model? This would make more sense architecturally than including this feature in existing ones (Encypt and/or Key)? Maintainer feedback on this would be greatly appreciated.

Deciphered’s picture

@colan, just in case it's not 100% obvious, the recommendation would be to make an 'ownCloud Encrypt' module that simply provided the CTools key provider plugin (in D7, assuming native in D8) for use of the Encrypt module.

I agree there should be better education on security, but that's not limited to this module and there's only so far it can be taken. Maybe a link to an external location that can go into depth? Personally having taken over a clients site where they stored the key in the database itself, I fully agree that it should probably be made clearer, but the problem isn't necessarily with this module.

I would however recommend that this discussion moves into it's own issue as it's not necessarily relevant to the porting of this module to D8.

colan’s picture

Sorry about hijacking the thread! The last thing I'll mention, that is on-topic, is that I've included this issue (porting Field Encryption to Drupal 8) in the list of goals for the GSOC project I posted, Add password-based public-key encryption to Drupal 8. Feel free to edit there if anything was missed, needs correction or will get done before then. Thanks to everyone for helping me get this plan solidified.

colan’s picture

Five months later, I think we can publish a D8 pre-release of Field Encryption as soon as #2764851: Fix tests round 2 gets committed.

nerdstein’s picture

Status: Active » Fixed

Doing some grooming and marking this issue as "fixed" as we pushed a release

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.