backup TrueCrypt container datacorruptie/recovery

[sloth]

Ik ben bezig met een backup strategie te bepalen voor mn data thuis. Een deel van de data die ik wil backuppen vind ik te privacygevoelig om as-is offsite te plaatsen, waarbij de vraag naar encryptie naar voren komt.

Na me hierover ingelezen te hebben wil ik met TrueCrypt file containers gaan werken. Het idee is simpelweg een file container aan te maken, deze te mounten, de backups hiernaar te kopiëren en vervolgens na het unmounten dit bestand up te loaden naar een offsite backup dienst als CrashPlan of Dropbox.

Tot zover niets speciaals aan de hand, ware het niet dat ik zeker wil zijn dat wanneer ik een backup wil restoren, deze ook überhaupt te restoren valt. Ik lees namelijk in de TrueCrypt FAQ:

quote: http://www.truecrypt.org/faq

What will happen when a part of a TrueCrypt volume becomes corrupted?
In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by TrueCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected.

Het spreekt voor zich dat ik wil vermijden dat een TrueCrypt volume niet meer te mounten is door 1 corrupte bit.

Zelf denk ik eraan om het truecrypt volume in een winrar archief te plaatsen en bij het archiveren extra recovery records aan te maken.
Ook heb ik wel eens van par2 bestanden gehoord, maar dit zorgt afaik voor extra bestanden terwijl de recovery data bij winrar mee in het rar archief zit.

Mijn vraag is nu wat best practices zijn om voor extra recovery te zorgen zodat een TC volume niet zomaar niet meer te mounten valt? Verder heb ik ook geen idee wat wijsheid is bij recovery records. Is 1% al genoeg of ga je voor 10% extra redundancy?

[ Voor 13% gewijzigd door sloth op 07-01-2013 01:55 ]

[citruspers]

Bij goede cryptografie heb je in principe 1 hele lange streng willekeurige data, dus comprimeren met Winrar gaat je helemaal niets opleveren behalve een groter bestand. Ik weet verder niet hoe Winrar's recovery in elkaar zit, maar het kan zijn dat die zich ook geen raad weet met random data.

Pariteitscontroles zoals par2 zorgen voor extra bestanden, maar is dat erg? Verder weet ik niet zeker of het wel effectief is met versleutelde data.

Maar, volgens mij heb je het truecrypt FAQje niet helemaal goed begrepen, een cryptografisch "block" is iets compleet anders dan een truecrypt container. In het zeldzame geval dat een block corrupt raakt ben je dus maar 16 bytes data kwijt, niet je hele container.

[Room42]

citruspers schreef op zondag 06 januari 2013 @ 22:49:
Bij goede cryptografie heb je in principe 1 hele lange streng willekeurige data, dus comprimeren met Winrar gaat je helemaal niets opleveren behalve een groter bestand. Ik weet verder niet hoe Winrar's recovery in elkaar zit, maar het kan zijn dat die zich ook geen raad weet met random data.

WinRAR heeft een functionaliteit gelijk aan PAR2, dus al "comprimeer" je enkel met "store" compressie level, heb je toch je recovery records. Dat kan dus een pré zijn. Maar ik zou inderdaad gewoon PAR2 gebruiken hiervoor. En ja, dat werkt prima met random data. Een RAR-bestand, waarvoor Par2 vaak gebruikt wordt in usenet-land, is namelijk niet veel anders

@TS: Houd er wel rekening mee dat je bij elke backup de gehele container moet uploaden. Dat kan een probleem zijn als je een grote container wilt gebruiken bij een langzame verbinding.

Is een encrypted rar- of 7-zip-bestand tegenwoordig niet net zo veilig als een truecrypt volume? Dat wil dus zeggen: enkel met brute force te kraken?

[ Voor 8% gewijzigd door Room42 op 06-01-2013 22:58 ]

[Dennisik]

Winrar gebruikt 128 Bits AES. Zolang je geen Obama heet hoef je, je geen zorgen te maken.

Je praat over tientallen jaren aan BFA, als je alle computers die op dit moment in dit Universum gebruikt die te verkrijgen zijn. Zo niet duizenden jaren.

Wil je nog veiliger spelen.
Truecrypt 512 Bits AES. Deze container rar je met 128 Bits AES en over dat rar bestand lever je 10 tot 15% aan par2 files mee.

Al lijkt me dat iets teveel van het goeie.

Betreft het kraken van Winrar of 7zip. AES logaritme is enorm sterk.
Enkel de software die AES gebruikt is bij AES de boosdoener. Als Winrar, tijdelijk de key in het ram geheugen stopt in plain text dan is het niet enorm veilig meer.

[ Voor 20% gewijzigd door Dennisik op 07-01-2013 00:19 ]

[Mr_gadget]

Misschien is het makkelijker om de data op te splitsen. Ik weet in hoeverre het mogelijk is om op een slimme manier per bestand te encrypten? Als je alleen de veranderde bestanden opnieuw hoeft te encrypten en up te loaden scheelt dat een hoop tijd. Als een backup maken erg lang duurt dan ga je het misschien te weinig doen

[Tsurany]

Om hoeveel data gaat het? Ik zou kiezen voor PAR2 simpelweg omdat het de simpelste oplossing is die zichzelf al ruim bewezen heeft. Gaat het om weinig data in hoeveelheden GB's kan je zelfs een 200% PAR2 maken. Dan kan je praktisch alles verliezen en alsnog restoren.

[sloth]

citruspers schreef op zondag 06 januari 2013 @ 22:49:
Bij goede cryptografie heb je in principe 1 hele lange streng willekeurige data, dus comprimeren met Winrar gaat je helemaal niets opleveren behalve een groter bestand. Ik weet verder niet hoe Winrar's recovery in elkaar zit, maar het kan zijn dat die zich ook geen raad weet met random data.

Pariteitscontroles zoals par2 zorgen voor extra bestanden, maar is dat erg? Verder weet ik niet zeker of het wel effectief is met versleutelde data.

Maar, volgens mij heb je het truecrypt FAQje niet helemaal goed begrepen, een cryptografisch "block" is iets compleet anders dan een truecrypt container. In het zeldzame geval dat een block corrupt raakt ben je dus maar 16 bytes data kwijt, niet je hele container.

Het is niet de bedoeling compressie in te schakelen, wel om winrar (of een andere oplossing) te gebruiken voor de recovery records.
Erg niet, ik kan er gewoon - m.u.v. usenet artikels - weinig over vinden. Het lijkt nog meer een knutseloplossing te zijn dan het al is, en als het kan probeer ik dat te vermijden.

Dat had ik inderdaad verkeerd begrepen dan. Ik denk dat de verwarring komt met berichten te lezen over corruptie in de volume header. Als dat voorkomt kan je alleen bij je bestanden door een backup volume header in te zetten. Omdat een volume header slechts 512 byte is, is het niet echt een probleem hier voldoende backups van te voorzien.

Room42 schreef op zondag 06 januari 2013 @ 22:54:
[...]
@TS: Houd er wel rekening mee dat je bij elke backup de gehele container moet uploaden. Dat kan een probleem zijn als je een grote container wilt gebruiken bij een langzame verbinding.

Is een encrypted rar- of 7-zip-bestand tegenwoordig niet net zo veilig als een truecrypt volume? Dat wil dus zeggen: enkel met brute force te kraken?

Dat besef ik me. Gelukkig gaat het bij de data die vaak veranderd slechts om 1 GB, dus dat ik niet echt een probleem.

Geen idee eigenlijk. In rar bestanden heb ik minder vertrouwen omdat de software afaik closed source is. 7-zip is gelukkig wel open source, maar is niet meer geüpdatet sinds 2010. TrueCrypt is zowel open source, het wordt over de hele wereld actief gebruikt én er komen frequent updates voor, en je hoort dat er vaak audits / penetration tests voor zijn. Ook de mogelijkheid zelf de encryptie te bepalen charmeert me wel.

Dennisik schreef op maandag 07 januari 2013 @ 00:16:
Enkel de software die AES gebruikt is bij AES de boosdoener. Als Winrar, tijdelijk de key in het ram geheugen stopt in plain text dan is het niet enorm veilig meer.

Net dit soort dingen doen me aan winrar twijfelen terwijl dat bij TC net veel beter voor elkaar is lijkt me, of zou het toch moeten zijn. In zo'n dingen geef ik de voorkeur aan open source software.

Mr_gadget schreef op maandag 07 januari 2013 @ 00:23:
Misschien is het makkelijker om de data op te splitsen. Ik weet in hoeverre het mogelijk is om op een slimme manier per bestand te encrypten? Als je alleen de veranderde bestanden opnieuw hoeft te encrypten en up te loaden scheelt dat een hoop tijd. Als een backup maken erg lang duurt dan ga je het misschien te weinig doen

Wat bedoel je precies met data opsplitsen? Ik maak op dit moment al een onderscheid tussen publieke data (jammer als het uitlekt, maar geen ramp) en private die ik wil beveiligen d.m.v. encryptie.
Dat klinkt ook als een optie. Hoe zou je dit aanpakken?
Klopt. Daarom wil ik ook een "gebruiksvriendelijke" oplossing om dit te vermijden.

Tsurany schreef op maandag 07 januari 2013 @ 00:23:
Om hoeveel data gaat het? Ik zou kiezen voor PAR2 simpelweg omdat het de simpelste oplossing is die zichzelf al ruim bewezen heeft. Gaat het om weinig data in hoeveelheden GB's kan je zelfs een 200% PAR2 maken. Dan kan je praktisch alles verliezen en alsnog restoren.

Ik ben nog bezig alles te inventariseren, maar ik vermoed dat 1GB voor het private deel al heel wat is. PAR2 komt wel erg vaak naar voor als tip, ik ga daar ook even naar kijken.

---

Bedankt voor jullie input allemaal!

[ Voor 6% gewijzigd door sloth op 07-01-2013 15:29 ]

[Thralas]

Dennisik schreef op maandag 07 januari 2013 @ 00:16:
Winrar gebruikt 128 Bits AES. Zolang je geen Obama heet hoef je, je geen zorgen te maken.

Zelfs Obama maakt zich geen zorgen met AES-128 (t/m classificatieniveau Secret).

Betreft het kraken van Winrar of 7zip. AES logaritme is enorm sterk.
Enkel de software die AES gebruikt is bij AES de boosdoener. Als Winrar, tijdelijk de key in het ram geheugen stopt in plain text dan is het niet enorm veilig meer.

Algoritme. Daarnaast is het grootste probleem niet een brute-force attack tegen AES, maar eerder het gebruik van zwakke passwords gebruikt om de key te deriven.

Aan TS: RAR'en of PAR'en levert je enkel extra werk op. Benader het gewoon als plaintext data, de gangbare oplossing daar is backuppen op een extra medium.

Immers is het zo dat een bit error slechts een ciphertext block meeneemt, maar laat bit errors nou net niet je grootste probleem zijn (bad RAM daargelaten). Ik zou eerder denken aan bad sectors op je opslagmedium, en dan ben je toch een veelvoud van je ciphertext blocks kwijt, ipv. een enkele bit.

EDIT: Vergeet niet TrueCrypt zo te configureren dat 'ie modification times wegschrijft (standaard laat 'ie deze untouched), grote kans dat je backupsoftware anders je TC container overslaat.

[ Voor 7% gewijzigd door Thralas op 07-01-2013 16:34 ]

[sloth]

Inmiddels tot volgende oplossing overgegaan, waarbij ik benieuwd ben naar jullie reacties.

Een TC container van 300MB waar de bestanden (zo goed als allemaal statisch) naar gebackupt worden. Vervolgens maak ik met TC een backup van de volume header. Deze wordt reeds 2x opgeslagen (een keer vooraan de container en een keer aan het einde van de container). In totaal zijn er nu dus 3, om de kans op een totaal onbruikbare container zo klein mogelijk te maken.
Tot slot worden beide bestanden d.m.v. winrar gearchiveerd in een rar bestand met 10% recovery, uiteraard zonder compressie.

Dit bestand plaats ik zowel op m'n ZFS NAS op 3 hdd's, als op een andere client in het LAN en natuurlijk ook nog op de client vanwaar de gegevens komen.
Daarnaast maak ik d.m.v. Dropbox een offsite backup in de cloud.
In totaal staan de gegevens dus op 5 verschillende hdd's lokaal, en is er nog een backup in een datacenter. De kans deze allemaal corrupt zijn lijkt me erg klein.
Om dit risico nog te verkleinen maak ik bij een (zeldzame) update van de gegevens een tweede container aan waar de nieuwe bestanden in komen.

Is er nog iets wat ik over het hoofd zie?

[Room42]

Wel een beetje omslachtig, hoor. Zijn de gegevens zo ontzettend gevoelig?

Tenzij je het allemaal script, is de kans op fouten zo alleen maar groter, imo.

@jeroen3: spuit 11

[ Voor 48% gewijzigd door Room42 op 12-01-2013 19:27 ]

[jeroen3]

Afhankelijk van de grootte van je container kan je pariteit herstel bestanden maken om een percentage te kunnen herstellen.
http://www.quickpar.org.uk/