Hi Adam,
From what I've read, it looks like convergent encryption would solve
all the cases you mention.
1) Any third party wouldn't be able to decrypt the files on the drive,
even when the server is online or without full drive encryption. The
server can't ever read file contents.
2) As with 1), administrators wouldn't be able to view file contents.
The problem you mention of destroying pooling wouldn't apply, as the
goal of convergent encryption is to still allow the pooling of identical
files by encrypting them the same way on different machines.
3) The need for encrypted tunnels is still there, but at least file
contents wouldn't be visible in transit.
Cody
Adam Goryachev wrote:
>
> Cody Dunne wrote:
>> I recently ran into a paper on convergent encryption, which is a way of
>> encrypting file blocks by their hashes. The hashes (keys) are stored
>> with the blocks, encrypted with the public key of any authorized
>> readers. This allows a server to pool identical files, as they end up
>> having identical encrypted blocks. This would allow BackupPC to still
>> work as it does now. Naturally, file size, location, quantity, etc are
>> visible but the contents wouldn't be.
>>
>> I'm not sure if this has been suggested before, but a brief peruse of
>> the archives didn't turn anything up. It seems like the arguments
>> against encryption in the past found the pooling issue insurmountable.
>
> I suppose there are a number of issues which should be solved by any
> encryption/backup solution, but which issues each person needs solved
> are different.
>
> 1) In some cases, the idea is to stop any third party that happens to
> break into the backup server from retrieving the data.
> 2) In other cases, you also want to prevent the admin of the backup
> server from being able to access the un-encrypted data
> 3) I'm sure there are other scenarios as well, but those are best
> resolved with a VPN/similar solution.
>
> To solve (1) there are probably a number of solutions from using an
> encrypted filesystem, or similar, though I'm not sure how useful that is
> when you need to leave the filesystem mounted 100% of the time so that
> backups can occur when needed. Same applies for auto-mounting the
> filesystem just before a backup, if the system can automount, then so
> could an attacker...
>
> To solve (2) there are also a number of possible solutions, one of which
> was mentioned on this list recently (rsync + encryption) which involved
> creating an encrypted directory structure (copy of the data) and then
> using the standard rsync to backup this encrypted structure.
>
> The ideal solution (from my perspective :) ) would be to have a custom
> open source'backuppc client' which can be installed on any linux or
> windows system, which supports rsync-like backups, with optional
> encryption prior to sending the data. This encryption will probably
> destroy the concept of pooling (unless every encryption key is the same
> on all clients), but it does make use of the other 90% of what backuppc
> provides (scheduling, interface, etc)
>
> Of course, the 'custom open source client' would also solve a number of
> other issues such as allowing the client to select which folders/files
> to include/exclude in the backup etc....
>
> Regards,
> Adam
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
