Dependent dbs

[calvinmetcalf]

When an index is created the new dependent db won't have the transform, E.g.if you use crypto pouch your query index is not encrypted

[nolanlawson]

Yeah, that's a good point. If we encrypt it, though, then the index is almost useless because you can't iterate it (assuming we encrypt the keys).

The only case where I think this may make sense would be to encrypt the values but NOT the keys, but then we'd need to trust the user to know that their keys will be unencrypted. Else we could let them encrypt the keys, but with the knowledge that their keys won't be ordered anymore.

Personally I've never used values much, so for me I would just make an index on a key that doesn't need to be encrypted and then use include_docs: true when I read from it.

[calvinmetcalf]

That is a good point, currently crypto pouch does only encrypt values not
keys, I might end up having to do something weird like make a memdown
pouch, serialize it and encrypt that.

On Mon, Mar 23, 2015, 8:42 AM Nolan Lawson notifications@github.com wrote:

Yeah, that's a good point. If we encrypt it, though, then the index is
almost useless because you can't iterate it (assuming we encrypt the keys).

The only case where I think this may make sense would be to encrypt the
values but NOT the keys, but then we'd need to trust the user to know that
their keys will be unencrypted. Else we could let them encrypt the keys,
but with the knowledge that their keys won't be ordered anymore.

Personally I've never used values much, so for me I would just make an
index on a key that doesn't need to be encrypted and then use include_docs:
true when I read from it.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[ermouth]

cloudwall.me implements encryption of underlying Pouch docs as per-doc option. Approach I used was:

• user has a list of encryption keys in his profile, key is a pair [keyName, keyValue] and can be shared
• to encrypt doc user saves it with property crypto set to keyName
• cloudwall encrypts doc as follows:
  • some properties kept untouched (like _id,_rev,_attachments, type, name, creator, stamp, crypto)
  • all other properties are stripped from the doc
  • new property CRYPTO is created, it‘s base64 SSL-encrypted json of properties stripped
  • attaches are not encrypted (performance considerations)
• cloudwall decrypts doc on read if user has cryptokey installed.

Reason for these complex policy is rather simple – docs in db contain not only data, but some kind of metainfo over data.

So what I want to say – some meta better kept readable for views and end users.

[calvinmetcalf]

So that is roughly how crypto pouch works, the issue is that when used with
dependent dbs the doc ids leak data about the contents of documents in the
parent database

On Mon, Mar 23, 2015, 11:31 AM ermouth notifications@github.com wrote:

cloudwall.me implements encryption of underlying Pouch docs as per-doc
option. Approach I used was:

• user has a list of encryption in his profile, key is a pair
  [keyName, keyValue] and can be shared
• to encrypt doc user saves it with property crypto set to keyName
• cloudwall encrypts doc as follows:
  • some properties kept untouched (like _id,_rev,_attachments, type,
    name, creator, stamp)
  • all other properties are stripped from the doc
  • new property CRYPTO is created, it‘s base64 SSL-encrypted json of
    properties stripped
    • cloudwall decrypts doc on read if user has cryptokey installed.

Reason for these complex policy is rather simple – docs in db contain not
only data, but some kind of metainfo over data.

So what I want to say – some meta better kept readable for views and end
users.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

[nolanlawson]

presumably you could just call whatever transforms you want inside of your map function, no? Maybe less than ideal because it's a potential footgun, but it would definitely work.

[ermouth]

dependent dbs the doc ids leak data about the contents of documents

To avoid leak map fns by default better see ecrypted doc, not decrypted one. There can exist config param, that can allow some views to run over decrypted doc, but as for me default behavior better be compatible with CouchDB – map see data, stored in DB.