| |
| 2.3, Аноним (3), 17:29, 01/07/2019 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Применение указанной обвязки может потребоваться в областях, в которых требуется соответствие Российским криптографическим стандартам (например, в ALT Linux). | | |
| 2.5, solardiz (ok), 17:39, 01/07/2019 [^] [^^] [^^^] [ответить]
| +8 +/– |
 Пароли пользователей на серверах обычно не хранятся, а вместо них хранятся результаты вычисления хеш-функции от паролей. Так безопаснее. Есть ряд желаемых свойств таких хеш-функций. yescrypt обладает многими из желаемых свойств.
yescrypt также обладает рядом желаемых свойств для применения при формировании ключа шифрования данных на основе пароля (например, для шифрованной файловой системы).
Изменения в этой версии yescrypt существенны с точки зрения реализации, будущего развития проекта и интеграции в другие проекты, но несущественны непосредственно для пользователей yescrypt прямо сейчас. Сам факт выпуска очередной версии показывает, что проект поддерживается.
Поначалу мы предлагали yescrypt для крупных внедрений (Интернет-компании с миллионами пользователей). Сейчас, с интеграцией в libxcrypt, это постепенно меняется - базовая функциональность yescrypt становится легко доступна и для применения на отдельных серверах.
| | |
| 2.6, Анонтоним (?), 18:13, 01/07/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Это такая медленная реализация хеша пароля, что если у тебя их сольют (например, из файла /etc/shadow с хешами паролей), то делать перебор паролей, даже по словарю будет настолько медленно, что можно надеяться, что этим никто не будет заниматься в здравом уме.
| | |
|
| |
| 2.10, не solardiz (?), 23:30, 01/07/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
> 2. зачем продвигать криптоалгоритмы, разработчиков которых поймали на недостоверной информации
> https://who.paris.inria.fr/Leo.Perrin/pi.html
Затем, что их всё равно анально внедрят, ибо партия велела. А так хоть какая-то надежда на надёжность будет.
> 3. чем yescrypt лучше argon2?
В новости есть ссылка, по которой это расписано.
> 4. когда новый выпуск LKML?
Если ты про https://lkml.org/, то по пачке тредов в день открывается, но причём тут solardiz?
| | |
| 2.11, gcc (??), 11:20, 02/07/2019 [^] [^^] [^^^] [ответить]
| +/– |
> зачем продвигать криптоалгоритмы,
> разработчиков которых поймали на
> недостоверной информации
Иногда лучше выглядеть дураком, чем сболтнуть лишнего и отсидеть пяток лет. Проще было сказать, что таблица рандомная, чем расписывать как и почему (показывая какие методы
анализа известны), imho.
| | |
| |
| 3.12, Tifereth (?), 12:37, 02/07/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Последствия этого "лучше" довольны просты - знающие люди однозначно советуют избегать использования Стрибога/Кузнечика, вследствие возможного существования "чёрного хода".
Замечательный итог. "Налить всем по чарке!"
| | |
| |
| 4.13, Анонтоним (?), 13:52, 02/07/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ага, "знающие люди однозначно советуют избегать использования" чего либо российского...
Знаем, проходили. Пол русского инета забита прoсрaлиполимерщиками.
| | |
| 4.15, Анонтоним (?), 15:08, 02/07/2019 [^] [^^] [^^^] [ответить]
| +/– |
20-ть лет назад некто Vincent Rijmen в своей работе http://luca-giuzzi.unibs.it/corsi/Support/papers-cryptography/rijndael-sbox.p написал: "Every element of GF(256) can be written as a polynomial of the first degree with coefficients from GF(16)", и вот теперь нашлись эксперты которые тоже самое проделали для гостовской таблицы замен, с криками "тайная структура!", "закладки КГБ!", "русские снова всем лгут!.."
Удивляет, как они ещё не добрались до белорусских, казахских и украинских S-боксов?..
| | |
| |
| 5.16, solardiz (ok), 17:18, 02/07/2019 [^] [^^] [^^^] [ответить]
| +/– | |
Не моя тема, но:
Vincent Rijmen - один из двух авторов AES. Процитированное утверждение универсально, но эффективность применения преобразований для S-блоков конкретно AES не вызывала удивления так как структура S-блоков AES была документирована с самого начала.
Суть претензий в том что для ГОСТ'овых S-блоков утверждалось, что они случайны, а значит крайне маловероятно что их удалось бы преобразовать во что-то, запись чего в каком-либо ранее общепринятом виде окажется в разы меньше их размера как таблиц. Упомянутые эксперты же нашли существенно более краткую математическую запись, а сообщество помогло добавить наглядности уместив исходно 256-байтную таблицу (или ~210 байт если вспомнить, что условия задачи требовали чтобы такая таблица была перестановкой) в, например, 72 байта машинного кода под 32-битный x86: https://codegolf.stackexchange.com/questions/186498/proving-that-a-russian-cry
Про "тайная структура" и "лгут" пишут и обосновывают. Про "закладки" пишут что подтверждения этому нет, но риск подразумевается. Аспекта что именно "русские" по-моему там нет, это нормально что любой криптографический алгоритм вызывает подозрения, а если речь о национальном стандарте, то подозрения в закладках от спецслужб соответствующей страны. Особенно когда что-то скрыли. То же самое было в отношении DES, причем во многом со стороны американцев же (а потом оказалось, что секретная структура S-блоков повышала безопасность). И сейчас возможные проблемы безопасности ГОСТ'ов затрагивают в первую очередь их использование в России же (так как использовать их где-либо еще всё равно почти не будут - просто не нужно) и опасения со стороны "русских" же.
"До белорусских" добрались тоже. А казахские и украинские есть? Я не в курсе.
| | |
|
|
|
| 2.14, solardiz (ok), 14:06, 02/07/2019 [^] [^^] [^^^] [ответить]
| +/– |
Сначала по теме:
2. Мы ГОСТ не продвигаем. В самом yescrypt его поддержки нет. Она есть в libxcrypt, что используется в некоторых установках ALT Linux. В моем анонсе этого выпуска yescrypt и заодно интеграции в libxcrypt явно написано, что gost-yescrypt следует использовать только там где требуется соответствие российским стандартам: "gost-yescrypt should only be used where compliance with Russian cryptographic standards is required". В файле NEWS из libxcrypt 4.3.1+ также описано изменение, сделанное с моей подачи, снижающее риск необдуманного использования gost-yescrypt: "Reduce the number of methods that can be the default for new hashes. We don’t want to accidentally encourage use of gost-yescrypt, [...] by people who do not have a specific need for them." Основная причина не продвигать gost-yescrypt не в недостоверной информации об S-box'ах (что почти наверняка не делает хеши уязвимыми при данном применении), а просто в том что это лишний тип хешей (сложности переносимости) и лишняя обертка (ее дизайн и реализация, а значит и риск ошибок).
3. Основное преимущество yescrypt в большей стойкости к перебору (бОльшие затраты атакующего при тех же затратах защищающего). Есть и другие преимущества, а также есть недостатки и отличия. Подробное сравнение с Argon2 (и с scrypt) есть в файле COMPARISON в архивах с yescrypt 1.0.1+, а также на странице проекта: https://www.openwall.com/yescrypt/#argon2
Не по теме:
1. diz остался со времен BBS и файлов file_id.diz.
4. Наверное, LKRG? Возможно, что в этом месяце, но не обещаем. Свежайший код есть в репозитории BitBucket по ссылке со страницы проекта: https://www.openwall.com/lkrg/
| | |
|
|
