Userbase

Ik vraag me af of het mogelijk is om een map met documenten te beveiligen met een sleutel in Windows/Linux omgeving (dus geen toegang tot map zonder sleutel), dat zelfs indien met Google drive gesynchroniseerd word dat niemand het kan openen mits de sleutel?

1. TrueCrypt file container aanmaken
2. container mounten
3. documenten hierin opslaan
4. container unmounten
5. container laten synchroniseren met Google Drive

Bij elke wijziging gaat de container in zijn geheel opnieuw geüpload worden, incremental backups zijn niet mogelijk.
Om gegevensverlies tegen te gaan kan je de disk header van de container backuppen. Mocht deze corrupt worden kan je de backup restoren.
Nog een goede manier om dataloss te vermijden is telkens bij wijzigingen kopieën van de container te maken zodat je altijd 2-3 vorige versies terug kunt gaan.

http://www.interrupt19.com/2009/10/15/b ... truecrypt/
http://www.cloudwards.net/the-ultimate- ... r-dropbox/

Truecrypt bestaat uiteraard niet meer, nadat de devs vorig jaar de handdoek in de ring hebben gegooid.
Alternatieven zijn ciphershed of veracrypt, beiden truecrypt forks die elk op hun eigen, niet met mekaar compatibele manier werken.

[ Post made via mobile device ]

Misschien kan volgende werkwijze voldoende voor je zijn (in Ubuntu en soortgelijke distro's)
Selecteer je bestanden > erop rechtsklikken > comprimeren > geavanceerde instellingen > vul wachtwoord in en kies tenslotte een geschikt bestandsformaat vb .7z

Bedankt voor alle nuttige reacties!

Is de "truecrypt" methode te kraken?

Alles is te kraken, maar tenzij je gegevens wenst te verbergen voor de clandestiene inlichtingenorganisaties van deze wereld is dit een veilige methode. Het grote voordeel, IMHO, van TrueCrypt (en nu natuurlijk de forks) is dat het Opensource is & dus moeilijker om een achterdeurtje in te bouwen. Bij commerciële software is dit altijd een groot vraagteken, maar wederom gaat dit dan om organisaties als de NSA & co.

Fatsie schreef:Het grote voordeel, IMHO, van TrueCrypt (en nu natuurlijk de forks) is dat het Opensource is & dus moeilijker om een achterdeurtje in te bouwen.

TrueCrypt is er zelf mee gestopt omdat men van hun eigen source niet meer weet of ze te vertrouwen is.

Cryptografie is trouwens zo'n complexe materie dat er slechts een zeer beperkte groep in staat is te controleren of het veilig is of niet. Achterdeurtjes hoeven trouwens niet noodzakelijk in de coding te zitten, maar kunnen bestaan als specifieke zwakte in het gebruikte algoritme.

TrueCrypt is er zelf mee gestopt omdat men van hun eigen source niet meer weet of ze te vertrouwen is.

Bron aub ? Dan bedoel ik een echte verklaring van het DEV team waarin ze dit bevestigen, geen speculatie want die is er natuurlijk genoeg te vinden.

Hier kan je een artikel erover vinden... http://tweakers.net/nieuws/96312/truecr ... uiken.html

Het heeft dus op hun EIGEN website gestaan en is niet actief tegengesproken... al de rest zijn speculaties.

Joh ja, de originele verklaring is zo vaag ... in principe heeft alle software een 'mogelijk beveiligingsprobleem' he.

Dat gezegd zijnde opteer ik nu ook voor VeraCrypt voor nieuwe toepassingen, maar ik gebruik nog steeds TrueCrypt voor systemen die al encrypted waren. Algemeen genomen blijf ik wel bij mijn mening dat het beter is een open bron hiervoor te gebruiken. Dan KAN er tenminste controle plaatsvinden, ook al is het werk voor specialisten zoals je terecht opmerkt.

Iemand weet met zekerheid wie het truecrypt dev team was. Officiele statements zijn dus moeilijk vast te krijgen.
Verder is de consensus dat de statement op de site naar de toekomst verwijst, omdat het programma niet meer geupdate wordt.

Crypto programmas zijn notoir makkelijk te breken. Je moet zelfs niet altijd een backdoor inbouwen. De NSA heeft bv ooit RSA betaalt om te defaulten naar een bepaalde pseudorandom number generator. De fout zit hem vaak in die PRNGs die te weinig entropie vertonen en dus makkelijk te achterhalen wordt wat hun gecreeerde number is.

Dat soort fouten wordt vaak over het hoofd gezien (debian heeft daar naar t schijnt 2 jaar mee rond gelopen door een lijn code in zijn ssh implementatie te wissen). Een goed programma moet dus goed geaudit zijn. Meer potentiele coders wil niks zeggen, kijk maar naar de heartbleed bug in openssl, hoelang heeft dat er wel niet ingezeten (en die was dan nog ns super obvious)?

Vandaar dat een fatsoenlijk geaudit programma je wel wat extra beveiliging geeft, maar als je je wil beschermen tegen activiteiten van pakweg de NSA, dan heb je maar 1 oplossing: het niet online zetten.

[ Post made via mobile device ]

Ik blijf in elk geval nog gewoon TrueCrypt gebruiken. Om te beginnen heb ik geen data die zo top secret is, dat ik zelfs wil dat ze veilig is tegen NSA en consoorten. Het is eer een bescherming tegen toevallige vinders (bvb op USB stick) en curieuzeneuzen.
Overigens merkwaardig hoe die hele TrueCrypt situatie nog altijd even mysterieus is. Een van de theorieën was immers dat de identiteit van de makers wél achterhaald werd door NSA oid en ze onder bedreiging (ik weet niet meer omwille van welke act) dan maar zelf de stekker eruit getrokken hebben.

Tomby schreef:Een van de theorieën was immers dat de identiteit van de makers wél achterhaald werd door NSA oid en ze onder bedreiging (ik weet niet meer omwille van welke act) dan maar zelf de stekker eruit getrokken hebben.

Zoiets lijkt mij zeer plausibel.

In ieder geval waarschijnlijker dat ze, zonder details te geven, ineens de stekker eruit trekken omdat hun code niet te vertrouwen zou zijn.
De eerste audit was net achter de rug en heeft geen beveiligingsfouten kunnen vinden. Daarnaast was TrueCrypt al vele jaren zowat dé OSS encryptie oplossing. Het zou me verwonderen mochten beveiligingsonderzoekers de kans zouden laten liggen hebben om kritiek te geven mocht de code lekken bevatten.