Hook for decrypting incoming data during replication

[Alan McKean]

What would be the best strategy for grabbing each incoming document during replication? It is encrypted on the remote server CouchDB and I need to decrypt it and store it unencrypted locally in my app.

[Jens Alfke]

On Feb 11, 2014, at 1:13 PM, Alan McKean <alanm...@me.com> wrote:

What would be the best strategy for grabbing each incoming document during replication? It is encrypted on the remote server CouchDB and I need to decrypt it and store it unencrypted locally in my app.

This has been discussed a few times (and filed as an issue back in the TouchDB days) but there's no implementation yet.

How are you encrypting the data? I.e. what's the schema of the encrypted form like?

—Jens

[Alan McKean]

I am encrypting with the iOS encryption. My documents have a single ‘data’ property that is an encrypted string. Without a hook for decrypting, I will have to either decrypt during views or run through the entire db looking for unencrypted data at launch.

--
You received this message because you are subscribed to a topic in the Google Groups "Couchbase Mobile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mobile-couchbase/ArwoOEd1Me0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/A528E56B-7D91-427C-8B73-A7F1EDA9B39E%40couchbase.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jens Alfke]

On Feb 11, 2014, at 9:32 PM, Alan McKean <alanm...@me.com> wrote:

I am encrypting with the iOS encryption.

What algorithm? And where does the key come from? (I'm just curious.)

How did the encrypted documents get into CouchDB — were they replicated from another database?

My documents have a single ‘data’ property that is an encrypted string. Without a hook for decrypting, I will have to either decrypt during views or run through the entire db looking for unencrypted data at launch.

The issue I linked to earlier describes some of the things I'm unsure about with this approach, like what the revision ID should be. If you'd like to work on adding such a hook, I can give you some advice on where to start.

—Jens

[Alan McKean]

I'm using AES 128 encryption. The key is generated on my Node.js server when the user registers to use the app. When I save the document I encrypt the entire document except for the _id, _rev and type properties. All encrypted data is in a 'data' property. That way I can query them and decrypt (or not if the 'data' property is absent). Not all document types are encrypted. Just the secret stuff. Patient, Claim, Session documents. The encryption key goes in their keychain and I STRONGLY encourage users to backup their keychain to iCloud. (It's in the license agreement and outlines the very bad things that will happen if they lose their encryption key). I struggled with this as a business decision and finally decided I could not safely/economically keep track of the encryption keys. User beware.

Realting to the earlier problem of managing the _rev properties ... I have given up on the previous approach of downloading data via Node and updating the documents with my downloader. I am about half way through on a branch that uses CBL replication directly from the CouchDB server. Problem solved if it works well and it looks like it will. Gets rid of a lot of networking and offline management code.

[Jens Alfke]

On Feb 12, 2014, at 4:28 PM, Alan McKean <alanm...@me.com> wrote:

I'm using AES 128 encryption. The key is generated on my Node.js server when the user registers to use the app.

…

I struggled with this as a business decision and finally decided I could not safely/economically keep track of the encryption keys. User beware.

It sounds like the encryption/decryption is done only by the client, and the server is simply passive storage of the encrypted documents?

But in that case, why create the encryption key on the server? By doing that, you're no longer provably unable to read clients' documents. If you changed the system to generate the key on the client (after all it's simply generating a 128-bit random number) you could make better privacy guarantees.

Other than that, the system seems sound.

—Jens

[Alan McKean]

You are so right. I generated the key on the server when I was investigating a secure means of storing the encryption keys. This was before I decided to not keep track of them. I couldn't find a cheap means of securing them. I investigated Gazzang but they were outside my budget. t intend to generate the key on the client before going to production.