Full-System-Encryption - Softwareempfehlung

[BessereHälfte]

Und weiter gehts
https://veracrypt.codeplex.com/wikipage?title=Release Notes

 

[onotop]

Habe mal folgenden Beitrag gefunden zu dem Problem, dass es bis zu 3min dauert bis meine HDD bootet
VeraCrypt / Forums / Technical Topics:long boot time

 

[TCM]

"Another reason is that the encrypted partition doesn't contain any indication about the encryption algorithm for security reasons."

Die meinten wohl "obscurity reasons". Das halte ich schon für fragwürdig. Wer weiß, welche Entscheidungen die in Zukunft noch treffen, bei denen sie denken, es diene der Sicherheit.

Edit: Auch die Iterationen so hoch zu setzen, dass es in die Minuten geht, ist eigtl. komplett sinnlos. Der Sinn hinter den Iterationen ist, dass brute-force nicht mehr mit x Milliarden Versuchen pro Sekunde geht, sondern halt z.B. mit 2 pro Sekunde. Es würde völlig reichen, wenn der Durchlauf pro Algorithmus eine halbe Sekunde dauert. Das bis in die Minuten zu strecken, zeigt eigtl. nur, dass die auch das nicht verstanden haben.

Und dann sowas:

"For those who prefer to have a fast boot, we are currently implementing a security level choice where the user can choose to have strong, medium or low security.
The low security mode will be the fastest and at the sametime it will be stronger than TrueCrypt (10000 instead of 1000)."

Extra Codepfade einbauen, die absolut sinnlos sind. Jede sinnvolle Krypto macht es so, dass bei der Generierung des Containers die Iterationen automatisch so gewählt werden, dass eine feste Zeit verstreicht. Auf einem schnellen Rechner kriegt man dann z.B. 10000 Iterationen, auf einem langsameren 5000.

Was die da frickeln, halte ich für bedenklich und bleibe erstmal bei Truecrypt.

 

[BessereHälfte]

@TCM
Statt irgendwelche nicht greifbaren negativen Schwingungen im Ether verursachen zu wollen konntest du auch einfach erklären was daran obskur ist, wenn ein verschlüsselter Datensatz keine Infos darüber liefert, ob es mit AES, Twofish oder Serpent verschlüsselt ist.

Das Gleiche gilt für Iterationen. Statt zu bedauern , daß sie nicht gleich scrypt oder wenigstens bcrypt genommen haben, meckerst du über eine dir überlassene WAHL der Anzahl der Iterationen, die sie einem für PBKDF2 geben. Wobei die schwächste kaum in der Zeit auffällt und trotzdem 10x höher ist als bei TrueCrypt.

Eine Art autosensing dafür befreit dich nur vom Nachdenken und ist KEIN Sicherheitsfeature, da vernünftige Software eine Grenze für die möglichst niedrige Anzahl haben wird. Niemand bei Sinnen der etwas von ASICs gehört hat wird heute selbst auf einem AthlonXP 1.6 irgendwas um 500 zulassen, nur damit man beim Mounten unterhalb von 5s liegt.
Dann kann man ja auch gleich den Algo autosenensen und für schlappe Kisten MD5 und (Single)DES nehmen. Oder wie?

Keine Ahnung warum du versuchst Problemfelder zu generieren wo keine sind. Irgendwie ist es grad bisschen merkwürdig hier...

 

[TCM]

Ach, man kann die Iterationen wählen? Das klang alles so, als wären die fest. Müssen sie ja eigtl. auch sein, wenn es keinen Header gibt, der die Anzahl enthält.

Das Geheimhalten des verwendeten Algorithmus bietet für die Sicherheit des Algorithmus keinerlei Gewinn. Das ist eine der Grundregeln bei Krypto. Die Sicherheit hängt einzig am Key und nicht daran, dass keiner weiß, womit man verschlüsselt.

Ich seh natürlich im Nachhinein ein, dass der Algorithmus hier nicht das einzige Angriffsziel ist, sondern dass man u.U. geheimhalten will, dass man überhaupt verschlüsselt, um sich nicht anderen (physikalischen) Angriffen auszusetzen.

Eine Art autosensing dafür befreit dich nur vom Nachdenken und ist KEIN Sicherheitsfeature, da vernünftige Software eine Grenze für die möglichst niedrige Anzahl haben wird. Niemand bei Sinnen der etwas von ASICs gehört hat wird heute selbst auf einem AthlonXP 1.6 irgendwas um 500 zulassen, nur damit man beim Mounten unterhalb von 5s liegt.
Dann kann man ja auch gleich den Algo autosenensen und für schlappe Kisten MD5 und (Single)DES nehmen. Oder wie?

Autosensing der Iterationen mit einer fixen Untergrenze ist genau das, was sinnvoll wäre.

Ansonsten darfst du mir gerne erklären, welchen Sinn es hat, die Iterationen so aufzublasen, dass es eine Minute statt einer Sekunde dauert. Wenn ich brute force schon auf einen Versuch pro Sekunde gedrosselt habe, ist das mehr als ausreichend, denn der Ausgangszustand sind mehrere Milliarden Versuche pro Sekunde. Wenn ich den Angriff von potentiell 6 Millionen Jahren auf 6 * 10^18 Jahre verlängert habe, bringt es genau gar nichts, da noch einen Faktor 60 dranzuhängen, wenn dadurch die Software unbenutzbar wird.

Viel viel wichtiger ist die Qualität des Passworts und dass die Software benutzbar bleibt. Hohe Iterationen, um ein schwaches Passwort zu schützen, ist ein völlig falscher Ansatz, wenn die Software dadurch für alle weniger benutzbar wird.

Edit: Ich weiß zumindest, dass ich nicht eine Minute beim Booten warte, nur weil die Software nicht glaubt, dass ich ein starkes Passwort wählen kann. Was natürlich schade ist, weil ich dadurch evtl. andere Verbesserungen ggü. Truecrypt verpasse. In der Gesamtsituation verbessert sich die Sicherheit dadurch nicht, weil weniger Leute VC einsetzen.

 

[BessereHälfte]

Ach, man kann die Iterationen wählen? Das klang alles so, als wären die fest.

Für mich klang das als wenn es 3 Stufen gäbe.

Das Geheimhalten des verwendeten Algorithmus bietet für die Sicherheit des Algorithmus keinerlei Gewinn. Das ist eine der Grundregeln bei Krypto.

Nein. Das Geheimhalten des Codes des Algos bietet keine Sicherheit bzw. erhöht sie nicht. Du hast da was verwechselt.

Die Sicherheit hängt einzig am Key und nicht daran, dass keiner weiß, womit man verschlüsselt.

Weiß man doch. Es ist entweder AES oder Twofish oder Serpent. Oder eine Kaskade davon. Die Soft macht kein Gehemnis draus.

Autosensing der Iterationen mit einer fixen Untergrenze ist genau das, was sinnvoll wäre.

Schon klar. Ein von deinen beiden stark vorgetragenen Einwände sagt aber nur aus, "ich bin bei dieser Sache halt bissl faul". Das hat mit security aber nichts zu tun.

Ansonsten darfst du mir gerne erklären, welchen Sinn es hat, die Iterationen so aufzublasen, dass es eine Minute statt einer Sekunde dauert.

Die Iterationen sind nicht dafür da damit jeder möglichst schnell sein Volume bootet. Was soll denn Serpent da, wenn AES-IN unterstützt wird?
Das ist aber eh ein Punkt wo ich nicht ganz mitkommen. Ich hab mal mit 1.0f eine Platte verschlüsselt und mein i5 mountet die in ~2s. Ich frag mich schon seit einiger Zeit an welcher Stelle ich nicht aufgepasst habe, daß mir das Prob mit dem langen Mounten unter VeraCrypt nie auffiel (?)

Viel viel wichtiger ist die Qualität des Passworts und dass die Software benutzbar bleibt. Hohe Iterationen, um ein schwaches Passwort zu schützen, ist ein völlig falscher Ansatz, wenn die Software dadurch für alle weniger benutzbar wird.

Dem stimme ich natürlich zu.

Edit: Ich weiß zumindest, dass ich nicht eine Minute beim Booten warte, nur weil die Software nicht glaubt, dass ich ein starkes Passwort wählen kann. Was natürlich schade ist, weil ich dadurch evtl. andere Verbesserungen ggü. Truecrypt verpasse. In der Gesamtsituation verbessert sich die Sicherheit dadurch nicht, weil weniger Leute VC einsetzen.

Gilt. Du kannst dich damit in deren Forum natürlich einbringen. Aber wie gesagt fiel mir das nie auf. Irgendwas hab ich bei der Konfig wohl versemmelt (?) SO stark ist auch ein 2500k @4.3Ghz nicht. Oder reden wir hier vom Athlon500?

 

[TCM]

Die Iterationen sind nicht dafür da damit jeder möglichst schnell sein Volume bootet. Was soll denn Serpent da, wenn AES-IN unterstützt wird?

Die Iterationen sind dazu da, damit aus dem (kryptographisch schwachen) Passwort ein (kryptographisch starker) Key für AES/Serpent/... wird. AES-NI ist an der Stelle überhaupt nicht beteiligt.

Und nein, wenn das Mounten in 1s geht, ist das System nicht automatisch schwach. Wie bereits gesagt, es geht darum, den Bruteforce-Aufwand um Größenordnungen zu erhöhen. Es muss aber benutzbar bleiben. Deswegen setzt man PBKDF so ein, dass der Aufwand für legitime User im Bereich von Sekunden liegt und nicht Minuten.

Wer es bis zu Minuten hochschraubt, hats einfach nicht verstanden. Edit: Nur um mal die Dimensionen klarzumachen: Ein 16stelliges Passwort aus Groß-/Kleinbuchstaben und Zahlen hat, wenn es "echt" zufällig ist, ca 95 Bit Entropie. Nur Buchstaben und Zahlen, keine Sonderzeichen und "nur" 16 Stellen. Greift man 95 Bit mit z.B. 1 Billion Versuche pro Sekunde an, dauert das im Schnitt 628077138 Jahre. Wenn ich die Versuche auf 1/s drossele, dauert es 628077138145804299796 Jahre. Was bringt mir danach ein Faktor von 60 noch? Genau, nichts, außer dass mich meine supersichere Verschlüsselung täglich eine Minute nervt.

PS: Ich beziehe mich bei dem Ganzen nur auf die Berichte all derer, bei denen das Mounten auf aktueller Hardware angeblich minutenlang dauert.

- - - Updated - - -

Und wenn ich mir oclHashcat - advanced password recovery angucke, sind 1 Billion Versuche pro Sekunde heute noch ein kostspieliges Unterfangen, um ein einzelnes Passwort, welches mit 1 Iteration(!) benutzt wird, zu bruteforcen.

Bei SHA-512 stehen da z.B. 5240 Mh/s, wenn man 8 NVidia Titan-X einsetzt. D.h. um auf 1 Billion/s zu kommen, braucht man 190 Karten. Und dann dauert das die besagten 628 Millionen Jahre bei einem Passwort, was nur einmal gehasht wurde. Durch Reduzierung auf 1 Versuch pro Sekunde ist man bei besagten 628077138145804299796 Jahren. Hier dürfte jeder sehen, dass selbst eine Beschleunigung um das Zigtausendfache nichts bringt. Auch ASICs sind nicht magisch einfach quadrillionenmal schneller. Es ist schlicht nicht machbar in unserer Lebenszeit.

Und die VC-Macher hielten es für eine gute Idee, das nochmal um den Faktor 60 zu erhöhen, weil es sich sonst nicht sicher anfühlt, wenn der Container zu schnell mountet? Absolut sinnlos.

 

[BessereHälfte]

Ich hab das Prob erkannt... Das spackt nur mit Bootvolumes rum. Weil dabei 16bit-Kode läuft. Das ist arschlahm. 32bit Kode würde das ums 3fache beschleunigen.

Die aktuzelle Idee ist die Iterations nach länge des Passwortes zu dynamisieren. Bei 20 Zeichen vielleicht nur 5000 usw. Das wären 10s und nicht 1min. Wäre soweit ok.

die Chancen auf ein 32bit Bootloader was eine Win-GPT Partition startet sind sehr kleine. GPT hat wohl vorrang (find ich auch ok). Also muß man sich für die 16bit was einfallen.

Sonst bin ich bei dir. 1min. geht garnicht. Deine Einwände hat er aber teils auch schon selbst gebracht. Also daß wenn es so mies benutzbar ist, die Leute was anderes nehmen usw. Das ist ihm auch selbst schon klar.

 

[BessereHälfte]

Quasi DONE. mit der 1.12beta darf man die "Iterationen" zum Teil selbst bestimmen.

Ich finds zwar immernoch zuviel, trotzdem ist das Mounten nun auch z.B. auf 1.6Ghz Pentium-M endlich annehmbar. Sonst muß man eben akzeptieren, daß man für Crypto abseits AES-IN eines Intels halt bisschen Hardware braucht...

Es gibt ein Feld PIN woraus sich folgendes ergibt:
This field can be left empty or set to 0 to have the same behavior as before.
If a value is specified in PIN, then the iterations are calculated as follows:
For system encryption: Iterations = PIN x 2048
For non-system encryption and file containers: Iterations = 15000 + (PIN x 1000)

If the password is less than 20 characters, PIN must be greater than 98 for system encryption and greater than 485 for the other cases.
If the password is longer than 20 characters, PIN can be equal to 1 and upwards.

VeraCrypt - Browse /VeraCrypt Nightly Builds at SourceForge.net

 

[TCM]

Ich finds zwar immernoch zuviel, trotzdem ist das Mounten nun auch z.B. auf 1.6Ghz Pentium-M endlich annehmbar. Sonst muß man eben akzeptieren, daß man für Crypto abseits AES-IN eines Intels halt bisschen Hardware braucht...

Nochmal: Bei PBKDF2 ist AES-NI überhaupt nicht beteiligt. Der Schlüssel ist _für_ AES, er wird nicht _mit_ AES berechnet.

Es gibt ein Feld PIN woraus sich folgendes ergibt:
This field can be left empty or set to 0 to have the same behavior as before.
If a value is specified in PIN, then the iterations are calculated as follows:
For system encryption: Iterations = PIN x 2048
For non-system encryption and file containers: Iterations = 15000 + (PIN x 1000)

If the password is less than 20 characters, PIN must be greater than 98 for system encryption and greater than 485 for the other cases.
If the password is longer than 20 characters, PIN can be equal to 1 and upwards.

VeraCrypt - Browse /VeraCrypt Nightly Builds at SourceForge.net

OMG, komplizierter geht's wohl nicht. Die verrennen sich da in völlig blödsinnige Komplexität IMHO. Ich muss für mich daher bei der Einschätzung bleiben, dass solche Entscheidungen - komplett am best-practice angewandter Krypto vorbei - nichts Gutes ahnen lassen, was andere Entscheidungen angeht. Das schwächt in meinen Augen das Projekt extrem.

 

[BessereHälfte]

1.
Was bedeutet für dich "abseits"? Erklärst du mir das mit AES-IN jetzt absichtlich unnötigerweise, damit jemand der garkeine Ahnung hat den falschen Eindruck gewinnt, du weißt es besser?

2.
Kompliziert? Gute Crypto geht auch bei einfachen Leuten. Bei Deppen braucht sie nicht funktionieren. Das ist u.a. für ggbf. die Gegenseite gut, weil dann weiß man die Leute gleich beim Erstkontakt richtig einzuschätzen.
Wer mir dann erzählt, VeraCrypt wird nicht genutzt, weil das mit den Iterationen unnötig kompliziert ist, zu dem bau ich auch keine OpenPGP-Verbindung auf, weil es so wahrscheinlich ist, daß a)seine Passphrase fritz80 lautet und b)es eine leichtere Übung ist ihm einen Trojaner unterzujubeln.

Minimale Komplexität schadet der Sache insgesamt also nicht. Im Gegensatz...

Der Rest rechnet sich das paar mal aus, testet es paar mal an neuen kleinen Containern (Mount-Zeit) und merkt sich dann seine beiden Multiplikatoren, die es für system (boot) und nicht-system Volumes erwählt hat.
DAS WARS.

Zwei Zahlen wie 10 und 180 merken und vor allem ab jetzt: brauchbares Passwort genutzt.

Sehr kompliziert
Wobei... was es mit "best-practice" auf sich hat, hättest du noch erklären können. Du hängst mal wieder paar Thesen im Raum auf, sonst wortlos, die dabei gleich das Gefühl erwecken sollen das Orakel zu sein, und gehst wieder raus.

Was Diskussionskultur angeht ist das vom best-practice ziemlich weit entfernt

 

[TCM]

1.
Was bedeutet für dich "abseits"? Erklärst du mir das mit AES-IN jetzt absichtlich unnötigerweise, damit jemand der garkeine Ahnung hat den falschen Eindruck gewinnt, du weißt es besser?

"Sonst ... abseits von AES-NI ..." klang so, als hätte man mit AES-NI bei der Iterationsgeschichte irgendeinen Vorteil.

2.
Kompliziert? Gute Crypto geht auch bei einfachen Leuten.

Gute Crypto ist die, die man nicht falsch benutzen kann. Jede Entscheidung außer dem Passwort und maximal noch dem Algorithmus, die das Programm dem Nutzer abfordert, ist unnötig und kontraproduktiv. Leute, die gute Passwörter verwenden, brauchen keine aufgeblasene Iterationsanzahl. Und jetzt sollen Leute, die sich schon keine guten Passwörter ausdenken können, plötzlich noch eine informierte Entscheidung darüber treffen können, welche Iterationszahl gut ist? Und zur Krönung nennt man das dann "PIN", um die Leute, die eh schon nichts verstehen, noch komplett zu verwirren? Das ist nicht gute Crypto, das ist komplett "zerdacht".

Zwei Zahlen wie 10 und 180 merken und vor allem ab jetzt: brauchbares Passwort genutzt.

Sehr kompliziert
Wobei... was es mit "best-practice" auf sich hat, hättest du noch erklären können. Du hängst mal wieder paar Thesen im Raum auf, sonst wortlos, die dabei gleich das Gefühl erwecken sollen das Orakel zu sein, und gehst wieder raus.

Ganz einfach: Wer ein brauchbares Passwort hat, muss sich nicht irgendwelche Zahlen merken. Ich kenne kein anderes Programm, welches mir die Iterationen abverlangt. GELI z.B.:

                -i iterations   Number of iterations to use with PKCS#5v2.  If
                                this option is not specified, geli will find
                                the number of iterations which is equal to 2
                                seconds of crypto work.  If 0 is given,
                                PKCS#5v2 will not be used.

Es wäre absolut kein Problem, die Iterationszahl einfach vorzugeben. Es wird wohl kaum jemand am einen Ende des Spektrums einen 486er verwenden und am anderen Ende einen i7 6GHz+. Dann wäre das vielleicht ein Problem, weil die nutzbaren Iterationen auf dem 486er evtl. sogar zu schwach sind.

Eine Iterationszahl, die auf einem i7 vielleicht zu einer halben Sekunde CPU-Zeit führt und auf einem Core2 zu 5s, wäre ein sinnvoller Wert. TrueCrypt hats ja auch so gemacht, und es wurde komplett auditiert.

PBKDF2 ist nicht dazu da, ein schwaches Passwort mit einem weiteren Faktor zu schützen. PBKDF2 soll die Bruteforce-Möglichkeiten von Milliarden/Billionen pro Sekunde auf trotzdem noch benutzbare Werte drosseln. Es ist kein essentieller Faktor, den es perfekt zu tunen gilt. Wichtiger ist, dass es das Gesamtsystem nicht dermaßen komplex macht, wie man das bei VC grade sieht.

Warum du dich von meiner Kritik gegenüber VC irgendwie persönlich angegriffen fühlst, hab ich dann nicht so ganz verstanden. Arbeitest du da mit?

 

[BessereHälfte]

"Sonst ... abseits von AES-NI ..." klang so, als hätte man mit AES-NI bei der Iterationsgeschichte irgendeinen Vorteil.

Wenn man es unbedingt möchte, könnte man das so verstehen. Da hast du Recht.

Gute Crypto ist die, die man nicht falsch benutzen kann.

Man kann alles falsch benutzen. Leute sind schon mit einem Kugelschreiber erstochen worden. Wie kann man VeryCrypt falsch benutzen?

Jede Entscheidung außer dem Passwort und maximal noch dem Algorithmus, die das Programm dem Nutzer abfordert, ist unnötig und kontraproduktiv. Leute, die gute Passwörter verwenden, brauchen keine aufgeblasene Iterationsanzahl. Und jetzt sollen Leute, die sich schon keine guten Passwörter ausdenken können, plötzlich noch eine informierte Entscheidung darüber treffen können, welche Iterationszahl gut ist?

Sie sollen es nicht und sie müßen es auch nicht. Sie können es. Wenn man sich damit dagegen kurz auseinandersetzt, bekommt man als erstes mit, daß miese Passwörter mies sind.

Ok, jetzt kann man langsam Autos bauen die Leute fahren können bzw. in welchen Leute fahren können, die kein Auto fahren können. Alle die es dagegen können meinen, sie würden sich in sowas nie hinsetzen. Problem erkannt?

Und zur Krönung nennt man das dann "PIN", um die Leute, die eh schon nichts verstehen, noch komplett zu verwirren? Das ist nicht gute Crypto, das ist komplett "zerdacht".

PIN ist als Wortspiel bestens dazu geeignet. Das singalisiert den ganzen Vollpfosten, die du ja überall siehst, daß sie sich das merken sollen. Es gibt Password und PIN Das fand ich gar lustig

Wer vorhat irgendwas zu tun von dem er "nichts versteht", der sollte das erst noch einfach lassen. Und sich erst bisschen einarbeiten. Es haben mich auch schon Bekannte angerufen, die das erste Mal Excel gestartet haben, sie würden jetzt 30min. suchen und finden nicht heraus wie man einen Rahmen komplett um die Zeile macht.
Und jetzt? Hätte ich bei MS diese Dramaqueen-Nummer machen sollen die du auf Sourceforge machst?

Ganz einfach: Wer ein brauchbares Passwort hat, muss sich nicht irgendwelche Zahlen merken. Ich kenne kein anderes Programm, welches mir die Iterationen abverlangt.

Dann trag da nichts ein. Können kann man es bei einigen. Oder wer hier kennt KeePass nicht? Da wird der Count halt nur im Crypto mitgespeichert. Sonst wie VeraCrypt.

PBKDF2 ist nicht dazu da, ein schwaches Passwort mit einem weiteren Faktor zu schützen. PBKDF2 soll die Bruteforce-Möglichkeiten von Milliarden/Billionen pro Sekunde auf trotzdem noch benutzbare Werte drosseln. Es ist kein essentieller Faktor, den es perfekt zu tunen gilt. Wichtiger ist, dass es das Gesamtsystem nicht dermaßen komplex macht, wie man das bei VC grade sieht.

Wieviel ist denn ok? stackoverflow gibt mal auf die Schnelle folgendes her:
Sept 2000 - 1000+ rounds recommended (source: RFC 2898)
Feb 2005 - AES in Kerberos 5 'defaults' to 4096 rounds of SHA-1. (source: RFC 3962)
Sept 2010 - ElcomSoft claims iOS 3.x uses 2,000 iterations, iOS 4.x uses 10,000 iterations
OWASP has a Password Storage Cheat Sheet with some guidance; they recommend 64,000 PBKDF2 iterations minimum as of 2012, doubling every two years (i.e. 90,510 in 2013).

Mir scheint das ist kein Randproblem. Das da ist aber auch kein Beweis dafür. Das ist die Entstehung von bcrypt und scrypt.

Davon ab gefällt mir momentan die Tatsache, daß der Angreifer über das Hashing nur sehr grobe Infos hat.
Du bist ja auch schon rumgesprungen wegen den "3 bits" davor, weil er nicht so einfach den sym. Algo erraten kann. Als wenn das irgendeine Relevanz für die Vollpfosten hätte, die du ja überall siehst.

Warum du dich von meiner Kritik gegenüber VC irgendwie persönlich angegriffen fühlst, hab ich dann nicht so ganz verstanden. Arbeitest du da mit?

Man muß das erstmal deuten können. Wenn einer im Kino plötzlich aufspringt und mit den Armen fuchtelt, dann hat entweder sein Nachbarn gefurzt, der Film geht garnicht für ihn oder er ist kurz davor wegen seinem Scheidungskrieg Amok zu laufen. Das weiß man erstmal nicht

Bist du auch auf SELinux und OpenBSD mailinglists unterwegs und springst da im Dreieck rum, wie blödsinnig es ist ein 10x sicheres OS als Windows zu machen, mit welchem kein Windowsnutzer klar kommt?

Das Ulkigste bei dieser Rumhopserei hier (und da) ist aber, daß man ja wohl selbst kein Vollpfosten ist und trotzdem nicht wahrnehmen kann, daß die Leute einfach Passwörter mit >20 Zeichen nutzen sollen und sich damit um PIN nicht kümmern müßen.
Immer brav überall 1 tippern und das Mounten dauert nur ein Augenzwinker, das Passwort bleibt aber bestens gesichert.

Ich beschmeisse jedenfalls keinen Programmierer mit Ziegeln, nur weil seine Soft plötzlich eine kleine Optuion bekommt die ich nicht brauche.
Was der Quatsch also GENAU soll, das könntest du vielleicht noch erklären. Das ist jetzt aber nur wie bei VeraCrypt. Du mußt es nicht und du sollst es nicht. Du kannst es halt.

 

[DragonTear]

daß die Leute einfach Passwörter mit >20 Zeichen nutzen sollen und sich damit um PIN nicht kümmern müßen.

Ja, super Kompromiss... 20 Stellen merkt sich doch kein Mensch halbwegs freiwillig, ohne zum Großteil Wörter zu verwenden... und dann ist man doch wieder für Wörterbuch-Attacken angreifbar.

Sache ist, heute unterwirft sich niemand (mehr) freiwillig der Software! Dagegen betrachtet man es immer nach Nutzen vs Aufwand.
Daher hat die Software, welche seine Funktionalität einfacher bereitstellt, immer vorrang. Das lernen wir im ersten Semester der Informatik und wenn es ein Programmierer schwieriger macht als notwendig, sollte man ihn schon "mit Ziegeln beschmeissen", aber das regelt der Markt ja von selbst

Das ist auch der Grund wieso z.B. kaum jemand (der nicht irgendwelches Zeug am Rande und hinter der Legalität macht) regelmässig PGP verwendet (ich kenne zumindest niemanden) obwohl das auf ersten Blick sehr mächtig und wie eine "Lösung aller Probleme" klingt (ich kenne ja selbst auch die Algos dahinter).
Unser Prof hats uns aber mal in der Praxis vorgeführt.. da kann ich nur sagen.. KÄSE, da nehm ich doch lieber im kauf dass die NSA weiss was ich gefrühstückt habe
Inzwischen werden Mails aber ja bei den meisten Anbietern doch automatisch verschlüsselt übertragen (auch wenn das nicht Client-to-client ist, wenn ich mich nicht irre).

 

[BessereHälfte]

Dann denk dir eine PassPHRASE aus. Das nannte sich bei PGP schon immer so. Mit Recht.

Da ich in der Tat nicht gleich der Obercracker bin, wollte ich eigentlich schon immer mal fragen wie ein Wörterbuchangriff auf Fusswohl4Frodo_Hobbit funktioniert. Weiß das hier jemand?

Du hast da mit der Unterwerfung irgendwie was verwechselt. Alleine schon deswegen, weil dir bei der Formulierung die "keiner"-Abermilionen der Apple-Nutzer nicht eingefallen sind.

Wenn ich DiskCryptor nutze, dann unterwerfe ich mich der Software. Die macht bei Systemdisks nur 1000 iterations. Wobei ich es nutze und das gerne (SSD halt). Aber der Code ist ja offen. Man findet diese Vorgabe also schon

Das ganze Trara gibt es eigentlich eh nur wegen Systemdisks. Weil da meist nur 16bit Code reinpasst und das rechnet eben sehr lahm. Das sind gute Passwörter mit welchen man den count sparen kann eben Gold wert. Falls man EIN so ein Passwort behalten kann.

Steht das System nutzt man KeePass&Co. und da kann man mit Zeichenketten aka Passwörtern wuchern. Da würden auch 2000 Iterationen reichen

PGP hat mit dem Handling weder was am Hut noch überhaupt was damit zu tun. Mit GnuPG zeigt Enigmail auf Thunderbird wie es geht. Einfachste Bedienung. Das kriegt übrigens GPGTools für OSX's Mail ebenso brauchbar.

Wenn das mit Outlook ungleich aufwendiger funktioniert, gehört das nicht zum PGP-Kümmerkasten. Entweder hat Outlook miese Plugin-Features oder die Plugins sind mies.

Vielleicht erstmal einfach warten mit der Beteiliegung hier, bis das zweite Semester anfängt. Dann stellen sich auch nicht solche Thesen auf, im O-Ton, daß entweder der DSL-Provider mies ist oder die Routerfirmware, wenn eigentlich die Netzwerkstrippe einen Kabelbruch hat...

Bis die Tage.

 

[DragonTear]

Dann denk dir eine PassPHRASE aus. Das nannte sich bei PGP schon immer so. Mit Recht.

Gut, das ist eine Möglichkeit, benutze ich selbst teilweise auch. Aber vor Wörterbuchangriffen ist das auch nicht sicher.

Da ich in der Tat nicht gleich der Obercracker bin, wollte ich eigentlich schon immer mal fragen wie ein Wörterbuchangriff auf Fusswohl4Frodo_Hobbit funktioniert. Weiß das hier jemand?

Technisch ist das keine große Sache. Wenn du Zugriff auf eine Wortdatenbank hast, kannst du dessen Inhalt auch als Strings zusammenwürfeln wie du willst.
Denke viele User nutzen solch einzelne Zahlen oder Sonderzeichen, so dass es sich anbieten würde, auf diese Art und Weise die Bruteforce Methode durchzuführen. Aber keine Ahnung wie der Alltag eiens Crackers aussieht Das cryptografischte was ich bisher geknackt habe, war die Vigenere-verschlüsselung im Rahmen einer selbstständigen Übung,..

In der Praxis wird das wahrscheinlich sowieso eher weniger gemacht, da man sich ja lieber einfachere Möglichkeiten (kürzere Passworter sucht). Es ist vom Aufwand her, das selbe ob man für 27 Namen die man irgendwo her hat, ein 10stelliges Passwort testet, oder für einen Namen, ein 11stelliges testet - und das auch nur wenn man allein von Kleinbuchstaben ausgeht.
Entsprechend ist die Wahrscheinlichkeit höher dass unter den 27 usern, einer mit Passwortlänge <= 10 ist.
(Ich gehe hier mal vom Versuch, Onlineaccounts zu knacken, aus... Wenn man eine verschlüsselte Festplatte von jemandem vor sich hat, ist es vieleicht was anderes.. aber ehrlich.. sowas passiert doch so gut wie nie (zumindest nicht bei Privatanwendern)..)

Du hast da mit der Unterwerfung irgendwie was verwechselt. Alleine schon deswegen, weil dir bei der Formulierung die "keiner"-Abermilionen der Apple-Nutzer nicht eingefallen sind.

Sich der Software zu "unterwerfen", ist was anderes als einem Produkt.
Davon abgesehen.. in Sachen Usability, um das es hier eigentlich ging, sind die Apple Geräte definitiv ganz gut dabei.
Ich meinte eher, dass man schlicht die nächste Software ausprobiert, wenn man mit der einen nicht klarkommt. Es gibt heute einfach sehr viel auswahl.
Wenn die eigene Software Stolpersteine hat, braucht man sich über Kritik nicht zu wundern.

PGP hat mit dem Handling weder was am Hut noch überhaupt was damit zu tun. Mit GnuPG zeigt Enigmail auf Thunderbird wie es geht. Einfachste Bedienung. Das kriegt übrigens GPGTools für OSX's Mail ebenso brauchbar.

Wenn das mit Outlook ungleich aufwendiger funktioniert, gehört das nicht zum PGP-Kümmerkasten. Entweder hat Outlook miese Plugin-Features oder die Plugins sind mies.

IT-Security kram war nie mein Ding (obwohl ich das Fach überraschend gut abgeschlossen hab ), aber soweit ich mich erinnere, ist PGP ursprünglich ein bestimmtes Programm gewesen (EDIT: Wiki sagt das auch). Dahinter stecken die selben grundlegenden Verfahren die ja auch z.B. in SSL Verbindungen stecken.
Das was du als Adons, etc. aufzählst sind eigentlich Kopien davon die nur das grundlegende Prinzip des "Web of Trust" aufgreifen und anwenden. Die gibt es aber auch erst seit vieleicht 10-15 Jahren, davor konnte man am ehesten die separate Software verwenden.

Vielleicht erstmal einfach warten mit der Beteiliegung hier, bis das zweite Semester anfängt. Dann stellen sich auch nicht solche Thesen auf, im O-Ton, daß entweder der DSL-Provider mies ist oder die Routerfirmware, wenn eigentlich die Netzwerkstrippe einen Kabelbruch hat...

Bin grade im vierten Semester - wobei ich "zugeben" muss, dass ich Medien-Informatik studier - kann sein dass wir darum eine etwas User-Orientiertere Sicht auf die Dinge beigebracht bekommen, als z.B. ein theoretischer Informatiker.

 

[awehring]

Dann denk dir eine PassPHRASE aus. Das nannte sich bei PGP schon immer so. Mit Recht.

Da ich in der Tat nicht gleich der Obercracker bin, wollte ich eigentlich schon immer mal fragen wie ein Wörterbuchangriff auf Fusswohl4Frodo_Hobbit funktioniert. Weiß das hier jemand?

Stickworte: Markov-Modell, Markov-Ketten

Arvind Narayanan, Vitaly Shmatikov, Fast Dictionary Attacks on Passwords Using Time-Space Tradeoff, http://www.cs.utexas.edu/~shmat/shmat_ccs05pwd.pdf


Oder in einer sehr lesenswerten und leicht verständlichen deutschen Darstellung (im letzten Drittel des Artikels):
Die Tools und Techniken der Passwortknacker - c't-Archiv, 3/2013, Seite 84

Resumee:

Ein wirklich zufälliges Passwort aus zehn oder mehr Zeichen wird natürlich keiner der hier vorgestellten Angriffe knacken. Doch so gut wie alles, was wir Menschen uns noch irgendwie merken können, fällt den Crackern offenbar früher oder später zum Opfer.

[...]

Bei den unter diesem Artikel abgedruckten, real geknackten Passwörtern finden sich viele, eigentlich richtig gute, deren Länge und Komplexität alle gängigen Anforderungen an Passwortsicherheit erfüllen. Bei[m] LinkedIn [Hack] verwendeten ganze 14'000 Anwender sogar Passwörter mit 16 oder mehr Zeichen. Und trotzdem wurden sie geknackt!

 

[DragonTear]

Oder in einer sehr lesenswerten und leicht verständlichen deutschen Darstellung (im letzten Drittel des Artikels):
Die Tools und Techniken der Passwortknacker - c't-Archiv, 3/2013, Seite 84

Huh, ist ja ernster als gedacht!
Da fragt man sich, wie man sonst Passworter wählen sollte.. :/
Eventuell vollständig zufällige, und dann einfach eine Passwortsafe-Software verwenden. Das birgt aber auch wieder ein par Sicherheitslücken, besonders wenn der Rechner selbst angreifbar ist...

 

[awehring]

Ein Passwort alleine reicht nicht. Ernsthafte Sicherheit erreicht man nur mit Zwei-Faktor-Authorsierung.

Narayanan et al. schlagen eine Kombination aus Passwort und Biometrischen Informationen vor.

 

[DragonTear]

Ein Passwort alleine reicht nicht. Ernsthafte Sicherheit erreicht man nur mit Zwei-Faktor-Authorsierung.

Narayanan et al. schlagen eine Kombination aus Passwort und Biometrischen Informationen vor.

Naja.. bei Bankautomaten, etc. sicher (in einigen Ländern sind z.B. Venenscanner bereits im Einsatz/Testphase), aber wie soll man das im Web realisieren (um Z.B. LinkedIn zu schützen)?
Selbst wenn man zuhause nen Scanner hat, wird auch nur wieder ein Datenpaket übermittelt das genauso gut gefälscht werden könnte.

 

[awehring]

PS, im Original:

Defending against offline and online dictionary attacks on human-memorable passwords is a difficult task. Possible techniques include graphical passwords [18, 36, 8], reverse Turing tests [31, 35], and hardening passwords with bio-metric information [26]. These techniques, however, require substantial changes in the authentication infrastructure.

 

[BessereHälfte]

Ist doch eine gute Sache bei VeraCrypt. 2-Faktor über Password und PIN

Und Leute, gehts auch sachlich?

DragonTear, ich hab PGP schon in den 90ern genutzt. Auf Amiga mit MicroDot. Das war GENAUSO problemlos und bequem wie es heute mit Thunderbird und Enigmail ist. Das lag nicht an PGP 2.6.x, sondern am MicroDot.
Lass das mit PGP als Beispiel einfach ruhen

awehring, weil man resources auf den Servern sparen wollte waren die Passwörter bei Linkedin schlicht einfach nur mit Sha1 ohne Salt (!1!!) gehasht. Also keine Art von key derrivation irgendeiner Art, die sich so nennen gedürft hätte. Das war schon 2012 ein schlechter Scherz.
Ich verneine damit nicht gleich die Existenz von besseren Gegenbeispielen. Der Linkedin-Hack ist jedenfalls kein brauchbares Beispiel für die Schwachstelle "Passwort" (auf der Client-Seite).

Markov wie auch RainbowTables gelten aber. Daher: GnuPG macht ordentliche (PB)KDF, per default mit sha-1 und 65536 iterations. Kein bcrypt, kein scrypt.
Wo ist denn der Prof samt seinen Doktoranten der mit seiner Abstelkammer voller Tesla-Karten zeigt wie einfach man an den seckey rankommt, wenn die Passphrase im Wörterbuch steht?
Oder bei TrueCrypt? Oder bei KeePass (wenn man mit den Einstellungen nicht dumm rumspielt)?

Doch so gut wie alles, was wir Menschen uns noch irgendwie merken können, fällt den Crackern offenbar früher oder später zum Opfer.

Dem kann man auch schlecht widersprechen. Fehlt halt nur ein Zeichen-Beispiel und die Einschätzung dazu, ob es damit 1, 100, 1000 oder 1Mio. Jahre dauern würde...

 

[TCM]

Wenn ihr sichere pass phrases wollt:

Diceware Passphrase Home

Das Wörterbuch ist gerade mal 7777 Wörter groß. Ich benutze daraus einen "Satz" aus 7 zufälligen Wörtern, ohne Großschreibung, ohne Zahlen, ohne Sonderzeichen. Einfach 7 Wörter klein aneinandergeschrieben. Der resultierende Satz hat eine größere Entropie als ein völlig zufälliges(!) 15-Zeichen-Passwort aus Groß-/Kleinbuchstaben und Ziffern und ist viel leichter zu merken.

PS: Ich sehs schon: "Waaas? Direkt aus dem Wörterbuch? Ohne Sonderzeichen, nicht mal Großbuchstaben?! Das crackt doch jeder C64 in 5 Minuten!" Nein, rechnet es durch.

 

[awehring]

Lies Dir mal die oben verlinkten Artikel durch.

Dann wirst Du Zweifel bekommen, ob Passphrasen aus einem Wörterbuch eine gute Idee sind.

 

[coolnik]

IT-Security kram war nie mein Ding (obwohl ich das Fach überraschend gut abgeschlossen hab ), aber soweit ich mich erinnere, ist PGP ursprünglich ein bestimmtes Programm gewesen (EDIT: Wiki sagt das auch).

Meins auch nicht, ich hab in der Zwischenprüfung alles genau anders rum gemacht. Das war kein RSA mehr sonder ASR
Aber bzgl. PGP setzt man doch eigentlich auf ein unsicheres System, wenn man die Entwicklung in den nächsten 10-15 Jahren betrachtet.
Denn sobald es Quantencomputer gibt, was auch nicht mehr lange dauern sollte, dann ist die Faktorisierung kein Problem mehr und alle Systeme die auf dem Public-Key-Verfahren basieren sind lösbar.

Wenn ihr sichere pass phrases wollt:

Diceware Passphrase Home

Das Wörterbuch ist gerade mal 7777 Wörter groß. Ich benutze daraus einen "Satz" aus 7 zufälligen Wörtern, ohne Großschreibung, ohne Zahlen, ohne Sonderzeichen. Einfach 7 Wörter klein aneinandergeschrieben. Der resultierende Satz hat eine größere Entropie als ein völlig zufälliges(!) 15-Zeichen-Passwort aus Groß-/Kleinbuchstaben und Ziffern und ist viel leichter zu merken.

PS: Ich sehs schon: "Waaas? Direkt aus dem Wörterbuch? Ohne Sonderzeichen, nicht mal Großbuchstaben?! Das crackt doch jeder C64 in 5 Minuten!" Nein, rechnet es durch.

Geht einfacher und sicherer, so lange keiner 2 deiner Passwörter geknackt hat:

Einmal ein 8-12 Zeichen langes Passwort bestehend aus Groß- und Kleinbuchstaben, Ziffern sowie Sonderzeichen merken und einfach Abkürzungen für die Dienste mit einem Sonderzeichen oder in Leetspeak dranhängen.
Ist relativ wenig zu merken und so lange niemand zwei deiner Passwörter geknackt hat, bilde ich mir ein, dass es auch relativ sicher ist. Immerhin besser als ein einziges Passwort für alles zu nutzen

 

[BessereHälfte]

Schön geworden hier

@coolnik
Nicht wirklich. Falls man das je so hinbekommt (Quantenrechner) verliert z.B. RSA die Hälfte an Stärke. D.h. ein 4096 Schlüssel ist dann nur so stark wie ein 2048 Schlüssel für konventionelle Technik. Und PGP geht bis 16384.
Falls wir also 2025 alle auf mind. 8192 RSA-Schlüssel gehen sollten, dann wird das für die Heim-IT weniger belastbar sein als heute 4096 Schlüssel Und auch wenn elyptische Kurven auf 1024bit gehievt werden müßen, auch das wird den Kohl nicht fetter machen.

Key-Crypto fällt mit Quantencopmputern ist Gallileo-Niveau.

 

[coolnik]

Okay, das erscheint logisch, auch wenn die Lösung etwas zu einfach scheint. Aber das wäre auch nicht das erste Mal, dass die Schlüssellänge einfach höher gesetzt wird.

 

[TCM]

Ich verstehe genau, worum es in dem Artikel geht, nämlich dass Menschen sich einzelne oder mehrere Wörter hernehmen und durch Umformungen in etwas für sie augenscheinlich "Zufälliges" verwandeln, was aber keineswegs zufällig ist, wenn man den Umformungsprozess nachvollziehen und in eine Maschin klöppeln kann, die dann alles durchprobiert.

Wenn man das gerade so versteht, könnte man auf die Idee kommen, Wörterbücher und alles daraus wären das Unsicherste, was es gibt und Passwörter müssen immer komplett zufällig sein.

Nun, was macht denn ein "echtes zufälliges" Passwort so gut? Grob gesagt besteht ein Passwort aus einer bestimmten Anzahl von Elementen eines Alphabets. Nehmen wir an, das Alphabet ist a-z, A-Z, 0-9. Das sind 62 mögliche Zeichen. Wenn man daraus jetzt "echt zufällig" z.B. 15 Zeichen wählt (z.B. mit einem Würfel), dann hat das Passwort eine Stärke von log(62^15)/log(2) = 89 Bits, d.h. da es keinerlei sinnvolle Regeln gibt, die ein Zeichen vom nächsten abhängig machen, wie es bei einem Wort aus dem Wörterbuch der Fall ist, muss man alle 62^15 Möglichkeiten durchprobieren und findet im Schnitt nach der Hälfte das Passwort.

Soweit die Theorie zum zufälligen Passwort.

Was ist bei Diceware jetzt anders? Nun, das Passwort wird zur Passphrase. Das Alphabet sind nicht mehr die einzelnen Buchstaben sondern die kompletten Wörter. Das Alphabet ist also nicht mehr 62 Elemente groß, sondern hat 7777 Elemente. Da man aus diesen Elementen keinen sinnvollen Satz raussucht, sondern immer noch mit echtem Zufall arbeitet, hat man mit 7 Wörtern am Ende eine Stärke der resultierenden Passphrase von 7777 ^ 7, was in etwa so stark ist wie das 15-stellige Passwort von oben.

Nehmen wir an, die 7 ausgesuchten Wörter ergeben eine Zeichenkette, die aus 30 Kleinbuchstaben besteht. Welche Stärke hat die Passphrase jetzt genau? Geht man einer zufälligen Verteilung aus und würde keine Wörter erkennen, dann wäre das log(26^30)/log(2) = 141 Bits. Da man aber weiß, dass die Phrase aus einem Wörterbuch stammt und man sogar das Wörterbuch kennt, reduziert sich die Stärke auf log(7777^7)/log(2) = 90 Bits.

Das wars dann aber auch! Weiter vereinfachen kann man nicht mehr, da die Wörter (die Elemente des Alphabets) "echt zufällig" gewählt wurden, genau wie die Buchstaben beim echt zufälligen Passwort.

Auch wenn Diceware mit einem Wörterbuch arbeitet, man nicht mal Großbuchstaben oder Sonderzeichen verwendet, ist es so sicher wie ein echt zufälliges 15-stelliges Passwort, was sich nie einer merken könnte. 7 Wörter kann sich jeder merken.

Wörter aus dem Wörterbuch sind nicht dadurch schlecht, dass sie aus dem Wörterbuch sind. Sie sind schlecht, wenn sie schlecht gewählt sind.

Geht einfacher und sicherer, so lange keiner 2 deiner Passwörter geknackt hat:

Einmal ein 8-12 Zeichen langes Passwort bestehend aus Groß- und Kleinbuchstaben, Ziffern sowie Sonderzeichen merken und einfach Abkürzungen für die Dienste mit einem Sonderzeichen oder in Leetspeak dranhängen.
Ist relativ wenig zu merken und so lange niemand zwei deiner Passwörter geknackt hat, bilde ich mir ein, dass es auch relativ sicher ist. Immerhin besser als ein einziges Passwort für alles zu nutzen

Merk dir mal 8-12 echt zufällige Zeichen oder 7 zufällige Wörter. Was ist wohl einfacher? 7 Wörter geht grade noch so, bei 12 Zeichen und mehr braucht man schon irgendeine Eselsbrücke. Das ist nämlich genau der Knackpunkt, um den es hier geht, dass Menschen meinen, ihre 12 Zeichen wären zufällig, weil sie sie aus irgendeinem Satz oder irgendwas anderem, was für sie Sinn ergibt, abgeleitet haben.

 

[BessereHälfte]

@coolnik
Es werden bestimmt auch andere Ansätze noch gesucht und gefunden. Wie immer. Es gibt ja noch die ganzen (bis dahin wohl auch entsprechend mehr) Micro-Smartdevices für die man immer kürzeste Zeiten und minimalen Stromverbrauch sucht. So ein Schwachsinnsgrund eben wegen welchem man Rijndael statt Serpent (oder statt Twofish) gewählt hat

Daß aber in der Nacht in der ein Quantenrechner das erste Mal etwas faktorisieren kann, Key-Crypto fallen wird, das stimmt halt nicht

 

[awehring]

@TCM
Ok, habe Diceware verstanden. Ist ein interessanter Ansatz. Danke für die ausführliche Erläuterung.

Man muss aber die Wörter wirklich auswürfeln. Falls jemand auf die Idee kommt sich einfach schöne Wörter rauszusuchen (welche, die zusammen einen Sinn ergeben und den er sich leicht merken kann) ist das Konzept natürlich torpediert.