Archiv verlassen und diese Seite im Standarddesign anzeigen : TrueCrypt: Aes, Serpent oder Twofish?
Welcher Algorhytmen ist eurer Meinung nach der beste und warum?
Für mich ist es twofish es waren äusserst versierte Leute beteiligt und er ist von vornerein drauf ausgelegt unbekannten Attacken was entgegenzusetzen.
Was habt ihr zu bieten?
Algorithmus, Algorithmen.
Twofish und Serpent sind wohl beide sicherer als Rijndael, aber nicht wirklich relevant. Sie sind auch etwas langsamer.
Jeder der 5 Cypher der AES-Endrunde ist nach heutigen Maßstäben wohl unbeschränkt zu empfehlen.
Philipus II
2009-11-04, 22:01:13
Als vollkommen paranoider Mensch habe ich meine Festplatte mit allen 3 gesichert:biggrin:
Bei den heutigen CPUs ist das recht flott und verbindet alle Vorteile.
Also laut Wiki ist AES der schnellste, TWOFISH der sicherste, wobei AES wohl die beste Performance für die Gebotene Sicherheit liefert. Da es ja AES ist (also der Advanced Encryption Standard der NSA usw) macht man damit sicher nichts falsch.....
Als vollkommen paranoider Mensch habe ich meine Festplatte mit allen 3 gesichert:biggrin:
Das ist nicht paranoid, sondern ziemlich dämlich. Brute-Force-Cracking wird dadurch auch nicht wesentlich langsamer (nur linear), und es ist nicht einmal gesagt, ob du damit nicht sogar noch irgend eine Schwachstelle auftust die man kryptoanalytisch ausnutzen könnte.
Viel wichtiger ist ein anständiges langes Passwort oder ein wirklich randomisierter Private-Key auf einem Stick.
Tesseract
2009-11-05, 00:27:00
serpent würde ich nicht nehmen weil es verhältnismäßig langsam ist.
ansonsten sind alle 3 selbst für absolut paranoide leute bei weitem sicher genug.
sicherheit/performance wäre twofish wohl sogar der beste da er doch "deutlich" sicherer als AES, aber praktisch nicht langsamer ist.
Tesseract
2009-11-05, 00:44:22
Brute-Force-Cracking wird dadurch auch nicht wesentlich langsamer (nur linear), und es ist nicht einmal gesagt, ob du damit nicht sogar noch irgend eine Schwachstelle auftust die man kryptoanalytisch ausnutzen könnte.
wenn alle 3 verschiedene passwörter verwenden kann das doch garnicht passieren. abgesehen davon verwendet man cascading ja auch nicht um bruteforce-attacken zu erschweren sondern um sich gegen das (allerdings nahezu ausgeschlossene) komplette umfallen eines der algorithmen abzusichern.
sinn macht es trotzdem nicht wirklich. :D
Philipus II
2009-11-05, 18:56:28
@Coda: Die Länge das Passworts halte ich für ausreichend.
Die Passwortlänge liegt zwischen 38 und 45 Stellen (die genaue Länge wird aus Sicherheitsgründen geheimgehalten). Gegen einen Bruteforceangriff aufs Passwort halte ich mich daher für ausreichend gesichert.
Es enthält keine Wörter und Namen. Daher wird eine Wörterbuchattacke zu wenig Erfolg führen.
Ein Angriff über Algorythmus ist eine theoretische Option, durch die Kaskadierung wäre es aber schon verdammt viel Pech, wenn bei allen dreien ernste Lücken gefunden werden.
Bleiben also nur noch Trojaner und Folter...
Ist dieses "Algorythmus" ein Crack-Programm oder so? ;-)
wenn alle 3 verschiedene passwörter verwenden kann das doch garnicht passieren
Tun sie bei TrueCrypt aber nicht.
Ein Angriff über Algorythmus ist eine theoretische Option, durch die Kaskadierung wäre es aber schon verdammt viel Pech, wenn bei allen dreien ernste Lücken gefunden werden.
Algorithmus. Das kommt nicht von Rhytmus.
Und ich habe dir doch gerade erklärt, dass gerade durch die Kaskadierung evtl. andere Lücken auftreten. Es ist einfach Quatsch. Twofish allein reicht völlig.
Tesseract
2009-11-05, 22:24:45
Tun sie bei TrueCrypt aber nicht.
ich könnte schwören bei einer früheren version kamen 3 passwortabfragen. seltsam.
das steht in der doku:
"Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent too, even though they are derived from a single password"
reallord
2009-11-06, 00:02:20
...
Algorithmus. Das kommt nicht von Rhytmus.
...
Rhythmus
scnr :tongue:
Aber recht hat Coda dennoch, Du gibst beim mounten doch nur ein PW ein und nich 3 hintereinander...
An sich wär das ja schon ne tolle Idee, jeden Algo mit eigenem PW sichern. Aber wenn man dann komplexe PWs mit 38-45 Stellen hat und das 3x.
Wer gibtn dass dann überhaupt noch von Hand ein?
Der_Donnervogel
2009-11-06, 00:54:28
Aber recht hat Coda dennoch, Du gibst beim mounten doch nur ein PW ein und nich 3 hintereinander...Vielleicht hat er 3 Truecryptcontainer geschachtelt. Also nachdem er das erste Passwort eingibt, befindet sich im gemounteten Laufwerk nur ein zweiter Container (mit anderer Verschlüsselung und anderem Paßwort) den er auch mountet, und in dem sich dann ein dritter Container (wieder mit anderer Verschlüsselung/Paßwort) befindet. Am besten gleich noch jeweils als Hidden Volumes. ;)
... wobei man sich da schon fragen muss ob das nicht "etwas" übertrieben ist. Hat der eine Selbstbauanleitung für Atombomben am PC oder was kann so geheim sein, dass eine der Verschlüsselungsarten nicht ausreicht? Vor allem stellt sich die Frage ob der PC denn gegen andere Angriffe, vom Trojaner bis zu Side Channel Attacken so gut gesichert ist, dass sich der Aufwand bei der Verschlüsselung lohnt. Ich will mal hoffen das ist ein Inselsystem das in einem atomsicheren Bunker im Keller steht und über ein eigenes Aggregat mit Strom versorgt wird. Nicht dass noch jemand z.B. über EM-Abstrahlung die Passworte auslesen kann ... ;D
Rhythmus
d'oh :usad:
ich könnte schwören bei einer früheren version kamen 3 passwortabfragen. seltsam.
das steht in der doku:
"Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent too, even though they are derived from a single password"
Hm okay, dann ist es wohl so.
(del)
2009-11-06, 23:11:53
Da es ja AES ist (also der Advanced Encryption Standard der NSA usw) macht man damit sicher nichts falsch.....Man macht aktuell zwar mit AES aka Rijndael zwar nichts falsch, auch wenn ich persönlich wo es geht Twofish nehme, aber Rijndael ist kein "AES der NSA". Es ist auch kein Standard der NSA.
Ich werde es wohl nie begreifen wie Leute die lesen und schreiben können auf die Idee kommen sich etwas auszudenken und es als gegeben hinstellen :|
Was die NSA als Standard jeweils und in welchem Masse benutzt und aus was das alles besteht ist nicht bekannt. Was sie selbst veroffentlichen ist eine Empfehlung aka Standardregelwerk an die Streitkräfte und Institutionen der USA. Es ist eine Ansammlung von Methoden (Algorithmen und Implementierungsmethoden, wobei viel davon mit Patenten der eigenen Firma Certicom Inc. belegt ist). Das nennen sie Suite B und die ist offentlich.
Suite A ist nicht offentlich bekannt und ist ebenfalls ein Standardregelwerk für Informationen oberhalb von TopSecret:
"Another suite of NSA cryptography, Suite A, contains some classified algorithms that will not be released. Suite A will be used for the protection of some categories of especially sensitive information."
Erzähl hier also keine Storys über irgendwelche NSA-Standards. Die kennst du nicht.
Also mal ehrlich. Meine Container habe ich mit AES verschlüsselt weil es einfach der schnellste ist. Ich mein, come on.
Ich brauche weder nen superlanges Passwort noch einen 1billionen bit Schlüssel ;)
Ich verstecke Daten wie vielleicht die paar schweinischen Bilder mit meiner Freundin, damit wenn ich aus versehen mal abkratze die keiner zu Gesicht bekommt. Manche übertreiben bei der Sicherheit. So wichtig könnt ihr net sein.
Und wenn ich bei TrueCrypt AES benutze und mein Password irgendwie so lautet wie "rammelbacke136" dann wird sich jeder daran schonmal ein paar Jahre die Zähne ausbeißen müssen, auch BKA und NSA zusammen. Wenn die mal so scharf sind auf die paar Daten die ich da habe.
Glaub kaum das ihr da was wichtigeres habt als ich ;)
(del)
2009-11-06, 23:52:45
DeX die Frage des TS lautete welcher der beste ist und nicht, welcher der sicherste ;) Man kann auch Serpent nehmen der noch vor CAST-256 und Twofish der sicherste bekannte wäre, aber er ist merkbar langsamer und daher nicht "der beste". Die anderen tuen es noch genausogut.
Ciao =)
p.s.:
Die Nacktbilder der Holde hab ich wohl hoffähig gemacht :D Ich denke man sollte sich aber nicht bemühen soetwas zu begründen. Man verschlüsselt, weil man nicht möchte, daß irgendjemand schon auf primitivste Weise in irgendwelchen persönlichen Daten rumschnüffelt und fertig.
Gut, hast recht.
Ich verbinde Speed und Sicherheit miteinander. Da ist AES vorne.
Bei normalen Platten sind die 220MB/s die meine C2D macht fast unwichtig. Da ich sowieso dort eher archeviere. Wer aber auf SSDs verschlüsselt nimmt mit sicherheit AES.
Also ist der "beste" immer im Sinne vom Gebrauch unterschiedlich.
Welche der beste bei der Verschlüsselung selbst ist weiß ich nicht so genau, da kenne ich mich nicht soo gut aus. :redface:
Die Sache ist doch: Wenn man nicht gerade ein Passwort mit 60 Zeichen verwendet hat man eh nicht genug Entropie für einen 128-Bit-Schlüssel, geschweige denn für 256 bit.
Im Endeffekt ist dann AES ganz bestimmt sicher genug ;)
Deshalb sage ich ja: Ein wirklich randomisierter Key auf einem Stick bringt weitaus mehr als Twofish statt AES.
Wer aber auf SSDs verschlüsselt nimmt mit sicherheit AES.Nö, Twofish. Mehr als die ~550 MiB/s, die ein kleiner Nehalem damit macht, packt auch SATA3/SAS2 als Massenspeicherinterface kaum.
In den allermeisten Fällen ist der Algorithmus aber sowieso nicht die Schwachstelle. Warum sollte man diesen angreifen, wenn andere Glieder der Kette schon beim Anfassen kaputtgehen? Das können ausgelagerte Daten oder gar Schlüssel sein (Swap-Partition/-Datei verschlüsseln!) oder aber auch die von Coda erwähnte Passphrase. Auch weitere typische Anwenderfehler sind sehr erfolgsversprechend. Warum auch mit hochkomplizierter Kryptoanalyse rumschlagen, wenn es doch auch so einfach sein kann. Neulich habe ich ein WLAN-Passwort eines Bekannten (er hatte es vergessen) beim 4. oder 5. Tippversuch erraten. Da bekommt man es echt mit der Angst zu tun. ;)
Also laut Wiki ist AES der schnellste, TWOFISH der sicherste, wobei AES wohl die beste Performance für die Gebotene Sicherheit liefert.
Nicht wirklich, die Geschwindigkeit von AES und TWOFISH unterscheidet sich nicht nennenswert.
Je nach Situation kann sogar TWOFISH mal schneller sein, im Durchschnitt dürfte aber AES vorne liegen. Allerdings so gering, dass es eigentlich egal ist.
Pinoccio
2009-11-07, 21:58:26
@Coda: Die Länge das Passworts halte ich für ausreichend.
Die Passwortlänge liegt zwischen 38 und 45 Stellen (die genaue Länge wird aus Sicherheitsgründen geheimgehalten).Gegen Brute-Force ist ein Geheimhalten der Passwortlänge - ähm - unnütz.
Das ist nicht paranoid, sondern ziemlich dämlich. Brute-Force-Cracking wird dadurch auch nicht wesentlich langsamer (nur linear)Bei zwei verwendeten Algrüthmen (:freak:) bzw. Stufen ist eine Kaskadierung in der Tat nur um den (Zeit-)Faktor 2 schwerer mit Brute Force zu knacken, bei 3 ist der Gewinn aber wieder deutlich höher und entspricht einem doppelt so langem Schlüssel.
mfg
Gegen Brute-Force ist ein Geheimhalten der Passwortlänge - ähm - unnütz.
Wenn mir bekannt ist wie lang genau dein Passwort ist habe ich wesentlich weniger Möglichkeiten durchzuprobieren als wenn ich den gesamten möglichen Schlüsselraum durchtesten muss. Beispiel:
In einem gegebenen System kann das Passwort zwischen 1 und 8 Zeichen lang sein. Ich sehe ganz kurz einem User bei der Passworteingabe auf den Rücken und kann anhand der Bewegung erkennen dass er 4 Zeichen eingibt, ich kann aber nicht sehen welche Zeichen genau es sind.
Also muss ich nur den Passwortbereich mit 4 Zeichen länge ausprobieren, nicht 3 und nicht 5 Zeichen oder sonst etwas anderes. Das hilft bei Brute Force dann doch sehr.
Kampf-Sushi
2009-11-07, 22:20:07
Topic:
Niemand wird sich die Mühe machen und einen Superrechner auf ein paar Raubkopien, Pornos oder Geschäftsdaten zu jagen. Selbst AES ist offiziell noch nicht gut genug geknackt um da ohne Superrechner was zu reißen. Und wenns unter Geheimhaltung schon geknackt ist, wird man sicher für obrigens nicht riskieren dass das an die Öffentlichkeit gerät.
Von daher würd ich sagen nimm den schnellsten lt. Benchmark.
Wenn man WIRKLICH geheime Daten auf einen Geschäftsnotebook haben sollte die RICHTIG Asche wert sind würd ich VIELEICHT darüber nachdenken was anderes zu nehmen.
Halb-OT:
Warum ist die Geheimhaltung der Passwortlänge unnütz? Seh ich nicht so:
wenn ich weiß dass die Phrase nur 10 Stellen besitzt brauch ich ja keine Phrasen mit 9 Stellen oder weniger probieren.
Halb-OT:
Dass mehrere Verschlüsselungsverfahren hintereinander die Sicherheit nicht erhöhen hab ich zwar schon oft gehört aber nie akzeptiert. Natürlich addiert sich die Sicherheit nicht einfach, zumindest nicht bei identischen Schlüssel.
Aber ich bin der Meinung dass mindestens die Sicherheit vom schwächsten Algorithmus übernommen wird.
Pinoccio
2009-11-07, 22:45:16
Wenn mir bekannt ist wie lang genau dein Passwort ist habe ich wesentlich weniger Möglichkeiten durchzuprobieren als wenn ich den gesamten möglichen Schlüsselraum durchtesten muss. Beispiel:
In einem gegebenen System kann das Passwort zwischen 1 und 8 Zeichen lang sein. Ich sehe ganz kurz einem User bei der Passworteingabe auf den Rücken und kann anhand der Bewegung erkennen dass er 4 Zeichen eingibt, ich kann aber nicht sehen welche Zeichen genau es sind.
Also muss ich nur den Passwortbereich mit 4 Zeichen länge ausprobieren, nicht 3 und nicht 5 Zeichen oder sonst etwas anderes. Das hilft bei Brute Force dann doch sehr.Nein. Um alle Passwort aus genau k Stellen durchzuprobieren benötigst du praktisch genau so lange, wie alle Passworter bis zu einer Länge von k durchzuprobieren.Selbst AES ist offiziell noch nicht gut genug geknackt um da ohne Superrechner was zu reißen.Es gibt keinen öffentlich bekannten Angriff auf AES, der in irgendweiner weise praktikabel wäre, egal wie toll dein Superrechner ist. (Ich lasse mich gerne vom Gegenteil überzeugen)
/edit: off topic: Was lustiges zwischendurch (http://blog.fefe.de/?ts=b40b7e38)
mfg
Nein. Um alle Passwort aus genau k Stellen durchzuprobieren benötigst du praktisch genau so lange, wie alle Passworter bis zu einer Länge von k durchzuprobieren.
Hä? Beispiel:
Passwortlänge max 3, nur 0 und 1 erlaubt.
Für ein Passwort von dem ich definitiv weiß dass es die Länge 3 hat muss ich ausprobieren:
000
001
010
100
101
110
011
111
Für ein Passwort dessen Länge ich NICHT kenne muss ich zusätzlich ausprobieren:
0
1
00
01
10
11
Kampf-Sushi
2009-11-07, 23:04:57
Nein. Um alle Passwort aus genau k Stellen durchzuprobieren benötigst du praktisch genau so lange, wie alle Passworter bis zu einer Länge von k durchzuprobieren.
Dass es nicht "wesentlich" weniger sind ist klar, aber schon vorhanden.
Hab leider keine Formel parat aber wenn ich das nach meinen Verständnis ausrechne müsste ich einfach die Anzahl der Möglichkeiten vom kurzen Schlüssel vom langen Schlüssel abziehen.
Also wenn ich weiß dass die Passphrase genau 256Bit lang ist muss ich die ersten 255Bit nicht ausprobieren. Also 2^256 - 2^255 = Anzahl der nötigen Versuche.
Ich würde also die Hälfte der Versuche sparen.
Pinoccio
2009-11-07, 23:08:16
Dass es nicht "wesentlich" weniger sind ist klar, aber schon vorhanden.
Hab leider keine Formel parat aber wenn ich das nach meinen Verständnis ausrechne müsste ich einfach die Anzahl der Möglichkeiten vom kurzen Schlüssel vom langen Schlüssel abziehen.
Also wenn ich weiß dass die Passphrase genau 256Bit lang ist muss ich die ersten 255Bit nicht ausprobieren. Also 2^256 - 2^255 = Anzahl der nötigen Versuche.
Ich würde also die Hälfte der Versuche sparen.Für zwei mögliche Zeichen ja. Praktisch hast du aber wesentlich mehr, dementsprechend geringer ist der Gewinn an Sicherheit durchs Geheimhalten der Länge. (Siehe folgendes Beispiel)
Hä? Beispiel:Dein Beispiel ist ein Beispiel für schlechte, irreführende Beispiele. Deine Zahlen sind viel zu klein. ;-)
Wenn wir beispielsweise von ein Vorrat an 70 Zeichen ausgehen, dann gibt es 2.25*10^55 Passwörter mit genau 30 Stellen und 2.29*10^55 mit bis zu 30 Stellen. Macht das praktisch einen Unterschied?
mfg
Kampf-Sushi
2009-11-07, 23:16:48
Also je mehr Zeichen benutzt werden desto weniger Gewinn durch Kenntnis der Schlüssellänge. Klingt plausibel.
Hatte vorhin das ganze für 30 verschiedene Buchstaben (was Unsinn ist wg. Groß/ Kleinschreibung) und 8 Stellen ausgerechnet und kam auf ca 5%.
Das erklärt das natürlich.
Wieder was gelernt :D
Die Zahlen habe ich bewusst klein gewählt um es besser visualisieren zu können. Je größer die Menge der Möglichkeiten, desto länger brauche ich. Das bedeutet aber auch dass ich immer mehr davon profitiere die Länge des Passwortes zu kennen, je länger dieses Passwort ist. Also relativ gesehen (hoffe ich habe verständlich ausgedrückt was ich meine)
Also je mehr Zeichen benutzt werden desto weniger Gewinn durch Kenntnis der Schlüssellänge. Klingt plausibel.
Okay, hier rächt es sich Mathe damals abgewählt zu haben. Ich hänge.
Okay, hier rächt es sich Mathe damals abgewählt zu haben. Ich hänge.
Das kannst Du hier (http://www.1pw.de/brute-force.html) glaube ich sehr schön nachschaun.
Nehmen wir an, unser Passwort besteht wie im letzten Beispiel aus 62 verschiedenen Zeichen und ist maximal 3 Zeichen lang.
Dann muss man sich, da man die genaue Länge des Passwortes nicht kennt, beim Brute-Force-Verfahren durch folgende Möglichkeiten durcharbeiten:
62 (62^1) = entspricht einem genau einstelligem Passwort aus 62 verschiedenen Zeichen.
+
3844 (62^2) entspricht einem genau zweistelligem Passwort aus 62 verschiedenen Zeichen.
+
238328 (62^3) entspricht einem genau dreistelligem Passwort aus 62 verschiedenen Zeichen.
Was dann insgesamt 242234 Kombinationen entspricht.
Nehmen wir nun an, wir wissen, dass das Passwort eine Länge von genau 3 Zeichen hat:
In diesem Fall müssen wir allerdings immernoch 238328 mögliche Kombinationen durchprobieren (62^3 eben).
Schon hier wird ersichtlich, dass die Passwörter der Länge 1 und 2 mit ihren insgesamt lediglich 3906 Kombinationen kaum mehr ins Gewicht fallen.
Ich hoffe, dass ich hier keinen Mist erzählt habe :D
OKay, hab ich jetzt verstanden. Aber: Geheimhaltung der genauen Schlüssellänge bringt mir immer noch etwas wenn ich mit meinem Schlüssel nicht die maximal mögliche Schlüssellänge ausnutze (was die meisten Leute betreffen würde die ihren Schlüssel per Passwort, also Tastatureingabe, und nicht per TPM oder Keyfile eingeben). Dann kommen die zu vernachlässigenden kürzeren Schlüssel als Bonus zu den zu vernachlässigenden längeren Schlüsseln hinzu.
Kampf-Sushi
2009-11-08, 07:31:03
Das kannst Du hier (http://www.1pw.de/brute-force.html) glaube ich sehr schön nachschaun.
Nehmen wir an, unser Passwort besteht wie im letzten Beispiel aus 62 verschiedenen Zeichen und ist maximal 3 Zeichen lang.
Dann muss man sich, da man die genaue Länge des Passwortes nicht kennt, beim Brute-Force-Verfahren durch folgende Möglichkeiten durcharbeiten:
62 (62^1) = entspricht einem genau einstelligem Passwort aus 62 verschiedenen Zeichen.
+
3844 (62^2) entspricht einem genau zweistelligem Passwort aus 62 verschiedenen Zeichen.
+
238328 (62^3) entspricht einem genau dreistelligem Passwort aus 62 verschiedenen Zeichen.
Was dann insgesamt 242234 Kombinationen entspricht.
Nehmen wir nun an, wir wissen, dass das Passwort eine Länge von genau 3 Zeichen hat:
In diesem Fall müssen wir allerdings immernoch 238328 mögliche Kombinationen durchprobieren (62^3 eben).
Schon hier wird ersichtlich, dass die Passwörter der Länge 1 und 2 mit ihren insgesamt lediglich 3906 Kombinationen kaum mehr ins Gewicht fallen.
Ich hoffe, dass ich hier keinen Mist erzählt habe :D
Stimmt so nicht ganz, aber die Zahlen verdeutlichen das ja trotzdem.
Wenn du alle 3 Stellen komplett probierst sinds 238328 Versuche.
Wenn du weißt dass du direkt bei 3 Stellen anfangen kannst, kannst du Dir alle Versuche die maximal 2 Stellen haben sparen (also 238328-3844).
Du sparst grad mal lächerliche 1,6% dadurch dass du weißt wie lang der Schlüssel ist.
Das bleibt übrigens auch so: bei 62 Zeichen sparst du 1,6% durch die Kenntnis der Passphrasenlänge. Egal wie lang das PW ist. Bei 2 Zeichen warns noch konstant 50% und bei 70 Zeichen wirds noch schlechter als 1,6% werden.
OKay, hab ich jetzt verstanden. Aber: Geheimhaltung der genauen Schlüssellänge bringt mir immer noch etwas wenn ich mit meinem Schlüssel nicht die maximal mögliche Schlüssellänge ausnutze. Dann kommen die zu vernachlässigenden kürzeren Schlüssel als Bonus zu den zu vernachlässigenden längeren Schlüsseln hinzu.
Nö, man fängt ja idR vorne an.
Nö, man fängt ja idR vorne an.
Das ist eine Optimierung des Vorgehens die nicht immer zutreffen muss. Beispiel: "Hey, ich kenn den Vogel. Der ist total paranoid. Probier mal die langen Kennwörter zuerst durch, ich wette der benutzt kein kurzes Passwort".
Rein von der Gesamtmenge der möglichen Schlüssel bringt es etwas die Passswortlänge geheim zu halten. In der Praxis kann dies variieren, aber da gehen wir langsam schon von Brute Force ab und packen Intelligenz dahinter.
Pinoccio
2009-11-08, 12:22:07
Das ist eine Optimierung des Vorgehens die nicht immer zutreffen muss. Beispiel: "Hey, ich kenn den Vogel. Der ist total paranoid. Probier mal die langen Kennwörter zuerst durch, ich wette der benutzt kein kurzes Passwort".
Rein von der Gesamtmenge der möglichen Schlüssel bringt es etwas die Passswortlänge geheim zu halten. In der Praxis kann dies variieren, aber da gehen wir langsam schon von Brute Force ab und packen Intelligenz dahinter.Bei Brute Force und einem einigermaßen großen Passwort-Alphabet ist es praktisch egal, ob du kurze Passwörter mittestest oder nicht.
Rechne es dir allgemein (http://de.wikipedia.org/wiki/Formelsammlung_Algebra#Potenzsummen) aus, glaub unseren Zahlenbeispielen oder versuche es einfach mal.
mfg
Okay, aber es ist nicht egal ob ich lange Passwörter mitteste oder nicht. Im Beispiel sorgt die Vermutung über die Verwendung eines langen Passwortes dafür dass ein größerer Schlüsselraum getestet werden muss als wenn mir die Länge des Passwortes bekannt wäre (kürzer als max.)
Wenn du alle 3 Stellen komplett probierst sinds 238328 Versuche.
Wenn du weißt dass du direkt bei 3 Stellen anfangen kannst, kannst du Dir alle Versuche die maximal 2 Stellen haben sparen (also 238328-3844).
Bist Du dir da sicher? Bzw kannst Du das mal bitte genauer erläutern?
Weil, wenn ich wie hier erstmal Passwörter der Länge 1 und 2 durchprobieren muss ADDIERT sich doch deren Aufwand in meinen gesamten Bemühungen das PW zu finden.
Ich teste ja erst alle möglichen PWs mit einer Stelle, dann alle mit zwei Stellen, dann alle mit drei Stellen.
Das sind doch drei unterschiedliche "Rechenjobs" mit jeweils ihrem eigenem Aufwand!?
Falls ich die Länge nicht kenne und es beim letzten Versuch eines dreistelligen PWs finde:
PW(1) + PW(2) + PW(3) = Gesamtaufwand
62 + 3844 + 238328 = 242234
Und falls ich weiss, dass das PW genau 3 Stellen hat und ich es auch wieder auf die letzte Kombination finde:
62^3 = 238328
Unterliege ich hier einem Trugschluss, oder definieren denn diese 62^3 Möglichkeiten nicht nur genau die der Länge 3? Soll heißen: Darin sind ja dann NICHT die Passwörter der Länge 1 und 2 eingeschlossen?!
Bei zwei verwendeten Algrüthmen (:freak:) bzw. Stufen ist eine Kaskadierung in der Tat nur um den (Zeit-)Faktor 2 schwerer mit Brute Force zu knacken, bei 3 ist der Gewinn aber wieder deutlich höher und entspricht einem doppelt so langem Schlüssel.
Das verstehe ich jetzt nicht. Wenn alle Cypher den gleichen Key haben, dann steigt das linear, nicht quadratisch.
Die Sache ist doch: Wenn man nicht gerade ein Passwort mit 60 Zeichen verwendet hat man eh nicht genug Entropie für einen 128-Bit-Schlüssel, geschweige denn für 256 bit.Das hast du falsch verstanden. Schlüsselexpansion und KeyAddition sind deine Freunde.
http://www.korelstar.de/informatik/aes.html
Der Benutzer muß sich nicht um eine dem Block gleichwertige Entropie und Länge zu kümmern. Es geht darum BruteForce abzuwehren. Mathematisch gesehen braucht man dafür keine Passwörter mit 60 Zeichen. Man richtet sich hier nur nach der Leistung der BruteForce-Maschinen.
Deshalb sage ich ja: Ein wirklich randomisierter Key auf einem Stick bringt weitaus mehr als Twofish statt AES.wie genau? Mir ist das zu blöd Filekeys in ihrem Klartext egal wo zu speichern. Dann generiere ich lieber >30 Zeichen Passwörter in einer verschlüsselten Datenbank und leg das ggbf. als portable auf einen Stick. Sprich, KeePass 1.x.
Pinoccio
2009-11-08, 16:12:03
Das verstehe ich jetzt nicht. Wenn alle Cypher den gleichen Key haben, dann steigt das linear, nicht quadratisch.Gut, bei gleichem Key ist das ganze natürlich sinnlos.
(Die Diskussion, ob das nun linear oder quadratisch oder sonstwie steigt sollten wir vorher vielleicht auf eine feste Grundlage stellen: was steigt in Abhängigkeit wovon?) Eine Kaskadierung aus beliebig vielen Algorithmen ist natürlich nur dann sinnvoll, wenn die Schlüssel unabhängig sind. Das habe ich als selbstverständlich vorausgesetzt. ;-)
Das hast du falsch verstanden. Schlüsselexpansion und KeyAddition sind deine Freunde.
http://www.korelstar.de/informatik/aes.html
Der Benutzer muß sich nicht um eine dem Block gleichwertige Entropie und Länge zu kümmern. Es geht darum BruteForce abzuwehren. Mathematisch gesehen braucht man dafür keine Passwörter mit 60 Zeichen. Man richtet sich hier nur nach der Leistung der BruteForce-Maschinen.Ich glaube, du hast Coda nicht verstanden, denn er hat recht und dein Beitrag nichts damit zu tun.
mfg
Ich glaube, du hast Coda nicht verstanden, denn er hat recht und dein Beitrag nichts damit zu tun.Es ist schon ein großer Brocken denn ihr noch lernen und begreifen müßt. Aber macht ihr mal in Ruhe. Soviel Zeit muß wohl sein ;)
Kampf-Sushi
2009-11-08, 17:34:50
Unterliege ich hier einem Trugschluss, oder definieren denn diese 62^3 Möglichkeiten nicht nur genau die der Länge 3? Soll heißen: Darin sind ja dann NICHT die Passwörter der Länge 1 und 2 eingeschlossen?!
Ah, versteh Dich jetzt. Dann musst du zu den 62 Zeichen noch ein Zeichen für "NULL" zufügen. Also dass an der Stelle gerade kein Zeichen vorhanden ist.
Also 63^3
Das hast du falsch verstanden. Schlüsselexpansion und KeyAddition sind deine Freunde.
Nein, das habe ich nicht falsch verstanden.
AES beschreibt überhaupt nicht wie man aus einer Passphrase einen Key erzeugt, sondern nur wie man aus dem Key dann die Rundenkeys erzeugt.
Wenn man weiß wie aus einem Passwort der Key erzeugt wird dann reduziert sich durch ein kurzes Passwort der Bruteforce-Angriff natürlich massiv.
Beispiel: 12 Zeichen Passwort über { A-Z, a-z, 0-9, 10 Sonderzeichen } ergibt "gerade mal" 72^12 Möglichkeiten. Das ist ein 1/17532727700000000 von 2^128.
Pinoccio
2009-11-08, 18:38:23
Es ist schon ein großer Brocken denn ihr noch lernen und begreifen müßt. Aber macht ihr mal in Ruhe. Soviel Zeit muß wohl sein ;)Auja, untermauere deine Argumente sinnlosen Beiträge durch persönliche Anfeindungen! Rrrr...
mfg
Beispiel: 12 Zeichen Passwort über { A-Z, a-z, 0-9, 10 Sonderzeichen } ergibt "gerade mal" 72^12 Möglichkeiten. Das ist ein 1/17532727700000000 von 2^128.Erstmal gibt es 42 simpelst erreichbare Sonderzeichen und nicht 10. Das macht insgesamt 104 Zeichen.
12 Zeichen sind dann 1.6^24 wofür der EarthSimulator brute force 1 Tag bräuchte.
13 Zeichen sind 1.66^26 wofür er 114 Tage bräuchte.
14 Zeichen macht 1.73^28 woran er ungefähr 32 Jahre knacken würde.
Vorausgesetzt eine fehlerfreie Implementierung sind demnach aus der Sicht des mächtigsten Angreifers mehr als 14 Zeichen genug für jede Größe der internen Schlüssellänge ausreichend, um brute force absolut sinnlos erscheinen zu lassen.
Keyfiles erhöhen zwar merkbar die Entropie, das Handling mit selbigen senkt aber prinzipiell die Sicherheit des Gesamtsystems. Sie sollten also auf jeden Fall nur zusammen mit einem >14 Zeichen Passwort benutzt werden.
Wir wollen aber auch realistisch bleiben. Die meisten Leute benutzen nichtmal Zahlen in ihren Passwörtern. Es gibt Statistiken über Passwörter, und da kommt man mit den 10 meistverwendeten Sonderzeichen wohl schon sehr weit.
Keyfile mit Passwort ist aber sicher eine gute Idee.
Bei uns darfst du wenigstens auch unter den Unwissenden wenigstens die Umlaute dazu zählen.
Was die Leute benutzen und was nicht, darauf kann der Angreifer vertrauen, oder nicht ;) Methoden die soetwas herausfinden können sind mir nicht bekannt.
Man sollte realistisch gesehen solche Threads nicht als Selbstzweck sehen, sondern an den 3DCler und auch Google denken und eben mehr an Infos und Tipps bringen als nur den Durchschnittsdepp zur Schau zu stellen.
Hausaufgaben. Habt ihr eigentlich schon von den neusten Methoden gehört bei welchen die "Stärke" des verschlüsselten Endprodukts stark sinken kann, wenn die Daten davor nicht komprimiert wurden? O_O
Auf Widertippern.
Bei uns darfst du wenigstens auch unter den Unwissenden wenigstens die Umlaute dazu zählen.
Ja, das gestehe ich ihnen noch zu ;)
Habt ihr eigentlich schon von den neusten Methoden gehört bei welchen die "Stärke" des verschlüsselten Endprodukts stark sinken kann, wenn die Daten davor nicht komprimiert wurden? O_O
Das passiert nur wenn man den Cypher im ECB-Modus verwendet.
Truecrypt verwendet aber XTS, da gibt es dieses Problem nicht. Ein moderner Cypher (alle hier erwähnten) erlaubt damit keine Unterscheidung von Chiffrat und Pseudozufallsfolgen, egal was die Eingabe ist.
Mal abgesehen von der Diskussion um die Länge des Passworts als Schwachstelle hat Truecrypt für mich ganz eine andere, m. M. n. sehr grosse Schwachstelle, die einen Bruteforce-Angriff überhaupt erst sinnvoll erscheinen lässt (zumindest nach den Maßstäben eines versierten Benutzers).
Es lässt eine unbegrenzte Key-/Passphrase-Eingabe zu. Würde man z. B. nach fünf Fehleingaben die Eingabemöglichkeit für sagen wir mal eine Stunde sperren und für eine weitere Fehleingabe (nachdem diese eine Stunde vorüber ist) die Eingabemöglichkeit gleich für einen ganzen Tag sperren, würde man sich das arbeiten mit dieser Methode schon überlegen.
Da es diese Möglichkeit in TC nicht gibt ist hier der Hinweis von Coda mit der Verwendung eines sog. Randomkeys der entscheidende. Ohne die Verwendung eines solchen, ist die Diskussion um den "besten" Algorithmus unter TC für den Threadstarter sinnlos. Dieser Key stellt selbst natürlich auch wieder eine potentielle Lücke dar. Er muss ja irgendwo gespeichert werden ...
Wo wir wieder bei der Ausgangsfrage wären, die dann wie folgt beantwortet werden kann: Es kommt bei Truecrypt NICHT so sehr auf den Algorithmus an sondern auf das Passwort UND die zusätzliche Verwendung eines oder mehrerer Keyfiles.
Abschließend bleibt nur die Frage nach der Wahrscheinlichkeit, mit der ein beliebiger Geheimdienst, einen oder mehrere dieser Algorithmen geknackt hat. Hier entscheidet dann die individuelle Paranoia. :D
TrueCrypt ist Open Source. Wenn TC ein "Aussperr"-Feature implementieren sollte kann mich nichts daran hindern dieses wieder aus dem Quelltext zu entfernen und eine modifizierte Version aufzuspielen. Davon abgesehen: Brute Force passiert nicht per Tastatureingabe am laufenden System.
Bruteforce: Ausprobieren von Passwörtern. Um zu verifizieren ob eine Passworteingabe richtig ist, braucht man das Programm mit welchem die Daten verschlüsselt wurden. Die Eingabe des Passworts übernimmt das "Bruteforce-Programm" (statt eines Menschen). Was wolltest Du mir jetzt genau sagen?
Wie man soetwas implementiert zeigt z. B. Safegaurd Easy seit Jahren. Wenn Du so schlau bist, dann modifiziere doch dort einmal eine verschlüsselte Platte oder die verschlüsselte Systempartition. Du hast keine Ahnung von nichts! Da kannst Du so lange am Quelltext herumschreiben und was entfernen wie Du willst. LOL!
LOL indeed. Warum sollte ich versuchen die verschlüsselte Platte zu modifizieren? Der Teil mit der Sperrfunktion ist der TC Bootloader, und der liegt unverschlüsselt auf der Platte (sonst könnte er ja nicht gelesen werden).
Im Quellcode von TrueCrypt steht genau was wann wo wie verschlüsselt wird. Ich benötige also den Bootloader nicht mal. Ich kann einfach die PreBoot-Authentification-Funktion in ein selbstgebasteltes Progrämmchen ziehen was die Funktion nutzt um die Schlüssel durchzuprobieren. Da haben wir das Brute Force. Ohne Aussperrung. Ohne Hindernisse. Die Sperre bei fünf Fehleingaben behindert also lediglich den legitimen Nutzer, nicht aber einen Angreifer.
(Erzähl mir nicht es wäre unsinnig dass legitime Nutzer fünf mal nacheinander das falsche Passwort eingeben. Du solltst mal sehen mit welchen Hohlbirnen ich teilweise arbeiten muss)
Und jetzt erklär mir mal warum ich "keine Ahnung von nichts" habe.
Erm, wenn man soetwas implementiert macht man das wohl auch ordentlich. Der Bereich in dem Truecrypt seine Daten ablegt ist sowieso bekannt. Das "orginale" Truecrypt z. B. protokolliert in diesem Bereich jeden Mountversuch (ob erfolgreich oder nicht). Der Ableich des erfolgreichen Versuchs wird im eigebundenen Laufwerk in einem seperaten Bereich protokolliert/verifiziert. D. h. ein erfolgreicher Abgleich, kann ohne die Kenntnis der verschlüsselten Daten (sagen wir mal es wurde ein Hashwert hinterlegt) gar nicht eingetragen werden. Also auch nicht mit Hilfe des modfizierten Programms. Nehmen wir weiter an, dass in diesem Bereich ein Random verschlüsselter Bereich existiert, der z. B. an ein TPM, Token, Fingerprint or whatever gekoppelt ist. Um den Schlüssel mit der Passphrase ansprechen zu können muss dieser Bereich zuvor angesprochen werden und dort werden dann auch die Fehlversuche hinterlegt. Ohne den ordentlichen Zugriff (nur Fehleintrag möglich) auf diesen Bereich wird der Schlüssel gar nicht erst geprüft und Bruteforce läuft ins leere.
Jetzt brauche ich z. B. den Fingerprint. Habe ich diesen kann auf den Random verschlüsselten Bereich zugegriffen werden und zunächst auch nur ein Eintrag erfolgen: "Fehler". Nun wird aber bei jedem Zugriff auf diesen Bereich der ja durch prüfen des Fingerprints bereits stattfindet protokolliert. Klar könnte man das jetzt wieder Rückgängig machen indem man den Bootbereich oder den Bereich den TC auf der Platte nutzt wieder zurücksetzt, aber auch das kostet Zeit und erhöht somit die Sicherheit. Wenn man diesen Bereich jetzt auch noch so gestaltet, dass dieser z. B. nur mit dem orginal TPM des Boards für das Programm sichtbar wird ist der Aufwand noch höher. Entweder man emuliert das Teil oder man greift auf die Orginalhardware zurück. Die vom Bentzer aber vielleicht schon unbrauchbar gemacht wurde.
Theoretisch könnte man das auch an ein beschreibbares TPM koppeln, das z. B. nur fünf Fehleinträge zulässt und anschließend, z. B. ähnlich bei der Ländercodefreigabe von DVD-Laufwerken, keine Änderungen mehr zulässt. Auch sicherere Varianten sind möglich. Ich denke da nur diverse Sensorchips (Airbag/Druck). Gleiches wäre möglich mit Brücken die bei Fehleingabe mehr Strom abbekommen und unbrauchbar werden.
So oder so ähnlich kann es gehen. Ich bin hier aber kein Profi sondern ein Laie. Aber auch kein Idiot der meint, dass soetwas nicht möglich ist oder gar sinnlos wäre. Alles eine Frage des Geldes.
Pinoccio
2009-11-09, 12:38:53
Bei uns darfst du wenigstens auch unter den Unwissenden wenigstens die Umlaute dazu zählen.Naja. Ein Passwort sollte sich schon noch eintippen lassen. Sinnvollerweise beschränkt man sich dabei auf alles, was sich auf einer amerikanischen Tastatur mit maximal zwei Tasten eintippen lässt (also z. B. Shift+s=S, nicht: Alt+[234]=Û). Umlaute mögen technisch kein Problem sein, aber sobald für den Anwender nicht klar ist, wie diese verarbeitet werden, sollte man die Finger davon lassen.
Die nötige (i. S. v. sicher gegen Brute-Force des Pasworts) Stärke erreicht man auch so, zur Not eben mit 55 Kleinbuchstaben.
Mal abgesehen von der Diskussion um die Länge des Passworts als Schwachstelle hat Truecrypt für mich ganz eine andere, m. M. n. sehr grosse Schwachstelle, die einen Bruteforce-Angriff überhaupt erst sinnvoll erscheinen lässt (zumindest nach den Maßstäben eines versierten Benutzers).
Es lässt eine unbegrenzte Key-/Passphrase-Eingabe zu. Würde man z. B. nach fünf Fehleingaben die Eingabemöglichkeit für sagen wir mal eine Stunde sperren und für eine weitere Fehleingabe (nachdem diese eine Stunde vorüber ist) die Eingabemöglichkeit gleich für einen ganzen Tag sperren, würde man sich das arbeiten mit dieser Methode schon überlegen.
Da es diese Möglichkeit in TC nicht gibt ist hier der Hinweis von Coda mit der Verwendung eines sog. Randomkeys der entscheidende. Ohne die Verwendung eines solchen, ist die Diskussion um den "besten" Algorithmus unter TC für den Threadstarter sinnlos. Dieser Key stellt selbst natürlich auch wieder eine potentielle Lücke dar. Er muss ja irgendwo gespeichert werden ...Es gibt keine - praktisch und theoretisch - Möglichkeit eine offene Verschlüsselungssoftware dagegen zu schützen.
Was Safeguard Easy da en detial macht, weiß ich nciht, ich halte das aber für oberflächliche Abschreckung von Sciptkiddies und nicht für ein tatsächliche wirksames Feature gegen ernstgemeintes Brute Force.
Und warum der Key irgendwo gespeichert werden muß, ist unklar. Außer im Kopf des Nutzers nicht, und da ist er - in einem freiheitlichen Rechtsstaat nach meinem Verständnis - sicher.
Aber auch kein Idiot der meint, dass soetwas [nach 5 Veruschen sperren] nicht möglich ist oder gar sinnlos wäre. Alles eine Frage des Geldes.Es geht prinzipiell nicht bei TC.
Und eines noch, liebe Gäste/lieber Gast: Nutz(t) doch bitte die Möglichkeit, euch/dich wenigstens innerhalb eines Threads zu wiedererkennbar zu machen, sei es durch Wahl eines Namens a la Gast5b oder durch "Unterschrift". Ich finde es verwirrend und zum Teil demotivierend, nicht zu wissen, ob man hier mit einem oder mehreren diskutiert. Zumindest das angelole deutet auf wenigstens zwei hin ... Wobei, warum sollte ein paranoider Gast nicht auch unter dissoziativer Identitätsstörung leiden. ;-)
mfg
SweetLolita15
2009-11-09, 13:21:02
Und warum der Key irgendwo gespeichert werden muß, ist unklar. Außer im Kopf des Nutzers nicht, und da ist er - in einem freiheitlichen Rechtsstaat nach meinem Verständnis - sicher.
Erklär das mal den Briten (http://en.wikipedia.org/wiki/Regulation_of_Investigatory_Powers_Act_2000#Controversy) (Wikipedia)
und zusätzlich der erstbeste Artikel aus der Google-Suche (http://www.itworldcanada.com/news/u-k-appeals-court-rejects-encryption-key-disclosure-defense/04090)
Und eines noch, liebe Gäste Nutzt doch bitte die Möglichkeit, euch/dich wenigstens innerhalb eines Threads zu wiedererkennbar zu machen, sei es durch Wahl eines Namens a la Gast5b oder durch "Unterschrift".
Ich hoffe ich hab es so richtig gemacht :D
Pinoccio
2009-11-09, 13:43:31
Erklär das mal den Briten (http://en.wikipedia.org/wiki/Regulation_of_Investigatory_Powers_Act_2000#Controversy) (Wikipedia)
und zusätzlich der erstbeste Artikel aus der Google-Suche (http://www.itworldcanada.com/news/u-k-appeals-court-rejects-encryption-key-disclosure-defense/04090)Gerade weil ich weiß*, daß es in UK anders gehandhabt wird meine Einschränkung.
* siehe da (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5862711#post5862711) (Beitrag ist von mir, auch wenn ich da grad mal nicht angemeldet war)
Ich hoffe ich hab es so richtig gemacht :DNaja, einige werden diese Seite auf Arbeit nicht mehr aufrufen dürfen, aber an sich ist das schon besser.
Mich hindert es nur daran, anderen zu erzählen, was ich hier mache: mit sweetLolita15 diskutieren, daß Penis nicht lang genug ist (http://giveupinternet.com/wp-content/uploads/2008/12/create-new-password-short-penis.jpg), ob MARS (http://de.wikipedia.org/wiki/MARS_(Verschl%C3%BCsselung)) sie/ihn überzeugen würde, und ob ein Bit mehr (http://de.wikipedia.org/wiki/Bitburger#Produkte) jetzt Chancen verdoppelt ... ;D
mfg
Tesseract
2009-11-09, 16:11:24
Mal abgesehen von der Diskussion um die Länge des Passworts als Schwachstelle hat Truecrypt für mich ganz eine andere, m. M. n. sehr grosse Schwachstelle, die einen Bruteforce-Angriff überhaupt erst sinnvoll erscheinen lässt (zumindest nach den Maßstäben eines versierten Benutzers).
Es lässt eine unbegrenzte Key-/Passphrase-Eingabe zu. Würde man z. B. nach fünf Fehleingaben die Eingabemöglichkeit für sagen wir mal eine Stunde sperren und für eine weitere Fehleingabe (nachdem diese eine Stunde vorüber ist) die Eingabemöglichkeit gleich für einen ganzen Tag sperren, würde man sich das arbeiten mit dieser Methode schon überlegen.
diese bottleneck-sicherheit ist kryptografisch vollkommen wertlos. damit tauscht du kryptografische sicherheit gegen physikalische absicherung weil so etwas nur funktionieren kann, wenn der angreifer physikalisch keinen zugang zum system hat. (selbst unter der naiven annahme, das system sei ohne physikalischen zugriff unhackbar)
das selbe gilt für irgendwelche mechaniken, die die daten bei z.B. 3x falschem passwort zerstören oder ähnliche lustigkeiten.
wenn du die sicherheit von verschlüsselung betrachten willst kannst du von folgenden dingen ausgehen:
- der angreifer hat uneingeschränkten zugang zu system und daten (daher keine bottlenecks, keine künstlichen blockaden usw.)
- der angreifer arbeitet ausschließlich an kopien und nicht am "original" (d.h keine selbstzerstörungen usw.)
- der angreifer hat umfassendes wissen über das system (daher keine security by obscurity, keine "unsicheren, aber geheimen algorithmen" usw.)
Pinoccio
2009-11-09, 17:11:23
diese bottleneck-sicherheit ist kryptografisch vollkommen wertlos. damit tauscht du kryptografische sicherheit gegen physikalische absicherung weil so etwas nur funktionieren kann, wenn der angreifer physikalisch keinen zugang zum system hat. (selbst unter der naiven annahme, das system sei ohne physikalischen zugriff unhackbar)
das selbe gilt für irgendwelche mechaniken, die die daten bei z.B. 3x falschem passwort zerstören oder ähnliche lustigkeiten.
wenn du die sicherheit von verschlüsselung betrachten willst kannst du von folgenden dingen ausgehen:
- der angreifer hat uneingeschränkten zugang zu system und daten (daher keine bottlenecks, keine künstlichen blockaden usw.)
- der angreifer arbeitet ausschließlich an kopien und nicht am "original" (d.h keine selbstzerstörungen usw.)
- der angreifer hat umfassendes wissen über das system (daher keine security by obscurity, keine "unsicheren, aber geheimen algorithmen" usw.)Kurz: Kerckhoffs' principle (http://en.wikipedia.org/wiki/Kerckhoffs%27_principle). 1883!
mfg
nicht möglich ist oder gar sinnlos wäre. Alles eine Frage des Geldes.
Es geht prinzipiell nicht bei TC.
Das ist ja richtig, dass TC diese Technik nicht bietet. Gleichwohl bezweifle ich, dass es prinzipbedingt nicht möglich sein soll. Preboot-Authentication gibt es ja seit einiger Zeit auch. In Zukunft wird es auch sicherlich möglich sein, Keyfiles (die auf einem USB-Stick liegen) für die Verschlüsselung der Systempartition zu verwenden. Das ist derzeit leider noch nicht möglich. Ob es eine solche Technik in Zukunft geben wird steht auf einem ganz anderen Blatt.
anderer Gast
2009-11-09, 18:26:22
Mal abgesehen von der Diskussion um die Länge des Passworts als Schwachstelle hat Truecrypt für mich ganz eine andere, m. M. n. sehr grosse Schwachstelle, die einen Bruteforce-Angriff überhaupt erst sinnvoll erscheinen lässt (zumindest nach den Maßstäben eines versierten Benutzers).
Hallo,
du glaubst doch nicht allen ernstes, das jemand die PWs zum knacken manuelle eingibt.
Es wird mit einem (Teil-)Image gearbeitet, welches im RAM gehlaten wird und aufgrund der bekannten Aufbaus von TC versucht das PW zu knacken. Erst so entsteht die Möglichkeit mehrer Millionen PW/s zu knacken.
Manuelle ist es sinnlos, einen Brute Force Angriff auszuführen (-> Zeit).
mfg
Pinoccio
2009-11-09, 18:30:17
Das ist ja richtig, dass TC diese Technik nicht bietet. Gleichwohl bezweifle ich, dass es prinzipbedingt nicht möglich sein soll. Preboot-Authentication gibt es ja seit einiger Zeit auch. In Zukunft wird es auch sicherlich möglich sein, Keyfiles (die auf einem USB-Stick liegen) für die Verschlüsselung der Systempartition zu verwenden. Das ist derzeit leider noch nicht möglich. Ob es eine solche Technik in Zukunft geben wird steht auf einem ganz anderen Blatt.(Hervorhebung im Zitat von mir)
Nein, es ist prinzipiell unmöglich, per Software soetwas zu realisieren.
PS: Das mit den Namen üben wir nochmal. ;-)
mfg
DerGastmitderSperre
2009-11-09, 18:55:41
diese bottleneck-sicherheit ist kryptografisch vollkommen wertlos. damit tauscht du kryptografische sicherheit gegen physikalische absicherung weil so etwas nur funktionieren kann, wenn der angreifer physikalisch keinen zugang zum system hat. (selbst unter der naiven annahme, das system sei ohne physikalischen zugriff unhackbar)
das selbe gilt für irgendwelche mechaniken, die die daten bei z.B. 3x falschem passwort zerstören oder ähnliche lustigkeiten.
wenn du die sicherheit von verschlüsselung betrachten willst kannst du von folgenden dingen ausgehen:
- der angreifer hat uneingeschränkten zugang zu system und daten (daher keine bottlenecks, keine künstlichen blockaden usw.)
- der angreifer arbeitet ausschließlich an kopien und nicht am "original" (d.h keine selbstzerstörungen usw.)
- der angreifer hat umfassendes wissen über das system (daher keine security by obscurity, keine "unsicheren, aber geheimen algorithmen" usw.)
Grundsätzlich steht und fällt das gesamte Konzept der Verschlüsselung mit der Möglichkeit des physischen Zugriffs auf einen verschlüsselten Datenträger.
Grundsätzlich verschlüsselt man ja auch Daten gerade weil man weiss, dass diese Daten unbefugten in die Hände fallen könnten. Man rechnet quasi mit dem "worst case".
Man kann es demjenigen, dem die Daten in die Hände gefallen sind, immer nur schwerer machen die Daten zu extrahieren. Die Verschlüsselung als Schwachstelle anzusehen ist ohne die entsprechende Rechenkraft utopisch und selbst für eine Behörde a la NSA, BKA, CIA or whatever nicht praktikabel. Da sind andere Ansätze wie eben die genannte "Brute-Force-Methode" eben viel aussichtsreicher. Daneben existieren die legalen und nicht legalen physischen und psychischen Methoden der genannten Behörden, die wohl ganz weit vorne bei den Methoden zur Erlanung eines Passworts oder Schlüssels liegen. Also sind das Passwort und die eigene Person die grössten Schwachstellen die ein solches System bietet. Nicht zuletzt gibt es den "Bundestrojaner" und damit zusammenhängende Methoden (Keylogger, etc.) der im wohl eher für das kriminelle Umfeld zum Einsatz kommen wird.
Begiebt man sich auf die Ebene eines Normalanwenders der evtl. Pronos von seiner Freundin, Warez und Musik auf der Platte hat. Fallen die o. g. Methoden wohl aus. Allein schon aus Kostensicht. Sofern man also von Gesetzeswegen nicht zur Herausgabe gezwungen werden kann ist man also einfacher Bürger relativ sicher. Gleichwohl wird man immer nach höherer möglicher Sicherheit streben.
Den Gedanken mit einer Art sperre kann man ja durchaus weiterentwickeln. Ist das Passwort richtig, fehlt aber z. B. der Schlüssel könnte das System oder die Verschlüsselung einen Container oder die Festplatte mit hinterlegten Fakedaten "freigeben" ohne, dass eine Behörde davon etwas mitbekommt.
Das arbeiten mit Kopien würde auch durch entsprechende Hardwaremodule, die "einzigartig" sind, extrem erschwert werden. Gleichwohl sind die TPMs (die es gegeben hat) für unsere Behörden Bücher mit offem Siegel. Es gibt hierbei dann nur die Möglichkeit nach Schwachstellen zu suchen (vgl. Blueray u. ä.). Betrachtet man aber die vergangen Jahre genauer wird es auch hier zunehmend fast unmöglich. Als Beispiel sei hier das sog. "PayTV" genannt. Insbesondere die Verschlüsselung die ein gewisser englischer Medienmogul seit vielen Jahren erfolgreich einsetzt.
Es müsste sich also erst einmal ein Hersteller finden, der es mit der Sicherheit ernst nimmt. Die zahlreich auf dem Markt befindlichen USB-Stick Verschlüsselungen sind hier ein warnendes Beispiel sich auf solche Hersteller nicht zu verlassen.
DerGastmitderSperre
2009-11-09, 19:01:45
(Hervorhebung im Zitat von mir)
Nein, es ist prinzipiell unmöglich, per Software soetwas zu realisieren.
PS: Das mit den Namen üben wir nochmal. ;-)
mfg
O.K. So verstehen wir uns. :)
In meinem Erstpost #50 habe ich ja nur auf diese (aus meiner Sicht) "Schwachstelle" von TC hingewiesen und über die Möglichkeit einer Sperre gesprochen. Nicht über die Umsetzung einer solchen.
Diese Möglichkeit hat ein gewisser anderer Gast angezweifelt. Ist auch sein gutes Recht. Daraufhin habe ich mir erst Gedanken über eine Umsetzung einer solchen Sperre gemacht. Dass dies in Verbindung mit Hardware geschehen muss war mir auch schnell klar. Gleichwohl ist eine Lösung a la SGE mit Sicherheit auch nicht verkehrt.
Hallo,
du glaubst doch nicht allen ernstes, das jemand die PWs zum knacken manuelle eingibt.
Es wird mit einem (Teil-)Image gearbeitet, welches im RAM gehlaten wird und aufgrund der bekannten Aufbaus von TC versucht das PW zu knacken. Erst so entsteht die Möglichkeit mehrer Millionen PW/s zu knacken.
Manuelle ist es sinnlos, einen Brute Force Angriff auszuführen (-> Zeit).
mfg
Mir ist sehr wohl klar, dass das ein Programm macht. Mir ist auch klar, dass mit Images gearbeitet wird. Mir ist auch klar, dass mit entsprechendem Aufwand fast alles möglich ist ... Mir ist auch klar, dass das ganze mit CUDA um den Faktor ~10 (grob geschätzt) schneller geht. Andere Anwendungen profitieren da weit weniger.
Im Übrigen ist der grösste Zeitaufwand die Prüfzeit für die Passwortverifizierung und die dauert mit dem Bruteforceprogramm genauso lange wie mit dem Orginal (abseits der Rechenkraft natürlich). I. d. R. dürfte es ja sogar so sein (man hat ja normalerweise keinen Quellcode), dass man auf das Orginalprogramm zurückgreifen muss.
Selbstverständlich hat man bei brauchbarer Verschlüsselungssoftware den Quellcode, wir sind hier ja nicht beim Kryptochef und selbst der rückt ihn für preiswerte 2 Mio raus.
Eine entsprechende "Sperre" würde man kurzerhand einfach rauspatchen und ohne weitermachen. Aber selbst wenn sie funktionieren würde: Stell dir vor du hast eine schöne massive mittelalterliche Burgmauer mit Hightech-Verstärkung vor dir und willst sie einreißen. Deshalb trittst du mit nackten Füßen dagegen. Welchen Unterschied macht es jetzt, ob du nach jedem dritten abgefetzten Fußnagel erst mal 5 Minuten Pause machen musst oder direkt weiter das Blut spritzen lassen kannst? Die Mauer wird so nicht kaputtgehen. Wenn du also nicht zufällig im Augenwinkel entdeckst, dass man beim Bau ein großes Loch gelassen hat (der Anwender eine dauige Passphrase gewählt hat), wirst du den Rest deines Lebens damit verbringen gegen die Mauer zu treten, dein Bein wird dir abfaulen und die Geier werden es fressen. Auf diese Art und Weise bleibt die Mauer stehen. Du musst dir was anderes ausdenken.
DerGastmitderSperre
2009-11-09, 20:29:51
Du gehst immer davon aus, dass eine Behörde unbegrenzte Mittel hat und mal so eben 2 Mio. an eine Firma oder einen Entwickler bezahlt. Das mag für die Terrorbekämpfung gelten und auch noch im Geheimdienstumfeld möglich sein. Aber für die Polizei oder gar das BKA sind die Mittel sehr wohl begrenzt.
So eine Sperre in Verbindung mit Hardware einfach mal eben "wegpatchen" ist IMO auch sehr hoch gegriffen. Ich habe bereits beschrieben in welche Richtung das gehen sollte/kann. Wenn das alles so einfach wäre und mit wenig Geldaufwand möglich wäre würde wohl keiner auf die Idee kommen gross Geld für eine Verschlüsselung von Daten auszugeben. Zumal ich mir kaum vorstellen kann, dass in Hochsicherheitsbereichen nur mit Softwaresicherheit gearbeitet wird. Darauf sind nur die "Normalos" wie wir angewiesen. Ich kann mir nicht vorstellen, dass die Raketenabschusscodes (sofern es diese Art von Sicherheitssystem so überhaupt gibt) nur mit dem Irisscan des Präsidenten freigeschaltet werden. Der hat sicher noch eine Art Hardwareschlüssel mit dabei und ein Passwort. Vielleicht kommt auch noch eine Stimmenanalyse hinzu. Wobei wir hier wieder bei der zusätzlichen Sicherheit einer solchen Sperre angekommen wären.
Dein Vergleich mit der Burg ist zwar durchaus richtig. Ich habe aber bereits erwähnt, dass das Passwort die grösste Sicherheitslücke überhaupt darstellt. Diese Lücke kann man mit einem zusätzlichen Randomkey verkleinern. Weiter verkleinern kann man diese mit der genannten "Sperre". Wie auch immer diese optimal zu realisieren wäre.
Sei es d'rum ... über Sinn oder Unsinn einer solchen Sperre kann man natürlich länger streiten.
Hi Coda ;)
Das passiert nur wenn man den Cypher im ECB-Modus verwendet.
Truecrypt verwendet aber XTS, da gibt es dieses Problem nicht. Ein moderner Cypher (alle hier erwähnten) erlaubt damit keine Unterscheidung von Chiffrat und Pseudozufallsfolgen, egal was die Eingabe ist.JA das paßt schon, aber die Info war eher einer allgemeinen Natur. Es gibt sowas wie OpenPGP und andere an sich korrekt verschlüsselnde Programme.
TC hat schon davor kein ECB benutzt.
Bei OpenPGP handelt es sich wohl eher um das hier
http://www.schneier.com/paper-pgp.html
Grundsätzlich steht und fällt das gesamte Konzept der Verschlüsselung mit der Möglichkeit des physischen Zugriffs auf einen verschlüsselten Datenträger.
Grundsätzlich verschlüsselt man ja auch Daten gerade weil man weiss, dass diese Daten unbefugten in die Hände fallen könnten. Man rechnet quasi mit dem "worst case".Das Problem in dem Fall ist nicht die Beschlagnahme, sondern die Geheimhaltung des physikalischen Zugriffs. Vorerst.
http://blogs.zdnet.com/security/?p=4662
Bei OpenPGP handelt es sich wohl eher um das hier
http://www.schneier.com/paper-pgp.html
Da hat wohl jemand das Salz vergessen. Doofe Geschichte.
Gleichwohl bezweifle ich, dass es prinzipbedingt nicht möglich sein soll.
Es auf jeden Fall nicht sinnvoll, wenn ein physischer Zugriff auf die geschützten Daten möglich ist.
Wenn jemand wirklich versuchen sollte die Verschlüsselung mittels Bruteforce zu knacken würde er es wohl kaum mit Truecrypt händisch machen, sondern mit einer eigenen Software, die das automatisch macht. Und bei dieser wird er logischerweise keine Sperre nach x Fehlversuchen einbauen.
Abgesehen davon wird kaum jemand wirklich per Bruteforce versuchen an die Daten zu kommen, das ist selbst mit relativ schwachen Passwörtern noch viel zu zeitaufwändig.
Da gibt es wesentlich einfachere Methoden an das Passwort zu kommen.
Beispielsweise wird einfach die Tastatur durch ein baugleiches Modell ausgetauscht, welches die Tasteneingaben mitloggt, schon hat man das Passwort mit minimalem Aufwand.
Je nach Situation wären natürlich auch andere Methoden denkbar.
Den Gedanken mit einer Art sperre kann man ja durchaus weiterentwickeln. Ist das Passwort richtig, fehlt aber z. B. der Schlüssel könnte das System oder die Verschlüsselung einen Container oder die Festplatte mit hinterlegten Fakedaten "freigeben" ohne, dass eine Behörde davon etwas mitbekommt.
Das gibt es schon lange und nennt sich Hidden System.
Philipus II
2009-11-10, 23:27:53
Noch ein Tipp aus der Praxis:
Die Kombination Keyfile+Passwort ist wirklich ziemlich praktisch.
Als Keyfile könnte man so manches nehmen, der Kreativität sind kaum Grenzen gesetzt.
Wenn man das Keyfile dann auf einer Micro CD Karte speichert, kann man diese selbst im Falle einer Hausdurchsuchung rechtzeitig schlucken und hat die Schlüsseldatei damit gut versteckt. Alternativ könnte man sie auch in Kühllamellen einkleben, unter den Tasten der Tastatur verstecken usw.
Oder man nimmt den Quellcodes einer normalerweise nicht sich ändernden Website...
Das ist eine Idee. Ich hab schon überlegt meine alte Compactflash dafür zu nutzen aber das könnte dann problematisch werden :ulol:
Hmm, zersetzt sich das nicht im Magen? Ansonsten schleppen die Bullen ja alles mit, damit sie selber neue Hardware haben. BTW: Schleppen die auch Rohlinge raus? Da würde ich ein anderes Versteck nehmen, denn clevere Naturen könnten versuchen die Daten im Speicher der Geräte zu verstauen, nehmen den Hash von einem ROM-Dump, Kauf-DVD und so weiter. Und die HW ist dann weg. Ich glaube kaum, daß sie mit sich argumentieren lassen, daß du deine Tastatur *unbedingt* behalten möchtest, weil unter dem X deine µSD-Karte klebt ;)
Wäre das mit dem Schlucken häufiger, würden DIE(tm) auch gleich eine Leibesvisitation mit Abführmittel durchziehen (überarbeitete Richter unterschreiben alles). Ist ja schließlich "kriminalistische Erfahrung" auch wenn es vom Erfolg her im Promillebereich liegt. Da kannst du die Karte eher an deinen Hund kleben und in den Wald schicken...
Oder dürften Tiere auch durchsucht werden? Na gut, packe ich mir einen Tiger in die garage wie bei Alf *rofl*
(del)
2009-11-20, 03:02:00
Hmm, zersetzt sich das nicht im Magen?-> Sicheres Löschen :D Das beste was einem Zugangkode passieren kann, wenn nicht authorisierte Personen sich den Zugriff verschaffen wollen.
iDiot
2009-11-20, 10:06:50
Das Zersetzen dauert wohl zu lange, ich denke da siehst du es vorher wieder :D
Philipus II
2009-11-20, 14:37:51
Notfalls gibts dafür Schutzhüllen. Einfach mal die Drogenschmuggler zum Vorbild nehmen, bei denen wirds planmässig ja auch wieder ausgeschissen.
Ah, versteh Dich jetzt. Dann musst du zu den 62 Zeichen noch ein Zeichen für "NULL" zufügen. Also dass an der Stelle gerade kein Zeichen vorhanden ist.
Also 63^3
Nein, auch nicht 63^3... dann hättest du u.a. 0ab oder a0b oder ab0, was bei einem zweistelligen PW ja identisch wäre...
Mordred
2010-06-15, 10:57:44
Bist Du dir da sicher? Bzw kannst Du das mal bitte genauer erläutern?
Weil, wenn ich wie hier erstmal Passwörter der Länge 1 und 2 durchprobieren muss ADDIERT sich doch deren Aufwand in meinen gesamten Bemühungen das PW zu finden.
Ich teste ja erst alle möglichen PWs mit einer Stelle, dann alle mit zwei Stellen, dann alle mit drei Stellen.
Das sind doch drei unterschiedliche "Rechenjobs" mit jeweils ihrem eigenem Aufwand!?
Falls ich die Länge nicht kenne und es beim letzten Versuch eines dreistelligen PWs finde:
PW(1) + PW(2) + PW(3) = Gesamtaufwand
62 + 3844 + 238328 = 242234
Und falls ich weiss, dass das PW genau 3 Stellen hat und ich es auch wieder auf die letzte Kombination finde:
62^3 = 238328
Unterliege ich hier einem Trugschluss, oder definieren denn diese 62^3 Möglichkeiten nicht nur genau die der Länge 3? Soll heißen: Darin sind ja dann NICHT die Passwörter der Länge 1 und 2 eingeschlossen?!
62^3 beinhaltet bereits sämtliche 1 und 2 stelligen Passwörter. 238328 ist also der maximal Wert der erreicht wird.
Wenn du ein und zweistellige Passwörter ausschließt kann du die Anzahl jener subtrahieren.
Dabei sparrst du aber reichtlich wenig.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.