Diskussion:PBKDF2

Scrpyt-ASICs (Erweiterung von Kritik und Alternativen)

Es ist richtig (und m.E. erwähnenswert), dass inzwischen ASICs auf dem Markt sind für das Mining von Litecoin. Litecoin benutzt zwar Scrypt, aber mit wesentlich weniger Speicheranforderung (1MiB oder 4MiB statt dem Standard 16MiB? - ich weiß es gerade nicht). Das bedeutet meines Wissens, dass die neuen ASICs zum Litecoin-Mining nicht für das Brechen normaler Scrpyt-Anendungen benutzt werden können. Falls jemand andere Infos hat, beispielsweise dass es Litecoin-ASICs gibt, die auch 16MiB verarbeiten können (würde mich sehr wundern), gilt der Einwand natürlich nicht. Ich schlage ansonsten vor, darauf hinzuweisen, dass die betreffenden ASICs nur für eine Speicher-reduzierte Form von Scrypt beutzt werden können. --Beloumi (Diskussion) 11:54, 9. Jul. 2014 (CEST)

ja, wenn das so ist, dann sollte das auch in den artikel. im moment geht es daraus nicht hervor. --Mario d 15:34, 11. Jul. 2014 (CEST)

Anwendungen von PBKDF2 - Warum Mediawiki?

Warum taucht MediaWiki in einer Reihe von Crypto-Anwendungen auf? Wird PBKDF2 dort für mehr als das Passwort-Hashing in der Benutzerdatenbank genutzt? Wenn nicht, würde ich vorschlagen es aus dieser Liste zu entfernen (ansonsten könnte diese Liste noch viele weitere Anwendungen führen bei denen PBKDF2 eine ähnlich unwesentliche Rolle spielt). (nicht signierter Beitrag von 46.183.103.8 (Diskussion) 09:59, 21. Mär. 2017 (CET))

Naja, die Anwendungen, die PBKDF2 fürs Passwordhashing verwenden kann man an einer Hand abzählen. Ist jetzt nicht so als erfreute sich der Algorithmus irgendeiner Beliebtheit, zumal er gar nicht für das Passwordhashing entwickelt wurde. Daher ist es schon erwähnenswert zu sagen, dass er vielfältige Anwendungszwecke hat.--Widder8 (Diskussion) 17:30, 31. Jul. 2017 (CEST)

PBKDF2 schreibt doch keine "schnellen" Hash-Funktionen (wie SHA) vor!

Es wird im RFC nur als Beispiel genannt, aber noch nichtmal als "Empfehlung". Es spricht also nichts dagegen, das PBKDF2-Verfahren mit Hash-Funktionen zu implementieren, die "absichtlich langsam", "speicherhungrig" oder "GPU-unfreundlich" sind, so dass das Verfahren eben nicht mehr mit Grafikkarten und ASICs beschleunigt werden kann. --RokerHRO (Diskussion) 22:19, 27. Mai 2017 (CEST)

Es werden vom NIST (RFC ist 10 Jahre älter) erprobte Hashfunktionen empfohlen, d.h. alle Finalisten aus dem SHA3-Verfahren und SHA256 - SHA512. Das sind alles "schnelle" Hashfunktionen. Speicher-intensive Funktionen sind unter anderem darauf ausgelegt, in vertretbarer Zeit einen möglichst großen Vektor zu erzeugen. Das widerspricht dem Prinzip der Iteration. Du könntest im Prinzip Scrypt als Hashfunktion für PBKDF2 verwenden, aber dann könnte entweder Scrypt nicht mehr Speicher-intensiv sein oder User müssten Wartezeiten von mehreren Minuten in Kauf nehmen. Das gilt auch für andere neue Passwort-Hashingverfahren (Argon2, Catena, Lyra2, Yescrypt, Pomelo, Balloon). Es gibt bestimmte Operationen, die Grafikkarten nicht viel schneller ausführen können als CPUs - auch ohne großen Vektor. Bcrypt profitiert davon. Aber für ASICs und FPGAs gilt das nicht: für die stellt Bcrypt kein Hindernis dar. Zur Zeit des RFC (2000) war PBKDF2 eine gute Empfehlung, da waren custom hardware attacks noch nicht verbreitet und es ging nur um eine kontrollierbare Verlangsamung. Das Verfahren war ausschließlich darauf ausgelegt. --Beloumi (Diskussion) 20:12, 28. Mai 2017 (CEST)

Hm, okay. Ich hatte scrypt, bcrypt und Co. "nur" als künstlich langsam / speicherhungrig gemachte Hashfunktion verstanden, die man als Ersatz für SHA-x in einer Passwort-zu-Schlüssel-Ableitungsfunktion wie PBKDF2 verwenden kann, um eben nicht nur den Rechenaufwand, sondern auch den Speicherverbrauch hochzutreiben.

Aber anscheinend ist scrypt selbst bereits ein Ersatz für den PBKDF2-Algorithmus, wobei es allerdings fix mit Salsa20 als rechenintensive Funktion gekoppelt ist, also nicht (im Prinzip) variabel wie bei PBKDF2.

Gibt es denn irgendwelche zitierfähigen Quellen, die sagen: "Leute, vergesst, PBKDF2, nehmt scrypt / Argon2 / whatever, weil …"? --RokerHRO (Diskussion) 21:45, 29. Mai 2017 (CEST)

Zitierfähige Quellen stehen noch aus, es wird eher immer mal am Rande erwähnt. Es ist auch nicht so, dass alle PBKDF2 für überholt halten, auch wenn sich die Ansicht zunehmend durchsetzt. Passwort Hashing ist ein relativ neuer Forschungsbereich und es gibt noch keine wirklich überzeugende Lösung. Argon2, Scrypt oder Catena haben ihre Schwächen, wenn auch wesentlich geringere als PBKDF2.

Schwächen von Argon2 & Co?

Hm, darf man da erfahren, welche das sind? (Okay, sollten wir vielleicht auf der DS des jeweiligen Verfahrens diskutieren, nicht hier ;-)) --RokerHRO (Diskussion) 16:22, 31. Mai 2017 (CEST)