Качество алгоритма
Утилита GrdUtil как-то умеет проверять "качество" алгоритма, и предлагает исправить "некачественные".
А можно ли это сделать самостоятельно или средствами Гардант АПИ?
Re: Качество алгоритма
Добрый день, Luck.
Luck пишет:
Утилита GrdUtil как-то умеет проверять "качество" алгоритма, и предлагает исправить "некачественные".
А можно ли это сделать самостоятельно или средствами Гардант АПИ?
Если нужно формировать и записывать маску в ключ при помощи Guardant API, то для определителей алгоритмов можно использовать любой "надежный", по Вашему мнению, генератор случайных чисел или, например, значения которые генерирует GrdUtil.
Re: Качество алгоритма
Так почему же тогда некоторые значения определителей GrdUtil считает некачественными?
Например, я открываю GrdUtil с маской по-умолчанию. Лезу в ТРУ, нажимаю "Сгенерировать", копирую его в буфер обмена и закрываю диалог. Потом лезу в алгоритм 00, и пытаюсь вставить из буфера обмена только что сгенерированное GrdUtil значение. Говорит, определитель некачественный, давай исправлю. Но она же сама его только что сгенерировала!
Re: Качество алгоритма
Luck пишет:
Так почему же тогда некоторые значения определителей GrdUtil считает некачественными?
Например, я открываю GrdUtil с маской по-умолчанию. Лезу в ТРУ, нажимаю "Сгенерировать", копирую его в буфер обмена и закрываю диалог. Потом лезу в алгоритм 00, и пытаюсь вставить из буфера обмена только что сгенерированное GrdUtil значение. Говорит, определитель некачественный, давай исправлю. Но она же сама его только что сгенерировала!
Не совсем понятна практическая ценность подобного эксперимента (число-вопрос например, имеет фиксированную длину, а определитель алгоритма может иметь размер как 16, так и 32 байта).
Судя по всему, Вы стремитесь использовать максимально качественные определители алгоритмов.
Как и упоминалось ранее, для этого имеется две возможности:
1) Использовать значения сгенерированные GrdUtil;
2) Использовать качественную реализацию стороннего генератора случайных чисел. Использование качественного генератора гарантирует Вам получение нормально распределенных случайных чисел.
Re: Качество алгоритма
Антон Тихиенко пишет:
Не совсем понятна практическая ценность подобного эксперимента (число-вопрос например, имеет фиксированную длину, а определитель алгоритма может иметь размер как 16, так и 32 байта).
О числе-вопросе речи. вроде не было.
Цель эксперимента - поиграться с TRU. Для этого нужно прописать один и тот же определитель в три алгоритма: в TRU пользовательского ключа, и в GSII64 и HASH64 вендорного ключа.
Естественное решение:
1) открыть диалог свойств TRU
2) скопировать определитель в клипборд
3) закрыть диалог свойств TRU
4) открыть диалог свойств алгоритма 00 (GSII64)
5) вставить определитель из клипборда
6) закрыть диалог
7) открыть диалог свойств алгоритма 01 (HASH64)
8) вставить определитель из клипборда
9) закрыть диалог
Далее, прошиваем полученную маску в два ключа и играемся с удаленной прошивкой.
Но почему-то на шагах 6) и 9) возникает предупреждение о ненадежности определителя и предложение его исправить. Причем, это возникает, даже если на шаге 1) нажать кнопку "Сгенерировать"
Re: Качество алгоритма
Антон Тихиенко пишет:
Судя по всему, Вы стремитесь использовать максимально качественные определители алгоритмов..
Вернее,я не хочу использовать заведомо "некачественные" определители.
Антон Тихиенко пишет:
Как и упоминалось ранее, для этого имеется две возможности:
1) Использовать значения сгенерированные GrdUtil;
Как я уже писал выше, значения сгенерированные GrdUtil не всегда являются "качественными" (по мнению самой же GrdUtil).
Естественно возникает предположение о наличие у GSII64 "слабых" ключей (как, например, у DES). Если это так, то хотелось бы иметь возможность самому проверять "качественность" ключей. Если это не так, то я не понимаю, на основании чего GrdUtil объявляет некоторые ключи "некачественными".
Re: Качество алгоритма
Практика показывает что предупреждение о некачественном ключе даётся при неоднократном повторении одинаковых байт. Возможно при вставке часть байт не заменяется и остаются 00? Как я понял сложного алгоритма проверка ключа нет.
Re: Качество алгоритма
Luck пишет:
О числе-вопросе речи. вроде не было.
Тут имелся ввиду пароль удаленного обновления, прошу прощения за опечатку.
Luck пишет:
Цель эксперимента - поиграться с TRU. Для этого нужно прописать один и тот же определитель в три алгоритма: в TRU пользовательского ключа, и в GSII64 и HASH64 вендорного ключа.
Действительно, данные требования необходимо выполнять, если нужно сделать собственную TRU - утилиту.
Однако для проведения удаленного обновления при помощи наших стандартных утилит (GrdTRU+GrdUtil) достаточно чтобы совпадали пароли удаленного обновления в обновляемом ключе и его прошивке в БД GrdUtil, в этом Вы можете легко убедиться, ознакомившись с нашими обучающими материалами, а именно "Урок 4. Знакомство с технологией Доверенного удаленного обновления (TRU)" (обратите внимание на то, что при генерации маски GrdUtil формирует разные пароль TRU и определители алгоритмов GSII64 и HASH64).
Luck пишет:
Естественно возникает предположение о наличие у GSII64 "слабых" ключей (как, например, у DES). Если это так, то хотелось бы иметь возможность самому проверять "качественность" ключей. Если это не так, то я не понимаю, на основании чего GrdUtil объявляет некоторые ключи "некачественными".
Если есть сомнения в качестве сгенерированных GrdUtil значений определителя, то, как уже неоднократно упоминалось можно использовать сторонние качественные (по Вашему мнению) генераторы случайных чисел.
Re: Качество алгоритма
DiK пишет:
Практика показывает что предупреждение о некачественном ключе даётся при неоднократном повторении одинаковых байт.
Провел эксперименты:
1) Заходим в редактор пароля TRU, генерируем новое значение и сохраняем.
Повторяем 10 раз - ни одного предупреждения о некачественном определителе.
2) Заходим в редактор алгоритма 00 (GSII64), генерируем новое значение и сохраняем.
10 раз - ни одного предупреждения о некачественном определителе.
3) Заходим в редактор алгоритма 00, набираем руками Hex-абракадабру.
5 раз - 5 предупреждений о некачественном определителе.
4) Заходим в редактор пароля TRU, генерируем новое значение, копируем и выходим. Заходим в редактор алгоритма 00, вставляем значение и пытаемся сохранить.
5 раз - 4 предупреждения о некачественном определителе
Вот "некачественные" определители:
88 C4 14 53 94 BA A8 30 F0 83 B2 02 F4 10 D8 54
0B F0 5B 64 13 60 C5 FF F5 DA 8C F2 4B DA F7 1D
F0 3D 6A FE 14 18 93 50 73 3B 7D F6 0F 9E B8 0F
15 7F D0 BE FE 15 6A 9A FF 96 97 9D 4F 55 64 F8
Невооруженным глазом признаков "некачественности" здесь не видно.
А вот "качественный" определитель:
35 96 8E 97 C5 C0 A0 25 FB AD A8 16 A6 02 4E 13
DiK пишет:
Возможно при вставке часть байт не заменяется и остаются 00? Как я понял сложного алгоритма проверка ключа нет.
Нет, копируется все правильно, нулей не остается.
Антон Тихиенко пишет:
Однако для проведения удаленного обновления при помощи наших стандартных утилит (GrdTRU+GrdUtil) ...
Мой целью было смоделировать работу еще не написанной ТРУ-утилиты.
То есть, создать два ключа - пользовательский и вендорный. Простейший способ это сделать - через GrdUtil. А затем провести удаленное обновление, используя ваш АПИ-экзекьютор. Так что, в данном случае GrdTRU+BD не подходят
Все-таки хотелось бы получить ответ на вопрос: почему многие значения определителей GrdUtil считает "некачественными". Или считать эту фишку программы глюком и не обращать внимания?
Re: Качество алгоритма
Luck пишет:
Все-таки хотелось бы получить ответ на вопрос: почему многие значения определителей GrdUtil считает "некачественными". Или считать эту фишку программы глюком и не обращать внимания?
Механизмы генерации пароля удаленного обновления и определителя алгоритма по объективным причинам могут отличаться друг от друга.
Также стоит отметить и то, что GrdUtil никак не проверяет стойкость сгенерированного им пароля для TRU (в отличие от определителей алгоритмов, которые проверяются), так как безопасность текущей сессии удаленного обновления достигается за счет уникального сессионного ключа, который генерируется заново для каждой сессии, а пароль для TRU разработчик может указывать любой какой захочет.
Таким образом, в данном случае, для уверенности в надежности можно использовать сгенерированный GrdUtil 16 байтовый определитель для алгоритма в качестве пароля TRU.