ubuntuusers.de

Luks oder TrueCrypt?

Status: Gelöst | Ubuntu-Version: Ubuntu 12.04 (Precise Pangolin)
Antworten |

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Wenn dein System nur sicher ist, wenn der Angreifer den Algorithmus und Schlüsselgröße nicht kennt, dann hast du Security by Obscurity.

Der Witz an Verschlüsselungstechnologie ist ja gerade, daß sie sicher zu sein hat, auch wenn alles darüber bekannt und der Sourcecode offen ist.

Dann eben direkt dm-crypt, ohne LUKS.

Das ist in der Regel erstmal ein Eigentor. LUKS macht ziemlich viel richtig was du bei plain so ohne weiteres erstmal nicht hinbekommst.

siehe auch http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions Punkt 2.4 und andere ...

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17525

Vegeta schrieb:

Man könnte auch alle Methoden durchgehen, nachdem das Passwort eingegeben wurde.

Brute Force? 😈

Das würde nur 'ne Millisekunde dauern und würde potentiellen Angreifern das Leben erschweren.

Leider Nein, denn wir reden hier von PBKDF2 wenn wir es richtig machen. Also pro versuchter Kombination von einer Sekunde, wenn ich mir da die möglichen Kombinationen anschaue wird das ordentlich lange dauern 😉

Warum allerdings die Größe des Masterschlüssels gespeichert wird, erschließt sich mir überhaupt nicht.

Ich gehe Stark davon aus das sich der Entwickler hier schon Gedanken gemacht haben wird.

Und bezüglich der Code-Qualität lässt sich so lange keine Aussage treffen, so lange der Quellcode nicht ebenfalls einem Audit unterzogen wurde.

Da bin ich wieder einer Meinung.

mfg Stefan Betz

Vegeta

Avatar von Vegeta

Anmeldungsdatum:
29. April 2006

Beiträge: 7943

frostschutz schrieb:

Wenn dein System nur sicher ist, wenn der Angreifer den Algorithmus und Schlüsselgröße nicht kennt, dann hast du Security by Obscurity.

Der Witz an Verschlüsselungstechnologie ist ja gerade, daß sie sicher zu sein hat, auch wenn alles darüber bekannt und der Sourcecode offen ist.

Nein, wenn der Angreifer den Verschlüsselungs- und den Hash-Algorithmus nicht kennt, kann er erstens nicht gezielt Schwächen eines Algorithmus ausnutzen und zum anderen vermehren sich mit jeder Algorithmus-Mix-Methode die Anzahl der Durchläufe die ein Angreifer durchführen muss. Es bringt also definitiv was, wenn der Angreifer nicht weiß welche Algorithmen benutzt werden.

encbladexp schrieb:

Vegeta schrieb: Leider Nein, denn wir reden hier von PBKDF2 wenn wir es richtig machen. Also pro versuchter Kombination von einer Sekunde, wenn ich mir da die möglichen Kombinationen anschaue wird das ordentlich lange dauern 😉

Ahja guter Einwand. Ich stecke allerdings in der Materie nicht drin um sagen zu können, ob man PBKDF2 wirklich jedes Mal ausführen müsste. Eigentlich müsste es ausreichen PBKDF2 einmalig für das eingegebene Passwort zu berechnen, mit diesem Schlüssel ließen sich dann die Algorithmus-Kombinationen testen. Denn der berechnete Schlüssel ändert sich ja nicht, so lange das Passwort dasselbe ist.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Testen ist auch so eine Sache, denn "funktionieren" tut jede Methode, die Frage ist nur, welche Daten du herausbekommst. Wenn cryptsetup entscheiden können soll, was richtig ist, muß dazu irgendwas im Header stehen. Eine Entscheidung anhand der Nutzdaten ist nicht zuverlässig möglich.

Vegeta

Avatar von Vegeta

Anmeldungsdatum:
29. April 2006

Beiträge: 7943

Ich würde das ungefähr so machen, man nehme das eingegebene Passwort des Users, schickt dieses durch eine Routine die das noch irgendwie häckselt, berechne den PBKDF2-Schlüssel davon, verschlüssle es mit dem berechneten PBKDF2-Schlüssel und angegebenen Verschlüsselungsalgorithmus, danach ermittle ich dann mit dem angegebenen Hash-Algorithmus den Hash-Wert und speichere diesen in dem Header ab.

Besagten Hash-Wert könnte man dann nur mit einer bestimmten Algorithmus-Kombo und dem richtigen Passwort erneut generieren, alle anderen Algorithmus-Kombos würden falsche Werte liefern oder aber das Passwort wäre falsch.

chilidude

Avatar von chilidude

Anmeldungsdatum:
18. Februar 2010

Beiträge: 867

@Vegeta Was anderes passiert doch auch gar nicht. Das MAsterpasswort wird mit zufälligen Salt-Wert zusammengefügt, dann mit SHA1 (nach dem Standard PBKDF2) eine Sekunde lang gehasht, die Iterationszahl niedergeschrieben und die Checksumme erstellt. Zufrieden?

Der Rest, den du bemängelst, ist absolut vernachlässigbar. Ob du nun zwischen verschiedenen Hashvarianten auswählst und eine Sekunde rechnest oder Eine nimmst und auch nur eine Sekunde rechnest - wo ist da der Unterschied? Und die Länge des Masterpasswords kann bei AES nur 128 oder 256 Bit sein. (Bei original Rijandel gibt es nur ein paar mehr). Es ist eine Blockchiffre mit starr festgelegter Bitlänge. (Wie du auf die 10% Verluste kommst, ist für mich nicht nachvollziehbar.)

Im übrigen hält dich bei dmcrypt/LUKS tatsächlich niemand davon ab, ganz auf LUKS zu verzichten. Erstelle deinen eigenen zufälligen Schlüssel und mache die Verschlüsselung ohne LUKS, wie oben beschrieben. (Mit dmcrypt ist das kein Problem.) Dann gibt es auch nichts mehr zu meckern.

Vegeta

Avatar von Vegeta

Anmeldungsdatum:
29. April 2006

Beiträge: 7943

chilidude schrieb:

Der Rest, den du bemängelst, ist absolut vernachlässigbar. Ob du nun zwischen verschiedenen Hashvarianten auswählst und eine Sekunde rechnest oder Eine nimmst und auch nur eine Sekunde rechnest - wo ist da der Unterschied?

Es ging darum, dass der Verschlüsselungsalgorithmus und Hash-Algorithmus automatisch erkannt wird und nicht extra in dem Header geschrieben werden muss. Je nach Implementierung wäre es nur einmalig nötig den PBKDF2-Schlüssel für ein bestimmtes Passwort zu berechnen und somit wäre es ohne Zeitverlust möglich die verwendeten Algorithmen zu bestimmen anstatt sie im Klartext reinzuschreiben. Wäre interessant zu wissen wie es TrueCrypt macht.

Und die Länge des Masterpasswords kann bei AES nur 128 oder 256 Bit sein. (Bei original Rijandel gibt es nur ein paar mehr). Es ist eine Blockchiffre mit starr festgelegter Bitlänge. (Wie du auf die 10% Verluste kommst, ist für mich nicht nachvollziehbar.)

Okay, da bin ich von einem falschen Ansatz ausgegangen. Ich dachte und das kam mir halt auch extrem seltsam vor, dass die Länge des originalen Passwortes gespeichert wird. Wenn man das nämlich nachrechnet, kommt man auf die 10%.

Aber trotzdem ist es nicht falsch, dass die Angabe der Schlüssellänge ein Schwachpunkt ist - jedenfalls bei AES. So ist AES 256 angreifbarer als AES 128, wie vor Jahren schon bei heise gelesen werden konnte. Aber es gibt ja auch noch andere Algorithmen wie den ebenfalls weit verbreiteten Twofish.

Im übrigen hält dich bei dmcrypt/LUKS tatsächlich niemand davon ab, ganz auf LUKS zu verzichten. Erstelle deinen eigenen zufälligen Schlüssel und mache die Verschlüsselung ohne LUKS, wie oben beschrieben. (Mit dmcrypt ist das kein Problem.) Dann gibt es auch nichts mehr zu meckern.

Nein nein, ich werde garantiert nicht auf LUKS umstellen. Verschlüsselung des Home-Verzeichnis benutze ich zwar mittlerweile, aber nicht die verschlüsselten externen Backup-Festplatten. Der Aufwand würde sich nicht im Geringsten lohnen, da bleibe ich bei TrueCrypt.

Und nein meckern tue ich nicht, das würde sich anders anhören.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Vegeta schrieb:

Ich dachte und das kam mir halt auch extrem seltsam vor, dass die Länge des originalen Passwortes gespeichert wird.

Aufs Passwort gibt es keinerlei Anhaltspunkte.

So ist AES 256 angreifbarer als AES 128

"angegriffen" wurde hier eine deutlich abgeschwächte Version unter ganz speziellen Bedingungen. Praxisrelevanz gleich Null.

Wäre interessant zu wissen wie es TrueCrypt macht.

Bei TrueCrypt wird der Header verschlüsselt, anders würden sich so Scherze wie "Hidden Volumes" auch kaum realisieren lassen. Der Sinn dieser Volumes sei mal dahingestellt, in der cryptsetup FAQ wird darauf auch eingegangen, aber wers braucht kann ja dann einfach TrueCrypt nehmen.

chilidude

Avatar von chilidude

Anmeldungsdatum:
18. Februar 2010

Beiträge: 867

Vegeta schrieb:

Es ging darum, dass der Verschlüsselungsalgorithmus und Hash-Algorithmus automatisch erkannt wird und nicht extra in dem Header geschrieben werden muss. Je nach Implementierung wäre es nur einmalig nötig den PBKDF2-Schlüssel für ein bestimmtes Passwort zu berechnen und somit wäre es ohne Zeitverlust möglich die verwendeten Algorithmen zu bestimmen anstatt sie im Klartext reinzuschreiben.

Wie schon gschrieben, der Unterschied ist marginal und zu vernachlässigen.

Okay, da bin ich von einem falschen Ansatz ausgegangen. Ich dachte und das kam mir halt auch extrem seltsam vor, dass die Länge des originalen Passwortes gespeichert wird. Wenn man das nämlich nachrechnet, kommt man auf die 10%.

Ich bin kein Mathematiker aber ich komme nicht auf 10%. Wenn wir nur von Brute-Force ausgehen, dann verdoppelt jedes zusätzliche Schlüsselbit den Zeitaufwand. Würde man die statische Angabe weglassen und alle Längen darunter addieren (50% + 25% + 12,5% usw.) kämen wir genau auf den doppelten Wert, also 1 Bit. Wo ist da der Verlust/Gewinn?

Aber trotzdem ist es nicht falsch, dass die Angabe der Schlüssellänge ein Schwachpunkt ist - jedenfalls bei AES. So ist AES 256 angreifbarer als AES 128, wie vor Jahren schon bei heise gelesen werden konnte.

Das hat mit der Schlüssellänge nichts zu tun, sondern mit der Rundenzahl (AES 256 = 14 Runden/128 Bit = 10 Runden bei 128 Datenbits) und dem geänderten Aufbau. Rijandel (der AES-Wettbewerber) ist von vorherein auf eine beliebige Rundenzahl, Schlüsselbreite (und auch variable Datenbreiten) ausgelegt worden. Mit geringen Modifikationen (mehr Runden) und 256 Schlüsselbits wird er auch in ferner, ferner Zukunft unknackbar bleiben. Das gilt dann nicht nur für Brute-Force, sondern auch für alle anderen stochastischen Angriffe, denn steigende Rundezahlen erhöhen die Zufälligkeit bzw verringern den Bezug der Bits zueinander. (Der Experte spricht dann von statistisch einwandfreiem Code.)

Edit: Mir ist jetzt eingefallen, wie du auf die 10 bzw. 90 Prozent kommst. Da es sich um eine Blockchiffre mit fester Länge handelt werden alle kürzeren Wortlängen aufgefüllt, wodurch sich doppelte Kombinationen bilden. Die müssen wieder herausgerechnet werden und dann kommt man vermutlich auf einen Wert zwischen 0,1 und 0,9 Bit.

Antworten |