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 20:12, 28. Mai 2017 (CEST)