ついにスクリプトが壊れましたか？
私が正しく理解していれば、これに従って http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html は、攻撃者が単に非常に高い効率で同じ出力を生成するscryptの最適化バージョン（たとえば、N = 2 ^ 14、p = 8、r = 1の場合、実行に16MBではなく1KBしか必要とせず、CPU作業係数をN/2だけ増やす） 。
短い答えは：noです。それは私が言ったことでも、私が暗示することでもありません。
私が特定して話し合ったトレードオフを使用して、メモリをCPU時間と交換できます。つまり、特定の派生を16MiBから8KiBに（おおよそ）減らすことができます。ただし、これを行うと、CPUで実行するロジックが数桁増えることになります。キャッシュの局所性によってある程度の効率が得られますが、一般的にはかなり遅くなります。 （平均すると、16MiBバージョンよりも約8,000倍遅くなりますが、アルゴリズムの正確なランダム分布によっては16,000倍遅くなります）。
しかし、もっと興味深い代替案があります。私の攻撃はオール・オア・ナッシングのベイズでした。基本的に、Vアレイを完全に排除しますが、複雑さが増します。ただし、より微妙なトレードオフを行うことができます。配列を半分に切り、他のすべての値を再計算できます。または、3つおきの値にカットします。ストレージ領域とCPU領域のトレードオフ。しかし、さまざまな程度で。これは一般にTMTOデフィーター（Time-Memory-TradeOff Defeater）と呼ばれます。
私は このスレッドの修正案を含む、より徹底的な分析 を行いました。 Password Hashing Competition の提案の少なくとも1つは、私の拡張アルゴリズムを使用していることに注意してください。
したがって、いいえ、scryptは依然として非常に強力です。 （KDFとしての）その主な使用例については、他の方法よりもかなり優れています。
私が投稿で作成しようとしていた点は、最適に調整されていない場合（不適切な設定で使用）または非常に高速な設定では、既存のアルゴリズムよりも大幅に弱くなる可能性があるということです。特にpassword storageの場合。あなたが結果を知っていて、出典資料（パスワード）を探しているところ。
scryptはタイミング攻撃に対して脆弱です：問題＃18・pbhogan/scrypt これは、パスワードをハッシュしているホストへのアクセス権を持つ攻撃者が、パスワードを特定するための追加の方法をいくつか持っていることを意味しますでる。したがって、壊れていませんが、たとえば、 bcrypt。