To implement a zero-knowledge system, it would be great if this module could support client-side encryption.

There's a JavaScript framework for this called Crypton that supports this. Perhaps we could take advantage of it?

This was originally discussed on Drupal Answers.

Comments

colan created an issue. See original summary.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented
Project: Field Encryption » Encrypt
Version: 7.x-1.x-dev » 8.x-3.x-dev

Moving to a better queue...

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles at CARD.com commented

Here's my understanding of the proposed solution: encryption happens on the browser side by adding a js library and encrypting the field before sending it to the server. Server-side it's just a single string of text to store.

If that's the case, I feel like it mostly deserves to be its own module separate from the encrypt module. At least so far, the encrypt module is focused on key management and keeping track of what encryption method was used on which string and then being able to get the right key and use the right settings to decrypt a string. The encrypt.module doesn't add any javascript nor does it store encrypted data - it's just an api with UI for configuring the API.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

Yes, that's how I see it as well. I was just wondering if the maintainers thought it would be worthwhile to include both types of encryption (server and client) in the same module. We could have one encryption module to rule them all, so to speak.

If we want to keep these implementations separate, I suppose we could have a new module named "Client-Side Encryption", and then rename this one to "Server-Side Encryption" or some such. It would help reduce confusion.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles at CARD.com commented

If you're open to maintaining it inside this project I could see adding it here. I'm just not sure there's much overlap beyond the name.

Not sure what the other encrypt maintainers think - perhaps they can add their thoughts.

rlhawk’s picture

rlhawk
Primary language English
Location Seattle, Washington, United States
CreditAttribution: rlhawk commented

I'm all for having as many ways to encrypt and decrypt data as possible, so adding client-side functionality sounds great to me. If it's possible to integrate the client-side options to the Encrypt API, without providing a specific encryption method, we should include the integration. A separate, contributed module could then provide support for Crypton as an encryption method.

ksevta’s picture

ksevta CreditAttribution: ksevta as a volunteer commented

This requirement can be fulfill with password-based public-key encryption which uses ownCloud’s Data Encryption 2.0 Model. There is a advance security method available which enables client-side encryption so i think we can use this.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

@ksevta: Actually, no. That's my GSOC idea there, and it's server-side as the encryption/decryption is done on the server. For a method to be client-side, the data must be encrypted on the client, before it gets to the server. So the server never sees any unencrypted data.

But maybe we could propose this as a project idea for next year's GSOC?

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

But maybe we could propose this as a project idea for next year's GSOC?

Done! Please help me add details at https://groups.drupal.org/node/515848#project1.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

One issue that the students brought up is which credential to use. I don't believe we can use the user's login password like we did in Pubkey Encrypt because we don't want to trust the server, and the user's password gets sent there.

Some options:

  • Alter Drupal core's password handling to be zero knowledge. In other words, don't send a password for authentication.
  • Use another login mechanism like Certificate Login. (I'll be working on the Drupal 8 version shortly.)
  • Allow for additional credential types to be used for encryption instead of the login credential, something like the user's GPG key.

Maybe we could provide a plug-in system with whichever (or more) options? I'd like to see at least one of the above in whichever module/solution we produce.

Thoughts and ideas welcome, and please correct me if I'm missing anything.

marncz’s picture

marncz CreditAttribution: marncz commented

@colan you concern being that passwords are hashed server side? and server would know passwords in plaintext?

One possibility is for users to create another passcode / password when registering that would encrypt RSA's private key with symmetric AES-256. Keys generation would happen client side (both RSA pair and AES encryption) so server would know the passwords used for encryption at all.

Another security mechanism would be "scrambling" keys array for each encrypted data => working on hashes will decrease assigning of user => key by an attacker.

For better security password may be entered every time that encrypted data is accessed (JavaScript prompt), this way the passhprase is not stored on the client (e.g. localStorage, cookies). That would also decrease harm of possible mitm / code injection attacks. May use another auth mechanism already existing in Drupal, I think that's a good idea to keep user passwords and encryption passwords separate.

On security of web client-side encryption: http://www.cs.tufts.edu/comp/116/archive/fall2015/mseltzer.pdf

Can share my design document upon request.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

I've got a wrap-up of this year's related GSOC projects over at Client-side encryption options now available in Drupal, but the short version is that we now have two contrib modules that support this: