Ungeknackte/unknackbare Verschlüsselung für Daten

meiner einer hat sich zum einen für ne Full System Encryption (FSE) von CE entschieden.

Klar, lässt sich drüber streiten, ist closed Software, aber ich wollte halt auch gern meine Systempartition verschlüsselt haben, inklusive verräterischem Swapfile.

Die datenpartition ist dann zusätzlich mit nem Truecrypt container (passwort+ keyfile(s) wo die keyfiles wiederum auf einem anderen medium in einem anderen truecrypt container mit anderem passwort zu finden sind) versehen. Das ganze könnte man dann noch mit nem Hiddenvolume steigern.

Ich denke das das System dadurch schon verhältnismässig sicher ist. Grade die Kombination von verschiedenen Systemen machts nochmal schwieriger.

und wie gesagt, da es n Laptop ist wollte ich gleich im Bootloader die Passwortabfrage... ich hoffe das TrueCrypt auch mal zu einer FSE lösung heranwächst.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Später möchte ich es ja so machen das wenn ich wo anders bin mit der Platte einfach mein USB-Stick reinstecke mit TrueCrypt drauf und dem Keyfile und ich dann so an meine Daten komme.

Gibt es da von eurer Seite aus irgendwas zu beachten?

gerade deshalb würde ich aus bequemlichkeitsgründen zum container tendieren (so hab ichs gemacht).. die platte hat eine partition (unverschlüsselt), auf der eine containerdatei liegt, die fast die gesamte größe der platte hat.. zusätzlich liegt (im unverschlüsselten bereich) eine mobile truecrypt-version mit autorun drauf.. steck ich die festplatte nun an einen anderen rechner an, öffnet sich automatisch die truecrypt-eingabeaufforderung fürs passwort (da der pfad zur containerdatei in der autorun.inf angegeben wird)..

verschlüsselt man die ganze partition, wirds mit dem autorun nicht gehen, d.h. man muss jedes mal die partition, die gemountet werden soll, in truecrypt manuell auswählen.. außerdem hat man bei der container-methode truecrypt immer mit (klar, wenn du ein keyfile hast, kannst du truecrypt mit auf den USB-stick packen, bleibt aber immernoch der umstand mit dem manuellen partition-auswählen)..

also wie gesagt, partition verschlüsseln ist die "saubere" methode bei fest installierter platte, aber wenn man sie zumindest regelmäßig an anderen rechnern anschließt, ist es mit dem container bequemer - und außerdem kannst du so auch schnell mal unverschlüsselte daten auf derselben platte transportieren (wenn du beim festlegen der containerdatei 1-2GB dafür übriglässt)..
 
Zuletzt bearbeitet:
Ja das stimmt natürlich wenn alles dann so auf der platte mit drauf ist, aber es wäre doch schon wegen dem Keyfile sehr schön. Oder ist das eh nicht so wichtig mit dem Keyfile?

Wobei man könnte ja auch eine Datei die im TrueCrypt Ordner ist, als Keyfile benutzen.
 
ein keyfile, das offen zugänglich ist, ist vielleicht nicht die beste lösung :d
ein keyfile ist sowas wie ein sehr langes passwort, das genauso geschützt werden sollte.. der vorteil gegenüber einem passwort liegt in der länge und in der "beliebigkeit" (systematisches bruteforce mit wörterbüchern o.ä. ist unmöglich)..
ob das in der praxis wesentlich sicherer ist als ein gutes passwort, darüber lässt sich streiten.. ich benutze es aus bequemlichkeitsgründen nicht..

wie dem auch sei - das was ich gesagt habe, gilt unabhängig davon, ob du ein keyfile benutzt oder nur ein passwort.. wenn du ein keyfile nutzt, solltest du es sicher aufbewahren, insbesondere nicht zusammen mit dem container :d

also nochmal, falls das irgendwie nicht klar wurde: wenn du eine containerdatei auf der platte erstellst und truecrypt als autorun mit draufpackst, kommt eine eingabeaufforderung, sobald du die platte anschließt.. und je nach dem ob du ein keyfile benutzt oder nicht, musst du halt den pfad vom keyfile angeben (USB-stick o.ä.) oder nur ein passwort eingeben..
 
Zuletzt bearbeitet:
Ja verstanden hab ich das soweit mit dem Container. Wäre halt eigentlich schon extrem geil, wenn automatisch nen Fenster hochpoppt und mich nach Passwort fragt und der Rest dann von selber läuft, meine Frage wäre da halt nur ob das wirklich sicher genug ist, oder ob die Keyfile Lösung nicht doch noch ne Ecke besser ist.
 
Ihr habt auch alle an ein Backup gedacht ? Denn wenn irgendwas nicht klappt mit dem Container, könnt ihr die Daten auf jeden Fall komplett vergessen.
 
Naja, ich würde sagen man muss mit dem Risiko dann leben, außer man macht die Backups und verschließt sie in nen Safe oder gleich in ein Bankschließfach.

Weil sonst wäre ja die ganze Verschlüssung für den Arsch, wenn man sich nur die Backup Platte krallen muss um an die Daten zu kommen.
 
so isses.. entweder sicherheit oder - sicherheit :d

was passwort vs. keyfile betrifft: die key-länge, ab der sich bruteforce nicht mehr lohnt, ist nicht besonders groß.. rechnungen dazu stehen im thread und in der wikipedia ;)
das ist die gleiche diskussion wie 10 zeichen vs. 100 zeichen passwortlänge - in der praxis ist das ziemlich egal, auch wenns theoretisch sicherer ist mit mehr zeichen.. man darf nur kein passwort nehmen, was per wörterbuch evtl. schneller knackbar ist..
also alles in allem würd ich sagen, keyfile ist was für paranoide :d
 
Also sprich, nen längeres Passwort mit 10 Zeichen aufwärts, mit nen paar Sonderzeichen, Groß- und Kleinbuchstaben ist sicher genug.
 
Ihr habt auch alle an ein Backup gedacht ? Denn wenn irgendwas nicht klappt mit dem Container, könnt ihr die Daten auf jeden Fall komplett vergessen.
das stimmt nicht. in sich selbst ist der container genauso gut / schlecht vor beschädigungen geschützt wie ne normale platte. sprich, wenninnerhalb des containers daten beschädigt sind, bleibt es dabei.

das einzige was deinen container zerstören kann ist ein fehler in er (ich glaube 1024kb) großen headerdatei. und letztgenannte lassen sich ganz bequem auf cd-r sichern. somit wäre eine rücksicherung problemlos möglich
 
Sehr gut! Hab mir auch schon eins ausgedacht was ich mir merken kann^^, mit genau 21 Zeichen (groß, klein, zahlen und sonderzeichen).
 
Wenn auf Grund irgendeiner kleinen Beschädigung Truecrypt nicht mehr ran will an den Container, steht man aber ziemlich dumm da - solange bis jemand ein Tool oder Bugfix gemacht hat, welches genau dieses Problem behebt oder umgeht. Irgendwelche gängigen Reparaturtools für unverschlüsselte Platten helfen da definitiv nicht.

Ob die Sicherung der Headerdatei dann hilft, hängt von dem konkreten Fehler ab.

Helfen würde da ein 2. Container auf ner anderen (am besten externen) Platte mit den gleichen Daten.
 
naja, ein beliebiger bitfehler im container macht nicht den ganzen container unbrauchbar, sondern nur den entsprechenden sektor, d.h. der schaden ist immer eingeschränkt..
im header ist das gefährlicher, auf den sollte man besser aufpassen.. davon abgesehen ist ein voll-backup nicht mehr oder weniger sinnvoll als bei einer normalen platte, der container ist also nicht mehr gefährdet als die platte selbst..
 
wie sieht das ganze eig dann bei raid verbänden mit hardwarecontroller aus ?
wenn da mal ne platte ausfällt gibt es da probleme die auftreten können ?

mfg
 
Wenn eine Platte ausfällt sind alle Daten weg. Da ist dann auch nichts mehr mit wiederherstellen.
 
wie sieht das ganze eig dann bei raid verbänden mit hardwarecontroller aus ?
wenn da mal ne platte ausfällt gibt es da probleme die auftreten können ?

mfg

kommt aufs raid an, bei nem raid5 kann ne platte ausfallen, bei nem raid5 mit hotspare 2 platten...

man kann damit schon ne recht gute verfügbarkeit gewärhleisten, sollt aber n zweiten identischen controller zur hand haben, dich das der dann der single point of failure ist.
 
kommt aufs raid an, bei nem raid5 kann ne platte ausfallen, bei nem raid5 mit hotspare 2 platten...

man kann damit schon ne recht gute verfügbarkeit gewärhleisten, sollt aber n zweiten identischen controller zur hand haben, dich das der dann der single point of failure ist.

aber nur wenn die beiden platten nicht gleichzeitig ausfallen - was durchaus vor kommen kann (wenns system alt ist -> alle platten gleich alt -> eine ausfällt -> und alle anderen einmal rebuilden auf ne hotspare)

bei raid6 können 2 platten gleichzeitig ausfallen
 
klar, lässt sich auch noch steigern, wollt ja nur n beispiel bringen, dass n raid durchaus sicherheit bieten kann.

wem das nicht reicht findet sicher auch ne backuplösung welche die bänder verschlüsselt.
 
Ich glaube meine Frage ist nicht ganz richtig angekommen. Ich meinte wie es aussieht mit einer derartigen Verschlüsselung via truecrypt, wenn man die komplette ( in meinem Fall unter linux ) RAID-Partition verschlüsseln lässt und dann eine der Platten ausfällt. Das bei einem RAID-5 nur eine ausfallen sollte ist mir schon klar. Dachte eher, dass es da ggf. Probleme beim wiederherstellen gibt, auf Grund der Verschlüsselung oder ist das für den RAID-Controller ( in meinem Falle Promise EX8350 ) eher unbedeutend.

mfg
 
@avanger das raid läuft ja normalerweise auf hardwareebene, s.h. das es der platte egal ist ob die daten verschlüsselt sind, der controller so wie die platten sehen eh nur 1 oder 0. die ver und entschlüsselung findet ja vorher im prozessor statt.
 
@avanger das raid läuft ja normalerweise auf hardwareebene, s.h. das es der platte egal ist ob die daten verschlüsselt sind, der controller so wie die platten sehen eh nur 1 oder 0. die ver und entschlüsselung findet ja vorher im prozessor statt.


-> der grund ist schlicht die art wie raid 5 arbeitet (a+b=c -> fällt eins weg lässt sich durch relativ leichtes "rechnen" das weggefallene widerherstellen - einfach ausgedrückt)
wo die daten ver und entschlüsselung werden hat das nichts zu tun
 
Eine 256bit Twofish Verschlüsselung mit Passwort mit 15Zeichen (Buchstaben, Zahlen, Sonderzeichen durchmischt) sollte recht sicher sein und somit "quasi" unknackbar. (Natürlich in Relation auf Zeit).
 
wie sieht es aus mit
SafeGuard

komplett verschlüsselüng mit Pre Boot und einem

Etoken?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh