Full System Encryption - Free CompuSec - TrueCrypt - Update 09.03.08

Sry für OT:

.. informier Dich mal, warum das WinPW mehr als 14 Stellen haben sollte ..
Weils unnötig ist? Du kannst doch alle Daten problemlos mit nem NTFS Reader unter "DOS" auslesen und auf ne FAT32 Platte schieben, die sich mit den Sicherheitsmerkmalen von NTFS den ...

Ich mein, wieso also ein "sichereres" Windows Passwort, wenn man eh problemlos in wenigen Sekunden an alle Daten kommen kann? :hmm:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
genau DAS hat er wohl nicht so ganz verstanden :)
aber über nen reader in DOS ist umständlich
 
So, ich hab nun ne Zeit lang über Truecrypt gelesen und wollte auch mal damit rumspielen. Ein paar grundlegende Fragen dazu habe ich aber.
Bei besagten "hidden containern" muss man den äußeren Container mit FAT formatieren. Wieso? Ist es egal mit welchem Dateisystem ich den inneren formatiere? Unterstützen die Cryptsysteme ala AES, Twofish ect. DualCore CPUs, so das die Leistung beim "o-t-f" ent/verschlüsseln auch genutzt werden kann? Ist die Festplattenleitung einzig CPU limitierend?


Dann noch was aus unserer Vergangenheit und Gegenwart, weil es mich einfach interessiert!

Ich habe noch im Hinterkopf das früher Verschlüsselungssoftware aus den USA nur als stark entschärfte Versionen ins Ausland verkauft werden durften, was auch für die Browser galt. Ich glaub dort waren es schon lange 128bit, während uns 64bit aufgezwungen wurden.

a) Wieso wurde so verfahren?
b) Inwiefern existieren noch heute Beschränkungen für den Crypt-Mark in den USA? (Quellcode Offenlegungspflicht oder sonst was ...)
c) Wieso wurde AES von den "AMIS" ausgewählt und wieso lief das ganze so "offen" ab? Wieso der Sinneswandel? Wo ist der Haken für uns bzw. Vorteil für die Amis? ;)

@axte.x:
Funktionierte das ganze problemlos? Welche freien Programme eignen sich den jetzt zur Systemverschlüsselung und wie sieht es da eigentlich mit System Images / Backups aus? :fresse: ;)

Kann nicht mal jemand ne Kombi aus Truecrypt, Compusec und Acronis Drive Image erfinden? :fresse: ;)
 
Zuletzt bearbeitet:
a) Wieso wurde so verfahren?
b) Inwiefern existieren noch heute Beschränkungen für den Crypt-Mark in den USA? (Quellcode Offenlegungspflicht oder sonst was ...)
c) Wieso wurde AES von den "AMIS" ausgewählt und wieso lief das ganze so "offen" ab? Wieso der Sinneswandel? Wo ist der Hacken für uns bzw. Vorteil für die Amis? ;)

Darüber kann man nur spekulieren. Wenn du dich etwas länger mit dem Thema "Verschlüsselung" auseinandersetzt, wird dir auffallen, dass fast jeder Algorithmus mit den USA in Verbindung zu bringen ist. Meistens liest man etwas wie: Die NSA steckt dahinter ... die haben für alles einen "Defaultkey" ... Der Key muss für den NSA knackbar sein ... usw. Ob was dran ist, musst du selbst entscheiden ;) Ich halte davon nicht wirklich viel.

Wenn ich mich recht entsinne, hat sich folgender Fall jedoch tatsächlich ereignet: Das Notebook eines USA Urlaubers sollte am Flughafen überprüft werden. Die Daten der Platte waren mit EFS verschlüsselt. Bevor der Reisende das PW nicht rausrückte, durfte er nicht einreisen. Was sagt uns das? Entweder reise nie mit HD in die USA oder eine Verschlüsselung bringt nichts, wenn du von jemandem gezwungen wirst, das PW rauszurücken ... :rolleyes:

Ich hoffe, dieser Thread verkommt jetzt nicht zum NSA / USA Spamthread ;) ...

Greetz

NetworkerZ
 
Zuletzt bearbeitet:
@NetworkerZ:

a und b sollte man auch ohne Spekulationen beantworten können, nur leider hab ich das Wissen schon wieder vergessen. :fresse: Genaueres dazu finde ich aber leider nicht mehr. :(

Kann vieleicht auch noch jemand etwas zu meinen anderen Fragen sagen? Vor allem wie das bei nem komplett verschlüsselten System mit Images usw. ablaufen soll, ist mir ein Rätsel. Wahrscheinlich gar nicht, oder? :confused:

Und halt die Fragen bezüglich hidden container bei Truecrypt.
Hinzugefügter Post:
Kleiner quote aus dem protectus Forum, wo es um "Twofish oder AES" ging:
Rijndael, derzeitiger AES (Advanced Encryption Standard) bereitet einigen Kryptologen mehr als Bauchschmerzen.

- Die Verwendung von nur 10 Runden fuer einen 128 Bit Schluessel bei recht einfachen Rundenfunktionen ist recht nah am Limit.

- Kritisch ist die einfache algebraische Beschreibung der S-Boxen, die ihrerseits die einzige nichtlineare Komponente der Chiffre sind.

- Rijndael verfuegt ueber eine sehr schwache Key Schedule. Mit Kenntnis eines Rundenschluessel kann man trivial 128 Bit des Verfahrensschluessels gewinnen.

- Die einfache mathematische Struktur die Rijndael beliebt gemacht hat birgt auch ihre Gefahren. So ist es bereits 2001 gelungen die gesamte Chiffre als überraschend einfache, geschlossene mathematische Formel darzustellen. Entscheidend waren dort die oben erwaehnte einfache algebraische Beschreibung der S-Boxen.

- Rijndael ist vermutlich verwundbar gegenueber dem XSL-Angriff. Bei einer Schluessellaenge von 256 Bit sind ca. 2^200 Operationen noetig was es derzeit nicht praktikabel macht. Realistisches Limit sind Augenblicklich ca 2^90 fuer finanziell wirklich gut ausgestattete Angreifer. Aufgrund dieser Tatsache ist es im Augenblick nichtwirkllich verifizierbar, kann Rijndael aber in wenigen Jahren das Genick brechen.

Die meisten Kryptologen halten Twofish fuer wesentlich robuster.

Zur AES-Standardisierung ist noch anzumerken das Mars, RC6, Rijndael, Serpend (Ebenfalls potentieller Kanidat fuer einen XSL-Angriff) und Twofish in die engere Auswahl gekommen sind. Twofish haette gute Chancen gehabt haette man sich nicht von dem blenden lassen, das Rijndael heute eher fragwuerdig dastehen laesst. Richtig schnuckelig war die von der Deutschen T(tm)elekom vorgestellte Submission mit dem einfallslosen Namen Mangenta die schon waehrend des Vorstellungstages gebrochen wurde.

Ich wuerde zum Einsatz von Twofish raten. AES ist zwar generell immernoch sehr sicher - aber es tun sich so grosse Risse auf das man zumindest ein wenig beobachtende Haltung, anstatt vertrauender Einnehmen sollte.
Quelle: http://board.protecus.de/t6188-2.htm

Da Twofish noch deutlich schneller ist ...
Rijndael hat wohl nur, sofern stimmt was der gute Mann schreibt, aufgrund der einfachen Integration die Ausschreibung gewonnen.

EDIT:
Noch nen Link:
http://www.cryptolabs.org/aes/WeisLucksAESattacksDS1202.html

Er hat wohl Recht mit dem was er schreibt. ;)


Ma ne theoretische Frage:

- CompuSec full System encryption @System
- externe Platte mit truecrypt Container (20gb unverschlüsselt freigelassen)

Mit der Acronis boot CD nen Image anlegen und halt auf den unverschlüsselten Speicherplatz der Platte hinterlegen. Das müsste ja_eigentlich_gehen, sofern Acronis RAW Images anlegt (also einfach 1:1 Images macht, egal ob das nun "erkannt" wird, oder nicht).

Frage: KANN Acronis Images von verschlüsselten Partitionen (ink. Bootbereich) 1:1 anlegen? Also als Rohdaten Image?

Kann das bitte mal jemand testen, der CompuSEC im einsatz hat und im Besitz von Acronis und ner externen Platte ist? Das wäre natürlich die ideale Lösung, in meinen Augen.

FSE, externe verschlüsselte Platte, die man mitnehmen kann und automatisch verschlüsselte Images, da 1:1 Image einer verschlüsselten Partition, die man aber von ner stink normalen BOOT CD wieder einspielen kann. :love: :bigok:
 
Zuletzt bearbeitet:
@NetworkerZ:
Das mit dem "Default key" der NSA könnte ich mir bei proprietären Lösungen, die aus den USA stammen, noch vorstellen, aber bei OpenSource-Lösungen ist diese These nicht haltbar.
 
Kann keiner was zu meinen Fragen sagen? Für was sind eigentlich die HASH Funltionen innerhalb der Verschlüsselungstechnologie und inwiefern ist ein "schlechter" HASH Algorithmus eine Gefahr? SHA-1 ist ja theoretisch schon mit 2^63 knackbar (oder heute noch weniger ...).

Nur für wat ist die HASH Funktion genau?
Hinzugefügter Post:
EDIT:
Ach ja, die HDD Benchis vom Threadersteller sind wertlos. HD-Tach misst bei mir, verständlicherweiße, 0,00 Unterschied.
Bei ihm muss da irgendetwas schief gelaufen sein. :-[
 
Zuletzt bearbeitet:
Für was braucht man "Hidden Container"?
Mach einfach einen "normalen" Container, erfüllt doch voll seinen Zweck.
Und man hat das Ganze auch schnell wieder gelöscht.


Und das jeder Algoritmus eine Backdoor hat ist doch sehr weit hergeholt.
Solange es solche Leute wie Bruce Schneier gibt wird das nicht passieren.
Ich verwende auch Truecrypt mit Twofish und normaler Containerdatei. Läuft absolut zuverlässig. Bootlaufwerk lasse ich unangetastet. Für mich nicht nötig. An die Partitiontabellen lasse ich so ein Tool auch nur ungern ran.
 
Was ist eigentlich "besser" (sicherer / schneller). Twofish oder Blowfish?
Hat die Blockgröße (BF hat 64bit und TF 128bit) direkten Einfluss auf die Sicherheit?
Für welche Hashfunktion hast du dich entschieden? Whirlpool oder ri...-160?

Und Truecrypt für die externe Platte ist ja schon und gut, nur ist es für die internen Platte sehr nervig. Wenn ich z.B. ne interne Partition verschlüssele, so muss ich die trotzdem noch zusätzlich mounten, anstatt sie einfach per pw "freischalten" zu können.

Das suckt nen bissel, wodurch ich auf den Gedanken mit der FSE gekommen bin.
 
RIPEMD wird derzeit empfohlen, stand jedenfalls noch vor Wochen so auf der Truecrypt Seite.
Twofish ist neuer und indirekt auch eine Weiterentwicklung von Blowfish.
Aber sich darüber nen Kopf zu machen ist eh überflüssig. An die Daten kommt ohne Passwort keiner ran egal welchen Algorithmus man wählt.
 
@ttom:
Wieso RIPEMD-160 und nicht Whirlpool? Welchen Grund für diese Empfehlung gibt es und welcher Algorithmus wird dort empfohlen?

Frage: KANN Acronis Images von verschlüsselten Partitionen (ink. Bootbereich) 1:1 anlegen? Also als Rohdaten Image?

Kann das bitte mal jemand testen, der CompuSEC im einsatz hat und im Besitz von Acronis und ner externen Platte ist? Das wäre natürlich die ideale Lösung, in meinen Augen.

FSE, externe verschlüsselte Platte, die man mitnehmen kann und automatisch verschlüsselte Images, da 1:1 Image einer verschlüsselten Partition, die man aber von ner stink normalen BOOT CD wieder einspielen kann. :love: :bigok:
Hier haben doch nen paar CompuSEC im Betrieb und keiner meldet sich? :-[ :heul:
akte.x hat sich ja leider auch nicht mehr gemeldet. :-[
Hinzugefügter Post:
EDIT:
Wo bekomm ich eigentlich das CompuSEC Handbuch her? Da steht nur "coming soon" ... seit fast nem halben Jahr ... :fresse:

Nen TrueCrypt Handbuch auf Deutsch wäre auch nicht verkehrt. :-[
 
Zuletzt bearbeitet:
Da steht zum Algorithmus rein gar nichts. :-[
Und das Thema hier scheint ja (leider) keinen zu interessieren. Zudem find ich es schade, dass die Leute, die CompuSEC schon im Einsatz haben, rein gar nichts zu Acronis und co sagen. :-[

Dann muss ich es wohl nach dem try & error Prinzip testen. Und nen Handbuch find ich auch net ...:wall:
 
@axte.x:
Funktionierte das ganze problemlos? Welche freien Programme eignen sich den jetzt zur Systemverschlüsselung und wie sieht es da eigentlich mit System Images / Backups aus? :fresse: ;)

Kann nicht mal jemand ne Kombi aus Truecrypt, Compusec und Acronis Drive Image erfinden? :fresse: ;)

Hi,

habe Compusec für die Systemverschlüsselung (Intel RAID 0) und Drivecrypt für die Datenplatte im Einsatz. Acronis ist meines Wissens kompatibel zu Compusec.

Was ich jedoch auf meinem Zweitrechner (ist auch verschlüsselt ;) )festgestellt habe, ist das Filesharing-Programme mit gemounten Platten Probleme haben --> LowID usw.
 
@akte.x:
Hast ne PM. :)

@all:
Ich hab gerade eben nen full Backup gemacht und wollte nun mal CompuSEC testen, aaaaabbbeeerrrr es gibt kein deutsches Handbuch und das englische ist auch recht sparsam, was die einzelnen Funktionen betrifft.

Tolle wurst ...

EDIT:
4. Question Wie lange dauert die Verschlüsselung bei einer 40GB IDE Festplatte?

Abhängig von der Verschlüsselungsmethode dauert diese ca. 2,5 Stunden (Hintergrundverschlüsselung) oder bis zu 8 Stunden (Initialverschlüsselung vor dem Start).
WIESO ist die Hintergrundverschlüsselung soviel schneller? Wie kann das Prog überhaupt die Files verschlüsseln, mit denen ich gerade arbeite? :hmm:

Das ganze rennt gerade und soll laut Anzeige um die 4 Stunden dauern. Da bin ich ja mal gespannt ... ^^ (Ich Depp bin müde wie sau und hätte das mal besser über n8 gemacht *g*)
 
Zuletzt bearbeitet:
So, CompuSEC lüppt @RAID 0! :) Die ganze Aktion hat um die ~4h gedauert und der spürbare Performanceeinbruch ist sehr gering. Anders gesagt: Man merkt es nicht wirklich. ;)

Am WE testet akte.x noch meine Idee mit Acronis und wenn das funktioniert, wäre es natürlich nen ideales System. Verschlüsseltes Syste, verschlüsselte Images (die man trotzdem von Boot CD aus wieder einspielen kann, da sie auf unverschlüsseltem Space liegen) und nen verschlüsseltes (externes) Datengrab. :bigok:
 
Ich weiß ja das dieses Thema hier keine Sau interessiert, aber falls sich doch mal ein User mit Interesse hier her verirren sollte:

- CompuSEC funktioniert auf meinem RAID 0 problemlos
- Wenn ich Acronis per boot CD starte und nen Image ziehen möchte, meckert es und sagt "Partition hat Fehler, bitte reparieren, sonst muss ich "leider" Sektor für Sektor lesen" -> :hail: -> 1:1 Image einer verschlüsselten Partition ist kein Problem! Funzt einwandfrei.

Nachteil: 15GB Partition == 15GB Image ;)

- Wenn meine eS-ATA Platte vorm booten am System ist, gibt es kurz vorm Windows Start nen BSOD (immer). Das Problem liegt an CompuSEC, welches scheinbar keine unverschlüsselte Platte im System möchte. :rolleyes: Der Bug nervt nen bissel, aber damit kann ich leben.

Die Platte unter Win anzuklemmen funzt einwandfrei und TrueCrypt ect. geht auch einwandfrei. :)



ATM sieht es also so aus:

- RAID 0 mit Windows und mehreren Partition mit CompuSEC komplett verschlüsselt, inklusive pre-boot Anmeldung.
- Externes Datengrab mit nem TrueCrypt Container versehen und noch 20GB freien, unverschlüsselten, Speicherplatz gelassen
- Per Acronis ein 1:1 Image der verschlüsselten Windows Partition auf dem unverschlüsselten Space der externen Platte angelegt -> Ich kann nun per Boot CD(!) meine verschlüsselte Startpatition wiederherstellen, falls es mir mal mein Windows zerballert und trotzdem ist alles verschlüsselt, selbst das Image. ;)

Fazit: :bigok: (auch wenns unnötig ist ... :fresse: )

EDIT:

O M F G! Über 1500 Views und fast keine Posts. :hmm:
Ich sags ma so ... die Leute, die nichts posten, obwohl es sie interessiert, sind entweder paranoid²³, oder haben wirklich etwas zu verbergen. :fresse: ;)
 
Zuletzt bearbeitet:
@Mr.Mito
Warum lässt du Acronis nicht einfach unter Windows laufen und die Platte sichern? Ich habe es zwar nicht ausprobiert, aber so sollte ein normales Image der Systempartition möglich sein.
 
Dann ist das Image aber unverschlüsselt und ich will nicht wissen, welche Probleme es dadurch beim wiederherstellen gibt, da dann die Bootpartition auf einmal ohne Verschlüsselung dasteht. ;)

Klar, wenn ich das ganze unter Windows (bzw. nach Boot PW Eingabe) wiederherstelle, sollte das keine Probleme bereiten, aber ich will ja nen Image, das ich von CD einspielen kann, eben wenn mein BS komplett hinüber ist.
 
Zuletzt bearbeitet:
Ich glaube nicht, dass das Image dann unverschlüsselt ist. Es wird ja das gesamte System, so wie es gerade ist, gesichert. Aber das müsste man mal ausprobieren.
 
Und das System wird ja, im laufenden Betrieb, on the fly entschlüsselt. Dadurch sollte auch das Image unverschlüsselt sein. Wenn ich unter Windows irgendwelche Files auf ne Diskette kopiere, sind die ja auch unverschlüsselt (es sei denn ich sag er solls verschlüsseln).

PS:
Das Rückspielen des verschlüsselten Images scheint den CompuSEC MBR zu killen, zumindest laut akte.x. :(
EDIT: Nen MBR Backup kann man sich allerdings anlegen und es gibt auch nen Tool zum rückspielen, laut der Yahoo Compusec Techgroup.

Danke hierfür an Akte.X! :)

Also müsste folgender Ablauf funktionieren:

- Acronis Backup einspielen
- MBR wiederherstellen mit dem CompuSEC MBR Backup

Ist zwar stressig, aber nen Image braucht man auch nur seeeehr selten.
 
Zuletzt bearbeitet:
@xe3tec
Damit dieser "Bug" zum Tragen kommt, musst du selbst den Container angelegt, das erste Passwort vergeben und danach den Volume-Header gesichert haben. Wenn nun das Passwort zwischenzeitlich geändert wurde kannst du, und nur du, das so wieder rückgängig machen. Da du deinen Rechner sicherlich nicht von einer dir höher gestellten Person administrieren lässt, der dir deinen Rechner konfiguriert und die Container eingerichtet hat, ist das für den Heimanwender belanglos.
 
jo trotzdem, no app is perfekt ;)

wer weis was noch für bugs gibt :) ich denk da grad an paar nette ideen in bezug auf HEX
 
@xe3tec:
Die "Bug" steht sogar in der FAQ zu TrueCrypt und "It´s not a bug it´s a feature!". ;)
Jetzt sag mir mal wo da das Sicherheitsrisiko liegen soll. Da besteht nur ein Sicherheitsrisiko wenn dir ein fremder an deinem PC den Container anlegt, ein PW vergibt und den Ursprungsheader sichert, bevor du das PW änderst. Die Funktion hat auch einen tieferen Sinn, denn Windows zerhaut dir in manchen Konstellationen gerne mal den Volumeheader und ohne Backupmöglichkeit ... :rolleyes:

Wenn DU den Container anliegt, kann das also nicht passieren und DU hast eine Möglichkeit den Header zu sichern. ;)

PS:
Das Video is nen Witz. Wo "crackt" der denn bitte was? Das HEX rumgefummel ist auch total überflüssig. Den "alten Header" kannste auch mit Truecrypt ganz einfach einspielen. :rolleyes:
 
Zuletzt bearbeitet:
Jap das video ist doch nur auf so einer Seite wo sich die Leute gerne wichtig machen und denken sie wären die größten.
Sieht man ja an dem Video das ist doch schon bekannt...^^
 
@xe3tec
Hast du auch das gelesen?
Dass sich das Administratorpasswort eines Systems so leicht überschreiben lässt, wenn man den PC mit einer Boot-CD startet, ist eigentlich keine Sicherheitslücke und auch kein Vista-spezifisches Problem. Grundsätzlich gilt: Wenn ein Angreifer physischen Zugang zum Rechner hat und ein anderes Betriebssystem booten kann, sind auch Passwörter keine Hürde mehr für ihn – solange keine Verschlüsselung im Spiel ist.

/Edit
Auf Golem.de gibt es eine ähnliche News: klick!

Wie du nun sehen kannst, sind auch andere Programme nicht unbedingt davor geschützt, den Passwortschutz ausgehebelt zu bekommen. Wobei das meiste wohl über ein Brute Force Attacke realisiert wird. Und das kann dauern. ;)
 
Zuletzt bearbeitet:
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