Encrypten van backup bestanden

[Ravefiend]

Voor weinig geld kan je tegenwoordig je backup bestanden kwijt bij cloud diensten zoals Crashplan, Backblaze, Amazon, etc. Elk van hun hebben zo hun eigen encryptie methods maar net dit heb ik liever zelf in de hand. Anders gezegd, ongeacht waar de backup bestanden terecht komen, enkel ik kan deze decrypten.

Het volgende idee leek mij wel toepasbaar, maar is het wel een goede methode?

code:

Key file genereren
openssl rand -base64 2048 > secret_key_2048.txt

Encryptie:
openssl enc -aes-256-cbc -e -k secret_key_2048.txt -in file.xyz -out file.xyz.enc

Decryptie
openssl enc -aes-256-cbc -d -k secret_key_2048.txt -in file.xyz.enc -out file.xyz

Is OpenSSL een goed plan voor dit of zijn er betere opensource alternatieven? (FreeBSD / FreeNAS)

[Thralas]

Wat heb je verder al overwogen? Er zijn genoeg alternatieven, maar het ligt er maar net aan wat je eisen zijn.

- Crypto container: TrueCrypt of iets dat 'native' BSD is
- Iets als EncFS (Linux), maar dan onder BSD (geloof niet dat dat er echt is, al lijkt PEFS mogelijk relevant)
- Files los encrypten (zoals je nu al doet):

In dat geval zie ik weinig problemen met je OpenSSL-voorstel Je OpenSSL voorstel is broken, al werkt GPG misschien makkelijker (dan kun je encrypten voor een public key, en heb je de (private) key enkel nodig bij decrypten).

Daarop voortbordurend: Duplicity is een backupoplossing op basis van GPG, eventueel zou je dat kunnen overwegen.

[ Voor 3% gewijzigd door Thralas op 23-04-2013 13:12 ]

[Henk007]

Het hangt er helemaal vanaf in welke setting je dit doet.
In veel gevallen voldoet de ingebouwde encryptie van standaard archivering/compressiesoftware.
Bijvoorbeeld 7-zip:

Strong AES-256 encryption in 7z and ZIP formats

edit: Niet goed gelezen , maar een 7-zip port voor o.a. FreeBSD is P7zip

[ Voor 14% gewijzigd door Henk007 op 22-04-2013 17:13 ]

[Osiris]

Thralas schreef op maandag 22 april 2013 @ 17:03:
(…) al werkt GPG misschien makkelijker (dan kun je encrypten voor een public key, en heb je de (private) key enkel nodig bij decrypten).

Wat is daar het praktisch nut van?

GPG e.d. maken eigenlijk alleen gebruik van de public/private keys (asymmetrische encryptie) om een random key voor vervolgens symmetrische encryptie te encrypten. 't Gebruik van public/private-key-algoritmes schijnt namelijk nogal wat rekenkracht nodig te hebben i.t.t. symmetrische algoritmes zoals AES.

Als gewoon een algoritme als AES al meer dan prima werkt, waarom dan moeilijk gaan doen met public en private keys? 't Is immers toch voor z'n eigen gebruik, dus ik zie de meerwaarde daar niet van.

@ TS: ik zou niet weten waarom dit niet gewoon prima zou fungeren? Wat vind je er zelf van?

[ Voor 5% gewijzigd door Osiris op 22-04-2013 17:13 ]

[Thralas]

Osiris schreef op maandag 22 april 2013 @ 17:12:
Wat is daar het praktisch nut van?

It depends, ligt eraan wat je wilt (TS was niet duidelijk).

Stel dat je een server automatisch wilt backuppen; met enkel een symmetrische key zul je die key altijd toegankelijk moeten hebben op de machine die de backups encrypt; een compromise betekent daarnaast dat al je backups mogelijk compromised zijn.

Met GPG heb je dat probleem niet - tenminste niet totdat je je key gebruikt om een backup te decrypten. Of helemaal niet als je een andere machine gebruikt om je backups te decrypten.

Een ander pijnpunt is key management. Het systeem van TS zoals hij het voorstelt biedt geen mogelijkheid om de passphrase aan te passen; met GPG krijg je dit er allemaal voor niets bij.

[Equator]

asymmetrisch encryptie gebruik je alleen voor het versleutelen van een symmetrische encryptie sleutel of een hash(bij ondertekenen). Block encryptie doe je een symmetrisch algoritme. Wat Osiris zegt klopt. asymmetrisch is vele malen zwaardere berekening.

Het wijzigen van de encryptiesleutel is niet mogelijk zonder ontsleuteling en weer opnieuw versleutelen. Dat klopt. Daarom is het handiger om je encyptiesleutel te versleutelen met een wachtwoord. Dat wachtwoord kun je makkelijk wijzigen. uitkomst is en blijft de correcte encryptiesleutel.

Zo heb je dus een Key Encryption Key, en een Data Encryption Key. De KEK kan je makkelijker wijzigen dan de DEK

[Thralas]

Ja, en het hele punt van GPG was dus dat je dat 'voor niets' krijgt - het is simpelweg vele malen robuuster dan de puur symmetrische oplossing die de TS aandraagt, terwijl het flexibeler, minder foutgevoelig¹ en niet moeilijker in gebruik is.

[1] OpenSSL verwacht bv. een expliciete cipherkeuze, terwijl GPG (tegenwoordig) met sane defaults shipped

Je hoeft me (a)symmetrische cryptografie & key management echt niet uit te leggen hoor

[Osiris]

Dan nog zie ik het voordeel niet van het d.m.v. een asymmetrische encryptie-methode encrypten van je block-cipher-key. Je private key moet je immers óók weer versleutelen met een passphrase. Dus die tussenstap ontgaat me nog steeds.

[Ravefiend]

Thralas schreef op maandag 22 april 2013 @ 20:36:
Ja, en het hele punt van GPG was dus dat je dat 'voor niets' krijgt - het is simpelweg vele malen robuuster dan de puur symmetrische oplossing die de TS aandraagt, terwijl het flexibeler, minder foutgevoelig¹ en niet moeilijker in gebruik is.

\[1] OpenSSL verwacht bv. een expliciete cipherkeuze, terwijl GPG (tegenwoordig) met sane defaults shipped

Je hoeft me (a)symmetrische cryptografie & key management echt niet uit te leggen hoor

Ik had doelbewust asymmetrische cryptografie achterwege gelaten in mijn TS omdat ik daar niet zo direct het nut in zag. Dat gezegd zijnde, in het scenario dat men toch zover geraakt op de server, is het wel zo fijn dat de private key niet compromised is en bijgevolg de bestaande backups ook op straat liggen. Die key hou ik wel op een andere (externe) locatie.

... interessante discussie trouwens ...

[Equator]

Thralas schreef op maandag 22 april 2013 @ 20:36:
Ja, en het hele punt van GPG was dus dat je dat 'voor niets' krijgt - het is simpelweg vele malen robuuster dan de puur symmetrische oplossing die de TS aandraagt, terwijl het flexibeler, minder foutgevoelig¹ en niet moeilijker in gebruik is.

\[1] OpenSSL verwacht bv. een expliciete cipherkeuze, terwijl GPG (tegenwoordig) met sane defaults shipped

Je hoeft me (a)symmetrische cryptografie & key management echt niet uit te leggen hoor

Nou, voor niets.. Het versleutelen duurt alleen een factor 1000 langer
Nee, dat is niet een geheel uit de lucht gegrepen getal
En dat je dat niet merkt bij een document van 10kB snap ik. Maar wanneer je een paar GB aan data moet versleutelen, nou succes

Het idee van een publieke en een private sleutel is dat je iets kunt versleutelen met de private sleutel, en dat iedereen je publieke sleutel mag gebruiken om het te ontsleutelen. Er vanuit gaande dat jij de enige bent met toegang tot de private sleutel kunnen we er dus vanuit gaan dat jij ook diegene bent die het heeft versleuteld. (onweerlegbaarheid)
Andersom kan iedereen jou een bericht sturen wat is versleuteld met je publieke sleutel en alleen jij kunt het weer openen. (vertrouwelijkheid)

Maar asymmetrische encryptie is niet bedoeld voor het versleutelen van grote stukken data. Daarvoor moet je een blockcypher gebruiken zoals AES, Rijndeal, DES, 3DES of BlowFish. Die zijn daar wel voor bedoeld.
De DEK kan je wel versleutelen met een asymmetrisch algoritme.

S/MIME doet dit ook.
Een versleutelde e-mail aan iemand wordt versleuteld met een symmetrische sleutel. Deze sleutel wordt versleuteld met de publieke sleutel van de ontvanger en de resulterende cyphertext wordt onder het bericht geplakt. S/MIME maakt daarvan dan weer een hash welke wordt versleuteld met de private sleutel van de versturende partij. De daaruit resulterende cyphertext wordt samen met het certificaat van de versturende partij aan de e-mail geplakt.(de digitale ondertekening)

De ontvanger krijgt het certificaat (met de publieke sleutel) van de versturende partij. Daarmee ontsleuteld hij de hash en controleert deze met de zelf berekende hash. Zo controleert hij of de tekst niet gewijzigd is.
Dan ontsleuteld hij de encryptie sleutel met zijn eigen private sleutel, waarna hij het gehele bericht kan ontsleutelen.

offtopic:
Dit is niet een 'les' aan jou gericht b.t.w. Het is gewoon interessante shit

[ Voor 4% gewijzigd door Equator op 22-04-2013 21:58 ]

[Thralas]

Osiris schreef op maandag 22 april 2013 @ 20:47:
Dan nog zie ik het voordeel niet van het d.m.v. een asymmetrische encryptie-methode encrypten van je block-cipher-key. Je private key moet je immers óók weer versleutelen met een passphrase. Dus die tussenstap ontgaat me nog steeds.

De asymmetrische 'tussenstap' biedt je twee mogelijkheden, afhankelijk van het feit of je een file wilt en- of decrypten.

Aangezien we toch al offtopic gingen kan deze uitleg er ook nog wel bij, voor future reference

Key generation:

1. genereer een asymmetric key P_keypair
2. encrypt deze met een symmetric key S_deriv derived van je passphrase

File encryption:

1. genereer een per-file key S_content en encrypt hiermee de file
2. encrypt deze met de public part van P_keypair (geen passphrase nodig)

File decryption:

1. decrypt S_deriv met je passphrase
2. decrypt de per-file key S_content met de private part van P_keypair
3. decrypt file met S_content

Je merkt (terecht) op dat er 3 stappen nodig zijn voor het decrypten van een file. Het voordeel is echter dat je de passphrase (lees: private key, en dus ook passphrase) helemaal niet nodig hebt bij het encrypten van een file - de kans dat Eve je private key (en passphrase) weet te verkrijgen is dus per definitie kleiner.

Tevens zou je kunnen stellen dat het 'complexer' is, maar daar merk je in de praktijk dus niets van (dat regelt bv. GnuPG voor je).

[Equator]

Je hebt het nu over het versleutelen van de encryptiesleutel met een asymmetrisch algoritme. Tuurlijk, dat is slim. Maar je had het eerder (of je was onduidelijk) over het versleutelen van grote hoeveelheden data met je publieke sleutel. En daar gingen Osiris en ik op in.

[Thralas]

Equator schreef op maandag 22 april 2013 @ 22:02:
Maar je had het eerder (of je was onduidelijk) over het versleutelen van grote hoeveelheden data met je publieke sleutel. En daar gingen Osiris en ik op in.

Dan was ik daar onduidelijk. Met 'encrypten voor een public key' doelde ik uiteraard op het feit dat een (fresh) symmetric content key wordt geencrypt met het publieke deel van een asymmetrisch keypair.

[Osiris]

Ook ik ben bekend met de technieken van asymmetrische encryptie.

Maar het praktische nut ervan is nog steeds NIET duidelijk.

De TS kan z'n files encrypten zonder passphrase voor z'n private key. Nou.. Whooptiedoo. Als ik de TS zo lees heeft 'ie de files toch wel unencrypted op z'n eigen schijf staan. Het ging hem namelijk om het encrypten van z'n backups voor ergens in een, niet door hem gecontroleerde, backup-service. (Ik weiger het woord wat iets met meteorologische verschijnselen te maken heeft in de mond te nemen.)

Verder blijf ik erbij: je omschrijft slechts een manier om er voor te zorgen dat de TS de symmetrische key die hij toch al ging gebruiken kunt 'beveiligen'. Sure, elke file krijgt dan wel een andere key, dus je hebt het probleem niet van het feit "mocht de key ooit open en bloot liggen, dan zijn alle files compromised", maar da's natuurlijk ook zo met z'n private key.

Ook valt er ongetwijfeld een manier te verzinnen zoals ssh-agent werkt. Eén keer je key invullen en je kunt die sessie d'r gewoon mee werken. Mgoed, GPG is daar natuurlijk, indeed, ook een mogelijkheid voor. Als de TS dat leuk vindt Persoonlijk vind ik 't enigszins overhead hebben. GPG is weer gekoppeld aan een email-adres en dient voor public keyring authentication en dat soort shizzle.

[ Voor 10% gewijzigd door Osiris op 23-04-2013 00:05 ]

[Thralas]

Osiris schreef op maandag 22 april 2013 @ 23:34:
Maar het praktische nut ervan is nog steeds NIET duidelijk.

De TS kan z'n files encrypten zonder passphrase voor z'n private key. Nou.. Whooptiedoo.

Goed, dan tik je iedere keer dat je wilt backuppen je passphrase. Whatever floats your boat.

Persoonlijk vind ik dat overhead, niet het feit dat GPG een mailadres 'eist' (inderdaad irrelevant in dit scenario, maar je kunt prima username@localhost invullen).

Andere voordelen zijn mogelijk niet direct relevant (passphrase change, resilience tegen het 'stelen' van je key), maar je krijgt ze er zo bij, so why the hell not?

[likewise]

Een woord: Duplicity

[ Voor 51% gewijzigd door likewise op 23-04-2013 01:25 ]

[Ravefiend]

likewise schreef op dinsdag 23 april 2013 @ 01:25:
Een woord: Duplicity

Zeker mee eens dat dit volledig past in het plaatje echt is het net een stap te ver qua complexiteit voor het doel dat ik voor ogen heb.

Laat ons stellen dat ik GnuPG / GPG toch maar ga laten voor wat het is en bij OpenSSL ga houden. Wat valt er dan nog te zeggen over zeggen over de key length voor OpenSSL (2048 in mij voorbeeld) alsook de salt?

[Equator]

Dit betreft alleen je encryptiesleutel. Onder water werkt AES met 256bit blokken. De lengte van je encryptiesleutel is daarin geen vertragende factor.

Salting is eigenlijk iets wat wordt gebruikt in het tegengaan van een raibowtable bij hashing. Een rainbowtabel is een grote database waarin je een gegenereerde hash kan terugzoeken naar de originele invoer. Iets wat bij hashing wiskundig gezien onmogelijk is (hashing is one way).
Om nou te zorgen dat een hash niet herleid kan worden naar het originele 'wachtwoord' geef je een onbekende salt op voordat je de hash uitvoert. Dit maakt het gebruik van een rainbowtable niet onmogelijk, maarhet maakt het een stuk lastiger.
Zolang jij de hash van je wachtwoord niet ergens opslaat en tegen valideert heb je geen salt nodig.

[ Voor 7% gewijzigd door Equator op 23-04-2013 09:23 ]

[Thralas]

Nu ik er nog eens naar kijk, je onderstreept maar weer eens waarom het juist implementeren/gebruiken van crypto moeilijk is. Het scheme uit de TS is flawed of biedt zelfs helemaal geen security.

code:

-k             passphrase is the next argument
-kfile         passphrase is the first line of the file argument

That said, je hebt het over een salt; probeer je nu een key of een passphrase aan OpenSSL te voeren? Als je een passphrase gebruikt regelt OpenSSL key derivation voor je (met een suitable per-file salt).

Als je wel van plan was een plain key aan OpenSSL te voeren getuigt je vraag over een salt van het feit dat je niet snapt wanneer een salt relevant is. Ook pakt OpenSSL een zero IV als je deze niet meegeeft - iets dat geen probleem is als je key derivation aan OpenSSL overlaat. De vraag over key length is dan ook niet relevant - AES heeft een fixed keysize.

Oh, maar dan specificeren we toch gewoon een voldoende lange passphrase? Prima - maar dan biedt het (gecorrigeerde) systeem uit je TS slechts maximaal ~128 bits security¹ (itt. de theoretische 256 van AES-256). Ruim voldoende, maar het bewijst maar weer dat 'openssl enc' niet meer dan een doos cryptospeelgoed voor (amateur)cryptografen is.

[1] Iemand die het aandurft dat uit te leggen?

[Osiris]

Kwestie van -K en -iv gebruiken dus

[Ravefiend]

Thralas schreef op dinsdag 23 april 2013 @ 14:24:
Nu ik er nog eens naar kijk, je onderstreept maar weer eens waarom het juist implementeren/gebruiken van crypto moeilijk is. Het scheme uit de TS is flawed of biedt zelfs helemaal geen security.

code:

-k             passphrase is the next argument
-kfile         passphrase is the first line of the file argument

That said, je hebt het over een salt; probeer je nu een key of een passphrase aan OpenSSL te voeren? Als je een passphrase gebruikt regelt OpenSSL key derivation voor je (met een suitable per-file salt).

Als je wel van plan was een plain key aan OpenSSL te voeren getuigt je vraag over een salt van het feit dat je niet snapt wanneer een salt relevant is. Ook pakt OpenSSL een zero IV als je deze niet meegeeft - iets dat geen probleem is als je key derivation aan OpenSSL overlaat. De vraag over key length is dan ook niet relevant - AES heeft een fixed keysize.
...

Yes, zoals ik al aangaf ben ik geen meester in cryptografie vandaar dit topic Blijkt dus alweer dat ik zelfs de verkeerde argumenten had gebruikt want in mijn voorbeeld moet het -kfile zijn (denk ik dan toch).

[Osiris]

Ravefiend schreef op dinsdag 23 april 2013 @ 14:53:
[...]

Yes, zoals ik al aangaf ben ik geen meester in cryptografie vandaar dit topic Blijkt dus alweer dat ik zelfs de verkeerde argumenten had gebruikt want in mijn voorbeeld moet het -kfile zijn (denk ik dan toch).

Neen.

[Oid]

bij crashplan kan je toch zo en zo al zelf een encryptie sleutel opgeven zodat je bestanden nooit benaderbaar zijn door crashplan zelf? Backblaze heeft dit niet.

[Ravefiend]

Osiris schreef op dinsdag 23 april 2013 @ 14:57:
[...]

Neen.

Ok, nog eens een poging dan na het lezen van de OpenSSL documentatie: met "-kfile filename" geef ik een password dat als basis dient om zowel key als IV te genereren.

Mijn TS is denk ik in die mate misleidend dat ik 'key' gebruik, terwijl het eigenlijk het password betreft. Bovendien genereert 'openssl rand -base64 2048' een output met na elke 65 characters een CR/LF dus is "-kfile secret_key_2048.txt" fout. Deze gaat enkel maar de eerste lijn (op een totaal van 42) gebruiken.

Edit: ... anders gezegd, het Key Derivation Algorithm komt hieraan te pas.

[ Voor 5% gewijzigd door Ravefiend op 24-04-2013 09:29 ]

[Ravefiend]

Deze discussie vond ik destijds al interessant om te voeren en afgelopen weekend heb ik me er nog wat verder in verdiept. Wat meer leesvoer omtrent het gebruiken van OpenSSL voor het encrypteren van bestanden:

http://security.stackexch...-key-and-iv-by-passphrase
--> OpenSSL is just not secure enough, so using GnuPG instead

GnuPG / gpg2 kan je net als OpenSSL inzetten voor symmetric encryption, waarbij gpg veel meer itteraties doorloopt mbt de passphrase. ( http://security.stackexch...encrypting-decrypting-key )

[ELD]

Aangezien je gebruik wilt maken van GnuPG gok ik dat je wellicht Linux gebruikt. Mijn suggestie is dan om ook te kijken naar DM-crypt/LUKS. DM-crypt is onderdeel van het Linux kernel subsysteem en maakt gebruik van de Linux crypto api. Je kunt het opzetten met Cryptsetup, te vinden in bijna elke distro(Fedora, Debian Mint, Ubuntu etc).

Voor meer informatie
http://code.google.com/p/cryptsetup/

Maken van een encrypted file container.
http://sys64738.dk/doku.p...iner_with_cryptsetup-luks

LUKS maakt gebruik van de PBKDF2 methode. Alle hash functies in de crypto api zijn beschikbaar (praktisch alle). Je kunt bijvoorbeeld 2 miljoen Sha512 hash iteraties doen. Met een snelle CPU kost dat 10 seconden. Dus als je de bestanden wilt opslaan in de cloud als backup, dan kun je best hier een minuut voor nemen.

Je kunt deze filecontainers ook op Windows openen via FreeOFTE.

[Ravefiend]

Bedankt voor de tip ELD! Oorspronkelijk was is op zoek naar een oplossing op mijn FreeNAS (FreeBSD) systeem maar vooralsnog sta ik open voor alle suggesties. Ook met gpg2 kan je zelf het aantal itteraties opgegeven met "--s2k-count n".

Doc: http://www.gnupg.org/docu...ions.html#OpenPGP-Options