Encryption option in library?

Howdy all,

Are there plans to add an option in remoteStorage.js to encrypt data before sending it to server? Or would it have to sit as another layer on top of remoteStorage?

Thanks!

Yes, we discussed solutions for this a while ago, and weā€™d like to add it at some point.

Want to help?

@silverbucket Wanna look at this again and hack on this with me during Hacker Beach?

@raucao absolutely!

@silverbucket and @raucao, have you had the chance to work on this?

Could you provide a little status quo of this question?
Donā€™t we already support HTTPS/SPDY so every connection is already encrypted?

Which additional way of solving the data privacy issue were you thinking of, @diafygi?

Only questions.

Encrypting the transport is the absolute minimum, but for critical data like e.g. credentials, you might want to encrypt the data itself as well.

Good. What kind of key exchange / storage encryption implementation / workflow ideas are already around?

The idea is to ask the user to optionally encrypt their data after connecting their storage. Then you either enter a password (first time or the one you used before) or you donā€™t. The password would be kept in memory during the session, and as soon as you reload or revisit the app, youā€™d have to enter it again.

So some kind of encrypted storage container like BoxCryptor or TrueCrypt (in some configurations). Nice; why not.

No, itā€™s not a container. Every piece of data would be encrypted and decrypted on demand all the time.

I agree with @raucao that client-side encryption would be really important to me if Iā€™m using a commercial server like 5apps instead of hosting my own server.

ā€¦ at least when it comes to credentials is what I meant. I donā€™t think Iā€™d want to enter my password every time I open an app with uncritical data.

2 Likes

We can encrypt only part of file tree, for example encrypt /user/notes/secrets/* and donā€™t touch /user/articles/*. So until you decided to read/change your secret notes you donā€™t need to enter password.

Itā€™s also possible to ask for passwords only for some files with specific extensions, for example /user/notes/ids.gpg.

All major browsers vendors work on implementing WebCrypto standard now. It will provide to Javascript access to first-class random generator and basic cryptography methods. In the meantime we can use a WebCrypto polyfill.

@dogada the file extension is a a possibility, though Iā€™m not sure if thatā€™s a good long-term solution as it could cause issues. Also, we donā€™t normally store anything with extensions, the modules themselves decide on naming patters, and usually with advanced usage there are more complicated indexing going on to ensure speed and organization of large amounts of data (at least, thatā€™s the goal).

Itā€™s been on my roadmap for the past couple months to do this (implement a way to encrypt data, and retrieve it easily via. the widget), even just to prototype it, but Iā€™ve been pretty busy lately with other things. I hope to get to this soon.

Currently remoteStorage is kind of backed-up with some large changes coming down the pipes, so Iā€™ve been delaying working on this until the dust settles.

If you are interested in helping out, perhaps we could talk this over more (@raucao as well).

As I said, Iā€™d propose to do something like a crypto hack day, where we could remotely pair on prototyping the whole feature in order to see if our ideas would work and gather feedback on it. How about putting up a Doodle for a date?

This is crucial IMO, Iā€™m very interested in getting this done.

How can I help?

Howdy all, Iā€™ve been working on a side project that implements encryption into an unhosted-style library (https://github.com/diafygi/byoFS). Itā€™s still super alpha, but itā€™s been fun so far. Thereā€™s some trade offs in order to provide client-side encryption, and Iā€™m not sure if it would be compatible for the remoteStorage spec.

The biggest tradeoff: Iā€™m only allowing direct key lookups for reads and writes, since the remote server stores only hashed filenames. This prevents listing all the files or searching for a filename in a remote server since the hash is one way. For the byoFS demos, they use a known ā€œindexā€ filename to keep track of all the other filenames, so inserting or changing a filename actually requires updating the index file, too (e.g. two writes on the remote server).

If remoteStorage didnā€™t want to make that tradeoff, it could keep the filenames unhashed in order to allow listing filenames. I chose not to make that tradeoff and force the app developer to manage their own filenames.

Alternatively, you could encrypt (instead of hash) the filenames and then decrypt when listing files. However, that would mean any filename search beyond a straight key lookup would require downloading the entire list of files and decrypting them all to see if they match the search. Nowhere near ideal, but possible.

2 Likes

For what itā€™s worth, I also use encrypted credentials storage in https://meute.5apps.com/. It still needs error handling added, but as long as you donā€™t mistype your master password, it works.

Oh, and my plan is to submit this upstream, of course. See also Working on a social library on top of remotestorage.js

Well, I see 2 main use cases for encryption support:

  1. Provide encrypt/decrypt routines for explicit encryption/decryption.
  2. Allow to to enter master password once and then implicitly decrypt data on read and encrypt them on write.

First use case is simple. We just need to add encryption support based on proven standards (WebCrypto?) to allow application developers to call RemoteStorage.encrypt(data, secret) and RemoteStorage.decrypt(data, secret). To use it developer will only need to implement an UI callback that will ask for password.

Second use case will need some way to detect should an object be encrypted/ decrypted? I agree that extension isnā€™t good idea and probably better idea is to use RemoteStorage.defineModule. For example if an module defines preSave and ā€˜postReadā€™ in own exports RemoteStorage can call these functions immediately after read and before save to the underlying datastorte. Encryption/decryption (and any other pre- and post-processing) can be done inside these functions. Functions accepts raw objects, analyse it, change if required and return original or modified copy. What do you think about this approach?

We also will need a default way to ask user for master password (it can be just trivial window.prompt. Application developer can customize this prompt also on module level defining in exports callback with name like passwordPrompt. Once we obtain master password from user, we can derive real password with a standard function like PKDF2 and use it for actual encryption/decryption with AES256 as chipper. So user will enter master password only once and we will use it until session expire or an timeout. We can discard master password immediately after generating of derived password and keep it private in memory only.

We even can have option to use own master password for each module, this
will lead to better security but weaker UX probably.

Yeah, Iā€™m interested in it. If we all agree desired solution and requirements to it, I can implement it.