я имел ввиду техническую документацию конкретного продукта. Формализация требований к продукту (от каких угроз защищаемся, что подразумеваем), описание архитектуры системы и её компонентов, cryptography engineering. Ну и исходники reference реализации.
Не знаю как сейчас, но в прошлом проблема с созданием криптографических стандартов — это проблема доверия: если некто предлагает конкретную версию алгоритма для стандартизации, все прочие считают, что он уже знает, как её взломать. И не без оснований, как показывает история с Dual_EC_DRBG.
А с исходным кодом и внушительным инженерным процессом — у семи нянек дитя без глазу, или “Only two remote holes in the default install, in a heck of a long time!”
Стандарты проходят похожий путь. Желающие предлагают и публикуют свои работы другие желающие их оценивают, кто-то формализует proposed стандарт, это все б/м открыто обсуждается (я - за полный доступ к таким обсуждениям). В результате заметно повышается (конечно не до 1) вероятность отсутствия backdoors в алгоритмах.
И работа по поиску недостатков в уже существующих алгоритмах не прекращается и после стандартизации. Только больше людей участвуют. Ибо уже стандарт и используется все больше.
Так что "всё прочие" только тем и заняты, что ищут уязвимости. И иногда находят.
В криптографии проблема что алгоритм может быть специально сделан так что имеет секретную отмычку но наличие или отсутствие этой отмычки невозможно доказать просто глядя на алгоритм или его реализацию. Плюс, отмычка может быть спроектирована только для использования на нетривиальных вычислительных ресурсах, доступных только серьёзным дядям (а что будет через десяток лет — ну мы знаем притчу).
Я не спорю что открытый код несколько лучше чем закрытый, но это не значит, что открытый код безопасен, или закрытому никогда нельзя верить.
Когда стандарт волевым решением вводят какие-то бюрократы, это всегда не очень хорошо. И кривые, настандартизованные НИСТом пачками, тоже вызывали вопросы: а почему выбраны такие коэффициенты? Объясните. Не объяснили. А меж тем, существует метод генерации эллиптических краевых на основе случайных чисел. Типа взяли столько-то цифр из числа Пи, записали подряд и на основе этого большого целого числа вывели параметры кривой. Вряд ли math backdoors был заранее встроен в число Пи. )
Подсказка: найдите число с backdoor, найдите место в числе Пи, где такая последовательность имеет место (поскольку ряд цифр Пи бесконечен и апериодичен, такое место точно существует для любой наперед заданной последовательности любой конечной длины). Дальше труднее: объясните всем, что попали на эту последовательность случайно. 😉
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2023-04-04 19:33 (UTC)Исходники? CVE 2016-0777.
Нет, верить никому нельзя.
no subject
Date: 2023-04-04 19:59 (UTC)я имел ввиду техническую документацию конкретного продукта.
Формализация требований к продукту (от каких угроз защищаемся, что подразумеваем), описание архитектуры системы и её компонентов, cryptography engineering. Ну и исходники reference реализации.
no subject
Date: 2023-04-04 20:19 (UTC)А с исходным кодом и внушительным инженерным процессом — у семи нянек дитя без глазу, или “Only two remote holes in the default install, in a heck of a long time!”
no subject
Date: 2023-04-04 20:34 (UTC)Желающие предлагают и публикуют свои работы другие желающие их оценивают, кто-то формализует proposed стандарт, это все б/м открыто обсуждается (я - за полный доступ к таким обсуждениям).
В результате заметно повышается (конечно не до 1) вероятность отсутствия backdoors в алгоритмах.
И работа по поиску недостатков в уже существующих алгоритмах не прекращается и после стандартизации. Только больше людей участвуют. Ибо уже стандарт и используется все больше.
Так что "всё прочие" только тем и заняты, что ищут уязвимости. И иногда находят.
no subject
Date: 2023-04-04 20:41 (UTC)Я не спорю что открытый код несколько лучше чем закрытый, но это не значит, что открытый код безопасен, или закрытому никогда нельзя верить.
no subject
Date: 2023-04-04 20:59 (UTC)И кривые, настандартизованные НИСТом пачками, тоже вызывали вопросы: а почему выбраны такие коэффициенты? Объясните.
Не объяснили.
А меж тем, существует метод генерации эллиптических краевых на основе случайных чисел. Типа взяли столько-то цифр из числа Пи, записали подряд и на основе этого большого целого числа вывели параметры кривой.
Вряд ли math backdoors был заранее встроен в число Пи. )
no subject
Date: 2023-04-04 21:01 (UTC)no subject
Date: 2023-04-04 21:15 (UTC)Дальше труднее: объясните всем, что попали на эту последовательность случайно. 😉