couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Castonguay <danny.castong...@gmail.com>
Subject Re: Question about validator functions and replication
Date Tue, 29 Mar 2011 19:14:32 GMT
I'm not a cryptographer. But here's a scheme which makes sense to me.
I don't know what the right notation is, so please bare with me. By
"Dc" I mean "private key of Centralized server" and by "Epi" I mean
"public key of Participant i". Also please note that I may be stating
the obvious!

Centralized server owns its own private key (Dc) and sends the public
key (Ec) to all the participants. Each participant owns its private
key (Dpi) and sends the public key to the centralized server (Epi). So
each participant owns needs two keys: Ec and Dpi. The server on the
other hand owns n+1 keys: {Epi} and Dc (where the set {i} contains n
participants)
When a participant i wants to access data from the centralized
(presumably couchDB!) server, she uses her private key (Dpi) to sign
her identity (some message like "hi this is Alice trying to contact
you Mr. Red Couch, on 2011-Mar-28 at 18h28 and the hash of this file I
just sent you is XXX"). The server then uses the public key of
participant i (Epi) to decrypt the message and confirm the identity of
participant i. The server then validates that participant i is allowed
access to this data, performs some couchDB map reduce function, and
encrypts the resulting data using Epi. Participant i then receives
this data over the wire, decrypts it using Dpi, and stores it on her
local couchDB.

(Later on) participant i changes some data on her local copy of
couchDB. She then replicates it back to the centralized server using a
similar operation. First, (as before) she validates her identify using
Dpi. But then she uses Ec to encrypt the data and send it to the
centralized server. The centralized server finally uses Dc to decrypt
the data and store it in couchDB.

What I have just described might just be https (TLS) wrapped around
completely unencrypted couchDB instances (n+1 instances). Is that the
case? Has anyone accomplished this?

Thank you for reading and thank for your help.
Danny


On Tue, Mar 29, 2011 at 10:41 AM, Robert Newson <robert.newson@gmail.com> wrote:
>
> so presumably this just uses couchdb us a dumb store, since you won't
> be able to compute views over this data?
>
> B.
>
> On 29 March 2011 14:19, Nebu Pookins <nebupookins@gmail.com> wrote:
> > On Tue, Mar 29, 2011 at 8:54 AM, Robert Newson <robert.newson@gmail.com> wrote:
> >> You can get read access control by separating each users documents
> >> into a separate database.
> >
> > This solution gets tricky if there are "shared" documents, though.
> > You'd basically need one database for each possible grouping of users.
> > I.e. with N users, you'd need 2^N databases.
> >
> >> I'm curious to know where you store the encryption keys such that no
> >> user can access the key of another user. Whatever you did to solve
> >> that would seem to be sufficient to prevent the access you were
> >> concerned about in the first place. Presumably there's also a
> >> different key per user?
> >
> > You basically need to use public key encryption. Each user has their
> > private key which they keep secret, and the public keys are accessible
> > to everyone and probably stored in the DB itself (so that the DB
> > software can also generate documents encrypted towards specific sets
> > of users).
> >
> > - Nebu
> >



--


dannycastonguay
US: 828.656.1212
Canada: 514.649.8954

Mime
View raw message