Кстати, у кого был пейпер про доказательство оптимальности scrypt в плане нагрузки на память относительно цпу?

эта? https://eprint.kobi.one/2016/989

да, вроде

прокомментируешь для тупых?

(мож, во время семинара)

я ее если и читал то давно. Абстракт говорит, что если считать стоимость вычисления как интеграл от памяти по времени t, то у scrypt есть нижняя оценка как O(t^2)

Нету такого пейпера и не будет. Scrypt крайне не эффективный, искуственно усложненный и сильно растянутый алгоритм. Поэтому в классе алгоритмов он будет - малоэффективным, малопроизводительным в любом железе и математически спорным в плане финального распределения. Исключительно сложным в плане реверса, но это не означает что он лучший в классе.

Я посмотрел всех авторов документа и их работы. Они все топят за proof of space, proof of memory... и помоему просто зациклены на сложностях. Помоему они немного на фолс лиде изначально. Вместо сравнения они строят сложности

Ну это ж теоретическая работа

;-) чем теории сферических коней в ваккуме от практики отличаются надеюсь все в курсе.

я думаю эта статья она исключительно про паттерн доступа к памяти, от спецификации scrypt там дай бог 10 процентов использовано

Когда мы выбираем шифрование, мы почему-то анализируем и заботимся о ключевых параметрах типа: криптостойкость, быстрота, простота реализации и пропускная способность. Типа rsa vs ed25519

Но с хешами, реально на зло врагам отморозим уши... Главное чтобы сложнее и больше ресурсов, а не чтобы доказанное распределение, скорость, простота реализации, лучше распределение и менее реверсивный...
https://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions
https://cryptobook.nakov.com/cryptographic-hash-functions/secure-hash-algorithms
Разные алгоритмы по разному работают на разных процессорах, это тоже нужно учитывать,  ноды должны иметь возможность быстро верифицировать результат а не иметь танцы с бубнами..
П.с. недавно смотрел концепт iot ребята все сделали, но забыли что пишут код для stm32/arduino где их hash-алгоритмы не интегрированны в проц и приходиться занимать 40% памяти чисто под код вместо вызова встроенных в проц функций

ну нет, когда делаем обычный хэш для скажем хэширования огромных файлов, там скорость и простота конечно вперед выходят. Тот же Blake2 .

А вот когда хочется безопасно использовать пароли из 7 цифр, тогда уже другой

У Blake2 низкая/плохая пропускная способность. Я делал анализ и сравнивал их. Сожалею это тоже классическая ошибка.

смотря на какой архитектуре. На x86 хорошая пропускная способность

собственно люди уже давно заморочились и сравнили на неплохом количестве машин https://bench.cr.yp.to/results-hash.html

Это другое в этом классе PBKDF2 лидер. Комплесный убийца производительности. Но я предпочитаю пользовать другой, ибо боюсь как только PBKDF2 наберет массу став решением дефакто, его таки имплементируют в железе какое нить 3х буквенное агенство, а это риск.

нет не лидер. Argon2 гораздо безопаснее PBKDF2

Это другое они тестируют на разных cpu/soc платформах, а не комплексность в чистом виде - это другое.