[linux] Remote encrypted backup (was: goedkope energiezuinige computer)

[Peter Fokker]

"Hugo van der Kooij" wrote:

> On Sun, 20 Aug 2006, Folkert van Heusden wrote:
> 
> > Ja maar het is zowiezo niet voor XP. Het idee is dat ik die pc bij m'n
> > ouders zet en dan met rsync en cryptosync elke nacht m'n data naar hen
> > toe backup.
> 
> Ehh. Iets mis met rsync over ssh? Daar heb ik internationaal al goede
> ervaringen mee. (Server in Noorwegen doet backup bij mij, ...) En het is
> met 2 vingers in de neus nog op te zetten.
> 
> Hugo.

Als het werkelijk zo simpel is dan zou ik graag wat meer details weten.
Ik ben al een tijdje op zoek naar een goede (robuust, betrouwbaar,
controleerbaar) faciliteit voor het maken van encrypted remote backups.

In praktijk blijkt mijn oplossing met het encrypten van (zeer grote)
tarballs niet fijn te werken bij beperkte bandbreedte. Het overseinen
van individuele (alleen gewijzigde) bestanden (met rsync of
anderszins) klinkt al een stuk efficienter maar ik heb daar problemen
mee als ik niet (ook) iets doe aan het encrypten van de bestandsnamen
+ paden. Een backup van een file op de server van een ander met als
naam 'Onstlagbrief heer Fokker.sxw.gz.des' mag dan encrypted zijn,
maar ik kan de inhoud wel zo'b beetje gokken... ;-) Bijkomend
probleem: als ik een backup maak van _alle_ bestanden op een server,
dan moet ik root zijn op die bron-server. Als ik alle permissies wil
conserveren dan is dat lastig als ik op de backup-server slechts een
eenvoudig (minimaal) useraccount heb != root.

Ik heb al eens zitten nadenken of duplicitiy een oplossing zou zijn
(http://duplicity.nongnu.org), maar ik krijg daar tot nu toe geen
warm gevoel van.

Gisteren ontdekte ik Folkert's cryptosync
(http://www.vanheusden.com/cryptosync). Dat komt in de buurt van mijn
eigen gedachtenspinsels over dit onderwerp:
 - je kunt op de bron-server een aparte directrory tree bouwen
   met encrypted paden + filenamen (en die dan rsyncen). Goed.
 - bestanden worden ook nog eens gecomprimeerd. Ook goed.

Ik heb alleen een beetje moeite met het feit dat alle informatie
over de encrypted backups in 1 enkel bestand 'index.dat' lijkt te
staan. En dat bestand staat zelfs op de remote server (dus mogelijk
buiten je eigen bereik, althans: modificeerbaar op die remote machine).
Klinkt erg als een Single Point of Failure; als 'index.dat' niet
meer bestaat is er (voorzover ik kan zien) geen manier meer om uit
de encrypted filename de plaintext filename af te leiden, ook niet als
je het password weet. Da's lastig (op zijn zachtst gezegd). Anderzijds:
je kunt nog wel wat informatie afleiden uit die 'index.dat', in ieder
geval of het bestand in kwestie een symlink is of niet. Hmmmm..

In mijn toepassing voor een remote backup gaat het bijv. om 250.000
a 300.000 bestanden in 45.000 directories (in totaal in de orde van
30 a 40 GB gecomprimeerd). Da's toch wel vrij veel voor zo'n
'index.dat' vrees ik (en ook voor een simpel ADSL-lijntje).

Idealiter zouden die 300.000 bestanden ieder apart gecomprimeerd en
encrypted moeten worden op een zodanige manier dat de resulterende
file geheel self-contained is, dwz. inclusief de naam _en_ het pad
_en_ de permissies en dan ook nog eens zodanig dat je geen dubbel
werk doet bij het prepareren van de encrypted directory tree.
Misschien iets als dit (pseudocode)?

for $srcfile in $HOME/*; do
    $tgtpath = make_new_pathname($HOME/$srcfile);
    $tgtfile = make_new_filename($HOME/$srcfile);
    if timestamps($HOME/$srcfile) != timestamps($BACK/$tgtpath/$tgtfile); then
        # need new encrypted version of file
        mkdir -p $BACK/$tgtpath
        tar zcpf - $HOME/$srcfile | des -e -k SeCrUt >$BACK/$tgtpath/$tgtfile
        touch -c -r  $HOME/$srcfile $BACK/tgtpath/$tgtfile
        touch -a -r  $HOME/$srcfile $BACK/tgtpath/$tgtfile
    fi
done
[ ...rsync $BACK with remote... ]

Als ik zoiets doe, dan kan ik, als ik het wachtwoord 'SeCrUt'
maar weet, van een willekeurig bestand exact bepalen hoe het
oorspronkelijk heette, inclusief permissies:

    des -d $BACK/some/encrypted/path/to/encryptedfilename.des -k SeCrUt | tar ztf -

en ik kan het botweg terugzetten met

    des -d $BACK/some/encrypted/path/to/encryptedfilename.des -k SeCrUt | tar zxf -

Het enig nadeel is dat ik niet zo eenvoudig gericht kan zoeken naar
de backup van een specifiek origineel bestand; ik moet in feite de
hele backup sequentieel doorzoeken naar een encrypted file die
in plaintext '/home/peter/levenswerk.txt' oplevert. Dat zal niet
echt snel zijn. (Omgekeerd '/home/peter/levenswerk.txt' omzetten
naar '/7/5/E/A/75EA84EECE1950EAB8C8C8AA1F694242' en dan daar naar
gaan zoeken werkt alleen als maar als je de naam van de file 100%
zeker weet, en dan nog: als je bij het encrypten van de filenaam
een salt gebruikt, dan weet je het nog steeds niet.

Oh, ja, en wat gebeurt er als er een name clash is? Het zou namelijk
kunnen gebeuren dat twee verschillende filenamen tot dezelfde encrypted
filenaam leiden (als je een digest-algoritme gebruikt). Als je _geen_
digest gebruikt, dan geef je al weer informatie weg puur en alleen
op grond van de lengte. Da's ook nie goe.

Het is allemaal niet zo eenvoudig, dus: als er een goede manier is om
al dan niet met 2 vingers een goed-werkende encrypted backup te
construeren, dan hou ik me bijzonder aanbevolen voor suggesties en ideeen.

--Peter Fokker

-- 
Doe mee aan de marktwerking in de Nederlandse spelling:
koop het Witte Boekje in augustus 2006 - http://wittespelling.nl