А вот с GrdUtil вы правы. В последней версии всем алгоритмам кроме GSII64 действительно дается свойство чтения по паролю при создании. Мы эту возможность в следующей версии закроем, т.к. это конечно идеологически некорректно.

Еще раз повторю - опеределитель не требует супермощного криптографического ГСЧ в силу особенностей использования ключей и алгоритмов.

Абсолютно согласен. В данном случае требования к ГСЧ могут быть значительно ниже, чем в других криптографических задачах.

Прекрасно. Подобный ответ я и надеялся услышать, когда создавал эту тему.

Почему бестолковой? Сейчас, как я понял в GrdUtil есть два ГСЧ - один надежный, для определителей, а другой "просто рандомный генератор", для паролей. Так, действительно, почему бы и для паролей не использовать надежный ГСЧ?

Я так и думал.

Полностью согласен.

У меня, наверное, неправильная GrdUtil - она разрешает чтение всем создаваемым алгоритмам (с паролем, слава богу). Некоторым видам алгоритмов она еще разрешает активацию/деактивацию.

Ваши опасения мне понятны, и могу вас заверить, что они беспочвенны :). Еще раз повторю - опеределитель не требует супермощного криптографического ГСЧ в силу особенностей использования ключей и алгоритмов. Но там далеко не srand(time)-rand(). Мы используем собственный ГСЧ, с собственным сбором энтропии (например, при сборе энтропии учитываются все действия пользователя с момента запуска GrdUtil). Качество "случайности" для каждого определителя проверяется по критерию согласия Пирсона (критерий Хи-квадрат), это помимо алгоритмов отсекающих заведомо слабые определители для конкретных типов криптоалгоритмов.
Плюс к этому наш ГСЧ тщательно тестировался специалистами по криптографии (мы сотрудничаем с кафедрой криптологии и дискретной математики МИФИ) и показал очень хорошие результаты, не уступающие популярным криптографическим ГСЧ.

Возможность генераций паролей защищенных ячеек с помощью аналогичного ГСЧ мы учтем в следующих версиях утилиты. Но вообще говоря это работа близкая к бестолковой, пароли проще всего подсмотреть отреверсив программу и вызовы Guardant API, а не используя математические методы и долго и мучительно собирая статистику.

Возможность прочитать определитель алгоритма из ключа есть потому, что алгоритм представляет из себя защищенную ячейку и это ее типичная возможность. В каких то редких сценариях эта возможность наверное может быть полезна, но вообще говоря алгоритмы действительно должны быть недоступны для чтения из ячейки и накрыт аппаратным запретом, и по умолчанию GrdUtil их создает именно таким образом. Просто я лично не вижу смысла блокировать эту возможность для алгоритмов просто ради блокирования. По умолчанию это всегда выключено.

вы сами можете генерировать и записывать туда любые пароли.

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

Допустим, в GrdUtil используется самый простой ГСЧ - rand(), причем без srand(). Этот ГСЧ будет всегда выдавать одну и ту же последовательность псевдослучайных чисел.

Я запускаю GrdUtil, создаю алгоритм (определитель, пароли на активацию и пр. GrdUtil генерирует сама), сохраняю маску, прошиваю ей электронные ключи.
Хакер запускает GrdUtil, создает алгоритм, и GrdUtil создает ему точно такие же пароли и определитель. Все. Ему не нужно ломать алгоритм, не нужно ничего брутфорсить, не нужно реверсить GrdUtil и вытаскивать оттуда ГСЧ -- GrdUtil сама выдаст все пароли.
Это в предположении, что используется rand() без srand(). Я все-таки надеюсь, GrdUtil использует что-то более надежное.

Использование rand() с  srand(time()) тоже не очень надежно, но уже не позволит так просто узнать пароли и определители. И, в сочетании с тем, что ключ ограничивает количество попыток перебора пароля,  это может быть вполне надежно.

И все же я не понимаю, почему GrdUtil не использует надежный ГСЧ с надежным seed-ом. Притом, что все это есть, в том числе открытое и бесплатное. Плохой ГСЧ может легко свести на нет все ваши труды по созданию электронных ключей  и сопутствующего софта.

То есть, определитель алгоритма создается с помощью надежного криптографического генератора случайных чисел (например, из CryptoAPI или OpenSSL), инициализированного надежным (длинным и случайным) seed-ом.

В зависимости от алгоритма шифрования/подписи есть свои критерии слабых определителей (ключей) и свои методы генерации ключей (ключевых пар). Эти методы и используются. В общем случае криптографический ГСЧ там не нужен, этот определитель подобрать или вычислить невозможно - это равносильно взлому самого алгоритма или тупому брутфорсу.

Опять же, необходимости в криптографически стойком ГСЧ для этой задачи нет. Мне даже сложно представить use case для этого. Алгоритм генерации не разглашается, но вы сами можете генерировать и записывать туда любые пароли.

Во все создаваемые в GrdUtil алгоритмы пишется уникальный (для каждого нового алгоритма сгенерированный отдельно), надежный определитель, которому можно доверять.

То есть, определитель алгоритма создается с помощью надежного криптографического генератора случайных чисел (например, из CryptoAPI или OpenSSL), инициализированного надежным (длинным и случайным) seed-ом.

А что значит "просто рандомно сгенерированные"?
С помощью CRT-шной функции rand() без использования srand()?
С помощью CRT-шной функции rand() с использованием srand(time())?
Или все же используется надежный ГСЧ?

Я хотел спросить, можно ли доверять определителю и паролям, которые GrdUtil прописала в свежесозданный алгоритм? Они действительно генерятся с помощью надежного ГСЧ, или во все создаваемые алгоритмы записывается один и тот же определитель?

Во все создаваемые в GrdUtil алгоритмы пишется уникальный (для каждого нового алгоритма сгенерированный отдельно), надежный определитель, которому можно доверять. Однако, указать определитель самостоятельно (вручную) разработчик тоже может. Про надежность определителей говорилось еще тут.)
Что же касается паролей для сервисов аппаратных алгоритмов, то это просто рандомно сгенерированные, целые числа, максимальная длинна которых, составляет 4 байта.

Внутри самого шаблона эти пароли меняться не будут даже при его активации, но для каждого шаблона придется отдельно, как то запоминать их, например, в виде nsd-файла сохраненного на основе данного шаблона.

Текущее поведение утилиты GrdUtil при заполнении (или не заполнении) полей паролей для сервисов различных аппаратных алгоритмов действительно не совсем понятное, и мы обязательно учтем Ваши рекомендации при дальнейшем развитии данной утилиты.

GrdUtil при создании алгоритма записывает в него определитель, а также пароли на чтение, активацию и деактивацию. Полагаю, эти данные генерируются при помощи достаточно надежного генератора случайных чисел. Это действительно так?

Я хотел спросить, можно ли доверять определителю и паролям, которые GrdUtil прописала в свежесозданный алгоритм? Они действительно генерятся с помощью надежного ГСЧ, или во все создаваемые алгоритмы записывается один и тот же определитель?

Тогда он будет уникальный для каждого записанного ключа. И храниться он будет, как я понимаю, в базе данных. А как быть с софтверным ключом? Как узнать, какие пароли записались в шаблон?
В данный момент, меня, видимо, интересуют постоянные пароли, сгенерированные однократно случайным образом.

Для этого была бы удобна кнопочка "Сгенерировать новое значение пароля". Она у вас есть, но только для определителей алгоритмов.
А, еще удобнее было бы, если бы случайные значения паролей автоматически генерировались бы при создании нового поля - защищенной ячейки или алгоритма.

При создании дескрипторов различных алгоритмов и защищенных ячеек, GrdUtil действительно по-разному может устанавливать набор активированных сервисов и паролей для них. Однако, для всех типов алгоритмов и защищенных ячеек, правильным будет следующее утверждение: если нужно чтобы GrdUtil генерировал пароли для активированных сервисов, то следует выбирать тип пароля как случайный (в выпадающем списке, справа от поля для указания пароля, выбирать соответствующее значение), если же используется постоянный пароль, то его необходимо указывать самостоятельно (получать любым удобным и надежным, по Вашему мнению, способом).

А пароль на обновление алгоритма по умолчанию в маске не создается, он нулевой. То есть, получается, при необходимости пользователь должен либо сам придумать пароль на перезапись, либо сгенерить его с помощью внешней утилиты с ГСЧ и скопипастить в диалог настройки алгоритма.

При создании же защищенной ячейки GrdUtil вообще не предлагает никаких случайных данных, ни паролей. То есть все придется делать руками? Или можно как-то попросить GrdUtil, чтобы она создавала алгоритмы и защищенные ячейки со случайными данными и паролями.

Цель всего этого такова: не поставлять пользователю ключ с незанятой памятью, а набить его различными алгоритмами и защищенными ячейками, так сказать, "про запас", чтобы в дальнейшем, при необходимости, можно было активировать новый алгоритм (ячейку), и использовать для защиты нового продукта.