Front page

multi-client, encryption, deduplication

8b1766c0db1b46ba81dca80bd8ebe56d
OBTUSE BOOKSELLER FRAMEWORK

From: obnamsupport <obnamsupport@infopower.nl>
Date: Fri, 1 Apr 2016 23:30:37 +0000

   Hello, I'm currently comparing duplicity and obnam and trying to decide
   which one to use to safely back up various (virtual) machines with some
   same data on various VMs.
   
   So the requirements are:
   -multi-client
   -deduplication
   -encryption
   and obnam seems to offer all three of them, while it seems that
   duplicity would need some deliberate hack in order to separate the data
   of the VMs (different /home/VM directories for each VM).
   
   Now I was wondering whether or not all clients need the same key in
   order to makes this possible. 
   
   The whole idea of using various VMs (Qubes-OS in fact) was to obtain
   security by isolation, albeit not strictly physical isolation, so when
   one VM is compromised by an attack, the others are still 'safe' and
   only _some_ data is 'given away'.
   Using one key for obnam, correct me if I'm wrong but probably needed
   for deduplication across various clients, would reduce the safety of
   the data because one successful attack on one VM could reveal the
   private key of all of them.
   
   Am I seeing this correctly? Is there a solution?
   
   
   Thanks,
   
   joe
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Lars Wirzenius <liw@liw.fi>
Date: Sat, 2 Apr 2016 18:40:06 +0300

   On Fri, Apr 01, 2016 at 11:30:37PM +0000, obnamsupport wrote:
   > Now I was wondering whether or not all clients need the same key in
   > order to makes this possible. 
   
   Each client can have its own key, and de-duplication will work anyway
   with in the same repository. However, if a client's key leaks, it can
   be used to retrieve any "chunk" data from the backup repository,
   though not the per-client metadata (filenames, etc).
   
   If you want to avoid that problem caused by a leaked key, you'll have
   to use a separate repository (accessed with separate ssh keys), and
   forego de-duplication.
From: obnamsupport <obnamsupport@infopower.nl>
Date: Sat, 2 Apr 2016 21:08:40 +0000

   Tanks!
   
   
   joe
   
   
   
   On Sat, 2 Apr 2016 18:40:06 +0300
   Lars Wirzenius <liw@liw.fi> wrote:
   
   > On Fri, Apr 01, 2016 at 11:30:37PM +0000, obnamsupport wrote:
   > > Now I was wondering whether or not all clients need the same key in
   > > order to makes this possible. 
   > 
   > Each client can have its own key, and de-duplication will work anyway
   > with in the same repository. However, if a client's key leaks, it can
   > be used to retrieve any "chunk" data from the backup repository,
   > though not the per-client metadata (filenames, etc).
   > 
   > If you want to avoid that problem caused by a leaked key, you'll have
   > to use a separate repository (accessed with separate ssh keys), and
   > forego de-duplication.
   > 
   
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: obnamsupport <obnamsupport@infopower.nl>
Date: Sun, 3 Apr 2016 14:50:33 +0000

   Hi, allow me to come back with one more question.
   From the manual I read:
   
   <quote>
   Obnam will automatically encrypt all the files it writes to the
   backup repository, and de-crypt them when needed. As long as you only
   have one encryption key for each client, and don’t add additional keys,
   Obnam will take care of adding the right keys to the right places
   automatically.
   </quote>
   
   But what I don't understand is what key it uses to encrypt the chunks.
   My understanding was that this key should be such that each client can
   use their own key to decrypt the chunks, but then how can I add a
   client later that will still be able to read all chunks?
   My gut says it can only read the chunks encrypted after this client got
   added to the client list of the repository (and obnam's 'chunk key'
   adapted accordingly).
   
   If I'm right about that, then another question is: how can I let obnam
   know (add all clients to the client list) all clients before starting
   encrypting the first chunks?
   Well, ok, a work-around would be to first backup a small insignificant
   file with each client before starting 'the real work'.
   
   me confused a little
   
   
   joe
   
   
   
   
   On Sat, 2 Apr 2016 18:40:06 +0300
   Lars Wirzenius <liw@liw.fi> wrote:
   
   > On Fri, Apr 01, 2016 at 11:30:37PM +0000, obnamsupport wrote:
   > > Now I was wondering whether or not all clients need the same key in
   > > order to makes this possible. 
   > 
   > Each client can have its own key, and de-duplication will work anyway
   > with in the same repository. However, if a client's key leaks, it can
   > be used to retrieve any "chunk" data from the backup repository,
   > though not the per-client metadata (filenames, etc).
   > 
   > If you want to avoid that problem caused by a leaked key, you'll have
   > to use a separate repository (accessed with separate ssh keys), and
   > forego de-duplication.
   > 
   
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: obnamsupport <obnamsupport@infopower.nl>
Date: Sun, 3 Apr 2016 15:34:03 +0000

   By the way (because I didn't think asking about it earlier), does obnam
   (re)store file attributes/ownerships etc.?
   
   Thanks,
   
   joe
   
   
   
   On Sat, 2 Apr 2016 18:40:06 +0300
   Lars Wirzenius <liw@liw.fi> wrote:
   
   > On Fri, Apr 01, 2016 at 11:30:37PM +0000, obnamsupport wrote:
   > > Now I was wondering whether or not all clients need the same key in
   > > order to makes this possible. 
   > 
   > Each client can have its own key, and de-duplication will work anyway
   > with in the same repository. However, if a client's key leaks, it can
   > be used to retrieve any "chunk" data from the backup repository,
   > though not the per-client metadata (filenames, etc).
   > 
   > If you want to avoid that problem caused by a leaked key, you'll have
   > to use a separate repository (accessed with separate ssh keys), and
   > forego de-duplication.
   > 
   
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Lars Kruse <lists@sumpfralle.de>
Date: Sun, 3 Apr 2016 20:39:43 +0200

   Hi,
   
   Am Sun, 3 Apr 2016 14:50:33 +0000
   schrieb obnamsupport <obnamsupport@infopower.nl>:
   
   > [..] 
   > But what I don't understand is what key it uses to encrypt the chunks.
   
   Here is an explanation:
    http://obnam.org/encryption/#index4h2
   
   Summary: everything is symmetrically encrypted with a master key. The master key
   can be decrypted with any of the client keys.
   
   Cheers,
   Lars
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Jan Niggemann <jn@hz6.de>
Date: Sun, 03 Apr 2016 22:55:00 +0200

   Zitat von Lars Kruse <lists@sumpfralle.de>:
   
   > Hi,
   >
   > Am Sun, 3 Apr 2016 14:50:33 +0000
   > schrieb obnamsupport <obnamsupport@infopower.nl>:
   >
   >> [..]
   >> But what I don't understand is what key it uses to encrypt the chunks.
   >
   > Here is an explanation:
   >  http://obnam.org/encryption/#index4h2
   >
   > Summary: everything is symmetrically encrypted with a master key.  
   > The master key
   > can be decrypted with any of the client keys.
   Also, note http://hz6.de/obnam/en/110-encryption
   The per-client directory is encrypted so that only that client can  
   access it. This means that only the client itself can see its  
   generations, and the files in each generation.
   
   The shared directories (client list, chunks) is encrypted so that all  
   clients can use them. This allows clients to share chunks, so that  
   de-duplication works across all clients.
From: obnamsupport <obnamsupport@infopower.nl>
Date: Mon, 4 Apr 2016 05:06:46 +0000

   On Sun, 3 Apr 2016 20:39:43 +0200
   Lars Kruse <lists@sumpfralle.de> wrote:
   
   > Hi,
   > 
   > Am Sun, 3 Apr 2016 14:50:33 +0000
   > schrieb obnamsupport <obnamsupport@infopower.nl>:
   > 
   > > [..] 
   > > But what I don't understand is what key it uses to encrypt the
   > > chunks.
   > 
   > Here is an explanation:
   >  http://obnam.org/encryption/#index4h2
   > 
   > Summary: everything is symmetrically encrypted with a master key. The
   > master key can be decrypted with any of the client keys.
   
   Ok, so does this mean that everytime a client is added, the master
   key's key will have the client key added?
   
   thanks,
   joe
   
   
   > Cheers,
   > Lars
   > 
   > _______________________________________________
   > obnam-support mailing list
   > obnam-support@obnam.org
   > http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
   
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Lars Kruse <lists@sumpfralle.de>
Date: Tue, 5 Apr 2016 00:28:36 +0200

   Hi Joe,
   
   
   I am a bit reluctant to answer, since Jan's reply was more precise than mine,
   but anyway ...
   
   
   > Ok, so does this mean that everytime a client is added, the master
   > key's key will have the client key added?
   
   the documentation [1] says:
    The symmetric encryption key is encrypted with the public key of every user
    who needs access to the toplevel.
   
   This section of the documentation contains another few bits of details
   regarding the implemented encryption that are probably of interest for you.
   
   Cheers,
   Lars
   
   
   [1] http://obnam.org/encryption/#index4h2
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Lars Wirzenius <liw@liw.fi>
Date: Tue, 12 Apr 2016 09:35:56 +0300

   On Sun, Apr 03, 2016 at 03:34:03PM +0000, obnamsupport wrote:
   > By the way (because I didn't think asking about it earlier), does obnam
   > (re)store file attributes/ownerships etc.?
   
   Yes, of course. :)
From: Lars Wirzenius <liw@liw.fi>
Date: Tue, 12 Apr 2016 09:37:05 +0300

   Thanks, Lars and Jan, for answering these encryption questions. I
   think your answers are correct.
   
   On Tue, Apr 05, 2016 at 12:28:36AM +0200, Lars Kruse wrote:
   > Hi Joe,
   > 
   > 
   > I am a bit reluctant to answer, since Jan's reply was more precise than mine,
   > but anyway ...
   > 
   > 
   > > Ok, so does this mean that everytime a client is added, the master
   > > key's key will have the client key added?
   > 
   > the documentation [1] says:
   >  The symmetric encryption key is encrypted with the public key of every user
   >  who needs access to the toplevel.
   > 
   > This section of the documentation contains another few bits of details
   > regarding the implemented encryption that are probably of interest for you.
From: obnamsupport <obnamsupport@infopower.nl>
Date: Tue, 12 Apr 2016 11:58:37 +0000

   On Tue, 12 Apr 2016 09:35:56 +0300
   Lars Wirzenius <liw@liw.fi> wrote:
   
   > On Sun, Apr 03, 2016 at 03:34:03PM +0000, obnamsupport wrote:
   > > By the way (because I didn't think asking about it earlier), does
   > > obnam (re)store file attributes/ownerships etc.?
   > 
   > Yes, of course. :)
   > 
   
   Ok, sorry for asking. :)
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org