[10.9 Mavericks] Wie lange muss ein FileVault 2-Passwort sein.

[SilentCry]

Liebe Freunde der Sicherheit,

ich habe mal einen Blick auf Apples Recovery-Key geworfen. Das sind 6 Blöcke zu je 4 Zeichen, die nur Ziffern und Großbuchstaben sein können.
Also:
10 Ziffern + 26 Großbuchstaben ergibt den Zeichensatzumfang z=36
6x4=24, Länge des Passworts l=24

Ergibt 36[SUP]24[/SUP] Möglichkeiten.

Wenn man nun eine Passphrase vergibt und sich ebenfalls auf 36 mögliche Elemente beschränkt, darf die eigene Passphrase nicht kürzer sein als diese 24 Zeichen, sonst ist die eigene Passphrase unsicherer als Apples Key.

Was nun, wenn man gerne, weil man sie oft tippen muss, eine kürzere Passphrase haben möchte? Wie viel mehr mögliche Zeichen braucht man, um ein kürzeres Passwort verwenden zu können.

Ich habe mal die 36 erweitert um weitere 26 Kleinbuchstaben plus 20 Sonderzeichen. Das sind all die, die man direkt (also nicht das Accént oder so, das ein weiteres Zeichen braucht um zu wirken) auf einer deutschen Tastatur eingeben kann: ,.-#+?*'_:;!"§$%&/()=

Ergibt z=82 und mit l=24 demnach 82[SUP]24[/SUP], also viel mehr Möglichkeiten.

Bei welcher Passphrase-Länge x ist bei 82 möglichen Zeichen die Anzahl der möglichen Passphrases aber nun gleich der des Recovery Keys? Also wann ist 82[SUP]x[/SUP]=36[SUP]24[/SUP]?

Dazu muss man x "runter" bringen. Um das zu können muss man sich die Definition des Logarithmus (die Umkehrung der Potenz) vor Augen führen, kurz aus dem Gedächtnis: "Der Logarithmus ist jene Zahl mit der man die Basis potenzieren muss um den Numerus zu erhalten".

Aus 82[SUP]x[/SUP]=36[SUP]24[/SUP] wird also x=log[SUB]82[/SUB](36[SUP]24[/SUP])

Tja, wenn man nun aber nicht gerade ein Mathematikprogramm zur Verfügung hat dann kann man den Logarithmus zu einer Basis von 82 nicht berechnen AUßER man weiß, dass sich jeder Logarithmus auf den ln (Logarithmus Naturalist) zurückführen lässt, also ln des Numerus durch den ln der Basis, in dem Fall:
x=ln(36[SUP]24[/SUP])/ln(82)

Das ergibt rund für x=19,52, also eine Länge von 20.

Das Traurige: Man erspart sich nur vier Zeichen.

Wenn jemand möchte, kann er mal nachrechnen, wie groß der Zeichenraum sein muss, wenn man ein Passwort von einer Länge von "nur" zwölf Zeichen verwenden will:

z[SUP]12[/SUP]=36[SUP]24[/SUP]
ergibt für z=1296.
Einen Zeichenraum von weit über tausend Zeichen - nun, damit können wohl nur Chinesen dienen und das macht die Eingabe nun auch nicht leichter.

 

[DaMikstar]

36 Zeichen auf jeder der 24 Stellen ergibt 36^24 Möglichkeiten.2,245*10^37 Möglichkeiten. Das dürfte sicher genug sein.

Selbst mit einem deutlich kürzeren Passwort bewegt man sich immer noch in einem ähnlich sicheren Bereich, da deutlich mehr Zeichen zur Verfügung stehen und auch Groß-/Kleinschreibung berücksichtigt wird.

 

[SilentCry]

Den Kommentar verstehe ich nicht. Ich habe nirgendwo ein "Mal" geschrieben.
Ob der Recovery Key sicher genug ist, kann man natürlich auch diskutieren, das war aber hier nicht mein Thema. Ich wollte herausarbeiten, wie kurz man eine Passphrase wählen darf, um nicht unsicherer als der Recovery Key zu sein. Und da kommt man nicht sehr weit drunter, denn meine Annahme mit all den Sonderzeichen ist schon sehr optimistisch in der Realität. Da kann man schon froh sein, wenn Menschen Ziffern zu den Passphrases hinzufügen. Dennoch spart man sich nur 4 Zeichen.

 

[Bananenbieger]

36^24 = 2,245 * 10^37

 

[Rastafari]

Da kann man schon froh sein, wenn Menschen Ziffern zu den Passphrases hinzufügen.

Schön wäre es wenn sie damit endlich mal aufhören würden.
Die am häufigsten verwendeten "Phrasen" sind nach wie vor 1234567890, das Geburtsdatum oder die Telefonnummer.
Nicht hilfreich.

 

[pti'Luc]

Moin ... also, von der Struktur her ist es doch so, dass man mit seinem eigenen Passwort nur den eigentlichen Schlüssel für FileVault 2 verschlüsselt. bedeutet also, dass das eigene Passwort und damit dessen Länge überhaupt nicht vom Schlüssel für FileVault 2 ab. Du musst Dir somit nur Gedanken darüber machen, wie einfach Dein Passwort sein soll und wie schnell sich dieses dann knacken lassen würde (z.B. via Brute-Force). Da der Schlüssel für FileVault 2 per Zufall erzeugt wurde und das System eigentlich nicht verlässt (es sei denn, Du speicherst was bei Apple - aber auch das ist wieder nur ein Schlüssel zum eigentlichen Schlüssel), ist er ja nicht bekannt und man müsste eine Schwäche finden, die in der Verschlüsselung des Schlüssels von FileVault 2 mit dem von Dir angegebenen Schlüssel besteht.

Das ist ja auch der Grund, warum man einfach sein Passwort für den Login ändern kann, weil dann nur der FileVault 2 Schlüssel neu verschlüsselt wird und nicht das gesamte System.

Ein wenig mehr auch hier: http://www.heise.de/security/artikel/Lions-Full-Disk-Encryption-analysiert-1669663.html

 

[ImperatoR]

AES-128 verwendet einen 128-Bit langen Schlüssel, die Blocklänge ist bei allen anderen Varianten auch 128 Bit. Das sind 2^128 Möglichkeiten.

Obergrenze für Rechenleistung, die im Vergleich mit der Gesamtleistung der Sonne die auf die Erde abgegeben wird, ist maximal 3*10^45 Bitoperationen pro Jahr. Oder wenn wir die gesamte Erde mit Flash-Speichern vollpflastern kommen wir auf maximal 10^45 Bit Speicherkapazität. Das ist schonmal relativ unmöglich diese 2^128 Möglichkeiten durchzuprobieren.

Wenn du dein Passwort mit einer UTF-8 Kodierung wählst, würde in dem Fall ein Passwort aus 7 Zeichen reichen um einen 128-Bit Schlüssel zu füllen—sofern darauf keine Wortbuchattacke gefahren werden kann oder es einfach leicht zu erraten ist. In Anbetracht der Blocklänge bringt dir ein längeres Passwort nicht wirklich viel.

(Der Angreifer muss ja nur die richtigen 128-Bit erraten, da kann dein Passwort so lang sein wie es will. Jedoch braucht er einen Indiz auf einen Plaintext, da er sonst seine erratenen Schlüssel nicht verifizieren kann. Denn die einzelnen Blöcke entsprechen ja quasi einem One-Time Pad—und diese ist theoretisch beweisbar sicher.)

Aus Vorlesungsskript [Grundlagen der Kryptologie 2013, Harald Vater]. Das Bild im Anhang ist eine Darstellung der Verschlüsselungsfunktion von AES. (ebd.)

Mein persönliches Fazit: man kann sich auch alles unnötig schwer machen mit einer übertriebenen Paranoia. Aber ich finde es gut, dass sich mache Menschen wenigstens noch darum kümmern und es hinterfragen.

 

[SilentCry]

Hm. Das ist alles richtig und sehr interessant hier. Freut mich auch, dass sich doch jemand für meinen Thread interessiert, jedoch hoffe ich, dass meine Botschaft angekommen ist: Wenn ein Angreifer seine Bemühungen auf das Knacken des Recovery Keys legt - und das erscheint dann sinnvoll, wenn er davon ausgehen muss, dass der paranoide Anwender (ich) einen halben Roman mit Sonderzeichen als Passphrase gewählt hat, Apple aber "nur" 24 Stellen und 36 Zeichen... ah... jetzt während ich das schreibe erschließt sich mir "Imperators" Posting.
2[SUP]128[/SUP] =32[SUP]8[/SUP] also wesentlich weniger als 36[SUP]24[/SUP]

Ich muss jetzt was anderes machen, aber ich werde gleich dann mal ausrechnen, wie lange ein PWD sein muss um 2[SUP]128[/SUP] zu schlagen. Ich habe nicht bedacht, dass Apple "nur" AES128 verwendet. (Obwohl ich auch mal durchdenken muss, dass das vielleicht nicht ganz so simpel ist, Buchstaben und Ziffern enthalten ja nur ein Subset von Bitmustern, die möglich wären....)

 

[MACaerer]

Der rechnerische Ansatz, dass 24Zeichen in einem Zeichenvorrat von 36 = 36^24 ergibt, ist allerdings nicht richtig. Die Anzahl der Möglichkeiten muss über die Binominal-Koeffizienten gerechnet werden. Also nicht 36 hoch 24 sondern 36 über 24 (36 * 35 * 34 ….. * 24). Wer mag kann das mal ausrechnen, es ist deutlich weniger als die Exponentenrechnung aber immer noch mehr als genug um gegenüber einer Brute-Force-Attacke hinreichend sicher zu sein.

MACaerer

 

[SilentCry]

Blödsinn. Sorry. Wenn ich A B und C als Zeichen habe und 5 Stellen, dann habe ich
bei Stelle 1 die Wahl aus 3 Zeichen = 3 Möglichkeiten
bei Stelle 2 die Wahl aus 3 Zeichen = 3*3 Möglichkeiten
bei Stelle 3 die Wahl aus 3 Zeichen = 3*3*3 Möglichkeiten
bei Stelle 4 die Wahl aus 3 Zeichen = 3*3*3*3 Möglichkeiten
bei Stelle 5 die Wahl aus 3 Zeichen = 3*3*3*3*3 Möglichkeiten.

Also 3 hoch 5 Möglichkeiten in Summe.
Das ist ein "unabhängiges Ziehen mit Zurücklegen", die As, Bs und Cs "verbrauchen" sich ja nicht.

 

[Bananenbieger]

Ich habe nicht bedacht, dass Apple "nur" AES128 verwendet.

AES 128 ist dabei aber nicht unsicherer als AES 256: http://www.heise.de/security/meldung/Einschlaege-bei-AES-256-kommen-naeher-749257.html

Das ist ein "unabhängiges Ziehen mit Zurücklegen", die As, Bs und Cs "verbrauchen" sich ja nicht.

Theoretisch hast Du recht, praktisch scheuen Menschen aber die Mehrfachverwendung von Zeichen in einem Passwort. Sie meinen zwar, dadurch ein sichereres Passwort zu haben, in Wahrheit jedoch machen sie es dem Angreifer einfacher, da er davon ausgehen kann, dass Kombinationen wie z.B. "aa", "aA", "n38.aika" wahrscheinlich nicht im Passwort vorkommen. Daher sind Passwortgeneratoren meist die bessere Alternative, auch wenn sie keine 100% echten Zufallszahlengeneratoren verwenden.

 

[SilentCry]

Das Problem mit den 128 Bit ist viel schwerer. Der 128 Bit-Block ist ok, aber auf einer Tastatur stehen auch bei UTF8 nicht 256 Tasten zur Verfügung.
Ich denke, dass "mein" Zeichenvorrat von 82 vermutlich nicht mal mehr sehr praxisnahe ist.

Ich versuche mal einen Ansatz: Zu schlagen gilt es 2[SUP]128[/SUP] Möglichkeiten.

Zwischenüberlegung: Wir haben 82 Zeichen in einer (Annahme) UTF8-Codierung, also 82 Bitmuster von 256 möglichen Bitmustern.
Das bedeutet, wir brauchen rund 3x (eigentlich mehr) so viele Zeichen, um mit 82 Bitmustern die Varianz von 256 Bitmustern auszugleichen. (Da es aber 3,1... ist, müsste ich genau genommen sagen 4x so viele Zeichen). Lassen wir das aber. Weil eigentlich geht es um den Aufwand, etwas zu knacken. Und ob ich 128 Bit als Block brute forcen will oder eben eine Zeichenkette ist egal, es kommt nur darauf an, wieviele Möglichkeiten es gibt. Insofern kann diese Zwischenüberlegung verworfen werden.

Mit der Rechnung vom Anfang kommt man also erstmal auf die Frage 82[SUP]x[/SUP]=2[SUP]128[/SUP],
also x= ln(2[SUP]128[/SUP])/ln(82) also x=20,14.

Fazit: Um gleich gut zu sein als der Recovery Key (gebildet aus 26 Großbuchstaben und 10 Ziffern) ist ein Schlüssel von rund 20 Zeichen nötig, wenn man aus einem Alphabet, Gorß/Klein, Ziffern und Sonderzeichen wählt. Mit einem solchen Key (und damit auch mit dem Recovery Key) ist man ebenso gleichauf wie der echte 128-Bit Key, der zum tatsächlichen Verschlüsseln eingesetzt wird, was die Anzahl der Möglichkeiten betrifft, die ein brute force-Angriff berücksichtigen muss.

 

[MACaerer]

Blödsinn. Sorry. Wenn ich A B und C als Zeichen habe und 5 Stellen, dann habe ich
bei Stelle 1 die Wahl aus 3 Zeichen = 3 Möglichkeiten
bei Stelle 2 die Wahl aus 3 Zeichen = 3*3 Möglichkeiten
bei Stelle 3 die Wahl aus 3 Zeichen = 3*3*3 Möglichkeiten
bei Stelle 4 die Wahl aus 3 Zeichen = 3*3*3*3 Möglichkeiten
bei Stelle 5 die Wahl aus 3 Zeichen = 3*3*3*3*3 Möglichkeiten.

Also 3 hoch 5 Möglichkeiten in Summe.
Das ist ein "unabhängiges Ziehen mit Zurücklegen", die As, Bs und Cs "verbrauchen" sich ja nicht.

Richtig, da bin ich jetzt irgendwie voll danebengelegen (Alterssenilität?). Ich habe einfach nicht daran gedacht, dass man einzelne Zeichen auch mehrfach verwenden kann. Die Binominalkoeffizienten gelten natürlich nur dann wenn man einzelne Zahlen/Zeichen nach dem Ziehen nicht mehr da sind wie beim Lotto. Sorry. :-c

MACaerer

 

[Rastafari]

Irgendwie sind diese Diskussionen immer wieder köstlich. Immer dieser blinde Glaube an die schiere Länge von Kennworten... lustig.

Übrigens hauen hier fast gar keine Berechnungen so richtig hin.
Hinweis: Der Zeichensatz des automatisch generierten Schlüssels beträgt nicht 36, sondern nur 32.
Es handelt sich um eine althergebrachte CRC-Schreibweise mit 6 Blöcken aus effektiv 4 Zeichen, aus jeweils 32 möglichen, pro Nybble ein Prüfbit.
Ergibt pro Viererblock exakt 16 Bit Nutzdaten == 96 Bit Zufallsdaten im Gesamtstring.
Schlägt man da als Saltwert noch die 64-bittige VSDB-ID des zugrunde liegenden CS-Containers dazu (das wäre auch ein Zufallswert, der aber aus anderer Herkunft stammt), kommt man letztendlich auf 2^160 Permutationen.
Ein optimal dimensionierter Eintrittsvektor in den in Folge verwendeten SHA-1 Hash (von gleicher Länge).

 

[Paganini]

Vielleicht sollte man mal darauf hinweisen, dass bei einer Brute-Force-Attacke auf einen Schlüssel mit n Möglichkeiten die Wahrscheinlichkeit 50 Prozent beträgt, den passenden Schlüssel nach n/2 Versuchen zu ermitteln. Hört sich total logisch an, bedeutet aber, dass im mittleren Durchschnitt der Schlüssel schon nach der Hälfte der Versuche ermittelt wird, es ist also wahrscheinlich, dass selbst der komplexeste Schlüssel doppelt so schnell gefunden wird, als diese ganzen Rechenübungen suggerieren.

 

[Rastafari]

Angenommen du verfügst über Spezialboards mit wahren Monster-VLSI, die 1048576 Schlüssel parallel und realsimultan antesten können.
Angenommen diese schaffen das in nur einem einzigen Takt pro Wert, bei 1 THz Arbeitsfrequenz.
Angenommen du verfügst über 1048576 socher StarTrek-fähigen Maschinen.

Sämtliche Permutationen eines 128 Bit Zahlenraums durchzugehen dauert damit immer noch knapp 9 Millionen Jahre.
Ob diese statistische Hälfte da wirklich von Belang ist? Ich weiss ja nicht so recht.
Schönen Gruss von "Deep Thought".

 

[Balkenende]

Ich weiß ja nicht, was Rastafari geraucht hat. Aber davon will ich auch was

Die Beschreibung hätte ja glatt von mir sein können. Aber nicht nüchtern. Und verstanden hätte ich die auch nicht.

Aber gut zu wissen. Werde ich meinen Kollegen gleich in der Mittagspause mal erklären.

Moment. Da brauch ich doch noch mal eine Rechnung, welcher Bruchteil das versteht.

 

[SilentCry]

Ich bin froh, das die Diskussion weiter geht.
Zum Verständnis muss man aber jetzt differenzieren, worauf wir uns beziehen. Es gibt meiner Ansicht nach drei Möglichkeiten, BF gehen FV2 einzusetzen. Ich bitte für die weitere Diskussion immer anzugeben, auf welche man sich bezieht, wenn es nicht für alle gilt:

• BF A: Gegen den Recovery-Key (Vorteil: Man weiß genau, wie lange er ist und welche Zeichen er enthält)
• BF B: Gegen den 128 Bit-Schlüssel. (Undurchführbar, gibt aber die maximale Sicherheit, die durch Passphrase und Recovery Key nicht unterschritten werden darf, vor)
• BF C: Gegen die Passphrase des Users. (Möglicherweise ein Vorteil, wenn der User ein kurzes oder unsicheres PWD verwendet)

Ich denke, ein BF B können wir ausschließen. Die Möglichkeiten sind 2[SUP]128[/SUP]. (entspricht rund 3,403E38)
Die anderen beiden waren Gegenstand meiner Berechnungen.

Rastafaris Einwurf verstehe ich allerdings nicht. Wenn ich Ziffern und Großbuchstaben habe, stehen mir 36 _Zeichen_ Zur Verfügung. Wenn in dieser Zeichenkette "berechnete Bits" vorkommen sollen, frage ich mich, wie das geht. Denn wenn bei der Berechnung der Bits kein valides Zeichen raus kommt, was macht der Algorithmus dann? Oder kommen nur solche Zeichenketten vor, die als Prüfbits ein Zeichen zulassen, das es auch gibt? Wenn das so ist, muss man FV2 aber als "broken by design" ansehen, denn dann sinkt die Anzahl der Möglichen Recovery Keys dramatisch.
Kann ich jetzt mal so nicht glauben, es sei denn, ich sehe eine Apple-Dokumentation, in der das ausgeführt wird.

 

[Rastafari]

Wenn ich Ziffern und Großbuchstaben habe, stehen mir 36 _Zeichen_ Zur Verfügung.

Dann muss es wohl auch 36 Hexadezimalziffern geben? Oder doch nur 16?

Denn wenn bei der Berechnung der Bits kein valides Zeichen raus kommt, was macht der Algorithmus dann?

Ganz gewaltigen Mist.

Oder kommen nur solche Zeichenketten vor, die als Prüfbits ein Zeichen zulassen, das es auch gibt?

Irgendwie ist das wohl der grundlegende Plan bei ausnahmslos allen Prüfzifferverfahren.

Wenn das so ist, muss man FV2 aber als "broken by design" ansehen, denn dann sinkt die Anzahl der Möglichen Recovery Keys dramatisch.

Autschn. Na, dann ist wohl das ganze Internet "broken". Wenn du das sagst...
Schliesslich sind solche Standardverfahren ja nur das Thema einer gefühlten Hundertschaft von RFCs.
Vielleicht ist es ja was völlig anderes, das hier "broken" ist?

Kann ich jetzt mal so nicht glauben, es sei denn, ich sehe eine Apple-Dokumentation, in der das ausgeführt wird.

Muss Apple demnächst auch noch erklären, wie man aus Bits ein Byte bildet?
Mann, das sind Grundlagen von ganz unten, vom Fussboden der IT.
Existiert in einer unüberschaubaren Unzahl von Variationen und ist als Prinzip älter als die Hollerith-Lochkarte.
Mit solchen "Tricks" werden Binärzahlen in menschenlesbare Formen gebracht seit... da könnte Thomas Alva Edison noch gelebt haben.

 

[SilentCry]

Rastafari - nochmal: Der Recovery Key besteht aus 6x4 Zeichen. Diese Zeichen werden aus einer Menge von 36 gewählt. Die Anzahl der Möglichkeiten ist demnach 36[SUP]24[/SUP]
Wenn ein Hacker also auf diesen Key einen Angriff per Bruteforce fahren will muss er sich in diesem Raum aller möglichen Kombinationen bewegen. Fullstop.

Ich verstehe nicht, was deine Prüfbits hier sollen. Wenn du meinst, dass in der Zeichenkodierung Prüfbits enthalten sind und deswegen die Binärentsprechung von 36 Zeichen gleich 96 Bits beträgt, bitte, ja, natürlich, dann liegen wir laut deinen Angaben bei 2[SUP]96[/SUP] für den binär dargestellten Recovery Key.

Vergleich:
AES128: 3,403 E38
Recovery Key binär ala Rastafari: 2[SUP]96[/SUP]= 7,932 E28
Recovery Key Character-Mode: 36[SUP]24[/SUP]= 2,245 E37

Wenn also die Zeichensatzkodierung eines Buchstabens oder einer Ziffer eine berechenbare Prüfsumme enthält, dann kann man binär etliche Kombinationen ausschließen. Unter der Annahme muss also die eigene Passphrase "nur" besser sein als rund 8E28, wobei aber dann auch die Passphrase binär reduziert wird um die Prüf-Bits.

Ich habe mal UTF-8 angesehen. Ein Buchstabe y ist 01111001. Die führende Null ist fix. Das ist so, damit die 128 möglichen Zeichen ASCII-konform sind. Ich gehe also davon aus, dass Großbuchstaben und Ziffern deswegen gewählt wurden. Damit besteht der Recovery Key aus 24 Blöcken zu je 7 Bit. Berechnete Prüfbits sehe ich nicht.

Jedes dieser 7-Bit-Blöcke kann 36 Zustände annehmen. Das wäre übrigens auch so, wenn jedes Zeichen 2 Prüfbits angehängt bekäme. Damit wird wieder jeder Block für sich eine Chance von 1:36, wenn ich ihn erraten will. Egal ob ich nun Buchstaben und Ziffern erraten will oder aus einem Topf mit 36 Bitmustern ziehe.

Damit bleibt es dabei: Der Aufwand, alle Recovery-Keys abzubilden liegt bei 36[SUP]24[/SUP] Möglichkeiten. Deine "Prüfbits" spielen hier keine Rolle.

Edit: ROT berichtigt.