Телеграмм чат группы rust_offtopic страница 9414

bcrypt не оч

12:02пожаловаться #1

но на сервере возникает фактор ДоСа - чем дороже КДФ, тем больше ты себя подставляешь

12:03пожаловаться #2

Oleg Andreev

1. зачем использовать хеши с коллизиями если есть хеши без коллизий (sha256 > sha1)
2. ты пароли хешируешь чтоб если ДБ сольют, не было дешево подобрать пароль. Поэтому нужно солить, а также использовать медленный KDF

1. понятно что ша256
2. понятно что надо солить

12:03пожаловаться #3

а, ты про ша1

12:03пожаловаться #4

я думал про любые ша

12:03пожаловаться #5

ну ша256 и ша3 норм

12:03пожаловаться #6

вернее, лучше shake128 а не sha3

12:04пожаловаться #7

хз, кессак меня вполне устраивает

12:04пожаловаться #8

sha3 - это фейспалм, при том что сам keccak - охуенчик

12:04пожаловаться #9

ша3 это алиас на кессак256 если ты не знал

12:04пожаловаться #10

не совсем

12:04пожаловаться #11

это keccak256 и толще раунды чем нужно

12:04пожаловаться #12

shake256 тоже перебздел. shake128 - самое оно

12:05пожаловаться #13

No they did not, the internals and security levels have not been changed from the draft Keccak submission, only the padding rule has changed.
The padding change is the only difference, this allows future tree hashing modes as well as the current SHAKE outputs to generate different digests given the same security parameters and message inputs. Up to 4 additional bits are added, which keeps the full padding inside a byte boundary, making implementations with octet only input able to switch to SHA-3 from Keccak with change to only a single line of code.
The padding change has no negative impact on the security of SHA-3.

12:05пожаловаться #14

а, блин

12:05пожаловаться #15