По результатам видно, что идет несовпадение результатов при вызове EnCode и GrdEnCode для метода ASCII.
На почту отправил тестовые примеры для Delphi вместе с проектами и скриншот результатов.
]]>Я правильно понимаю, что на ключах Sign эти алгоритмы вообще не предусмотрены и данные, зашифрованные ключом StealthII функциями nskEnCode/nnkEnCode, расшифровать ключом Sign не получится?
Да, все верно.
]]>Возможно ли в принципе дописать защиту так, чтобы программа определяла какой ключ используется и в зависимости от этого вызывала разные функции для расшифровки данных, при этом сами данные были одни и те же для разных типов ключей?
Определить тип (модель) используемого электронного ключа не сложно, достаточно после вызова функции GrdFind воспользоваться структурой TGrdFindInfo или воспользоваться функцией GrdGetInfo. Однако, для того, чтобы расшифровать некоторые данные определенным алгоритмом, нужно чтобы эти данные, предварительно, были зашифрованы именно таким алгоритмом.
Наиболее просто осуществить миграцию с заданными условиями можно при помощи аппаратного алгоритма симметричного шифрования GSII64, поддержка которого имеется как в ключах Guardant Stealth II, так и в современных Guardant Sign. Таким образом, используя данный аппаратный алгоритм и идентичные определители, можно будет шифровать\дешифровать одинаковые данные при помощи ключей обоих типов.
]]>Антон, какую функцию использовать???
На 4 версии мы использовали Transformex и Encode/Decode.
Какие функции можно использовать сейчас, чтобы быть уверенным, что вы их сохраните в следующих API ???
Как и было сказано в предыдущем посте:
переделать на софтовый AES вряд ли нужно много времени, а он точно стандарт
лучше воспользоватся софтверной реализацией алгоритма AES. Для этого нужно вызывать GrdCrypt/GrdCryptEx с параметром dwAlgo = GrdSC_AES256.
]]>В нашем случае это очень плохо.
Поскольку на Encode на API 4 была завязана защита паролей для дальнейшего использования в функции Transformex.
А это три таблицы по 256 строк + 10 постоянных констант.
Причем вызов Decode осуществляется в более чем 100 процедурах.
Нам, чтобы заново сформировать таблицы для API 5 надо будет не менее месяца...:(
Да и потом главный вопрос, рационально ли это делать ???
Если программный алгоритм Encode меняется от версии к версии,
то есть вероятность, что при переходе к следующей версии придется опять всё переписывать...
Честно говоря, даже не знаю как поступить...
Полностью менять всю логику защиты ?
Это месяца два работы, это значит что проект, который мы должны сдать, уже по срокам точно срываем.
При этом надо обязательно переходить на ключи Sign...
Одно слово, засада...
Действительно, ситуация получается довольно странная. К сожалению, алгоритмы Encode/Decode являются устаревшими, были оставлены в 5ом АПИ только для совместимости и их использование очень не рекомендуется (об этом прямо говорится в документации). Выявленное поведение Encode в режиме ASCII в принципе можно считать и ошибкой. Проблема в том, что этой функцией в 5 API практически никто не пользуется и исправление ошибки будет происходит в очень низкоприоритетном режиме (т.е. счет идет на несколько месяцев, не раньше).
Могу лишь порекомендовать полностью отказаться от этой функции (уверен, что в можете найти и оперативное решение - переделать на софтовый AES вряд ли нужно много времени, а он точно стандарт). В случае если вы переделаете таблицы на новую функцию Encode, не могу гарантировать что мы не исправим это поведение через несколько месяцев и функционирование Encode не вернется к 4 версии API.
Перейти на Sign со вторых Stealth и четвертого API увы не получится "без потерь".
]]>Антон, я сделал тестовый пример для 4 и 5 API.
По результатам видно, что идет несовпадение результатов при вызове EnCode и GrdEnCode для метода ASCII.
Подобное несовпадение НЕ является результатом, какой либо ошибки т.к. эти функции исключительно софтовые и алгоритм шифрования (а следственно и «вид» зашифрованных данных) для них может изменяться от версии к версии Guardant API.
Главное здесь то, что дешифрация проходит корректно.
]]>По результатам видно, что идет несовпадение результатов при вызове EnCode и GrdEnCode для метода ASCII.
На почту отправил тестовые примеры для Delphi вместе с проектами и скриншот результатов.
]]>проверил, к этому файлу в модуле grddelphi.pas путь прописан,
файл там лежит...
т.е. вроде всё корректно, но результаты разные...
куда дальше копать не понятно
Хочу еще раз особо подчеркнуть, что функции EnCode\DeCode версий 4.8 и 5.х работают корректно - т. е. расшифрованные данные идентичны, как Вы сами можете убедиться из наших примеров. Т. о. природа проблемы, скорее всего носит частный характер.
Поэтому для того, чтобы мы все-таки смогли обнаружить причину описанного Вами поведения софтовых функций, выполните следующие, обязательные, действия:
1) Соберите, пожалуйста, два небольших теста, на которых _проявляется данный эффект_: то есть просто использование данных функций для API v4 и v5 с явно передаваемым паролем. Пришлите полный тестовый проект нам на почту;
2) Обязательно уточните какая\ие верия-и (если, например, для тестов используются различные версии драйверов, то обязательно укажите какие и для какого API) драйвера Guardant используется?
Это необходимые условия решения проблемы. Без этого определить, в чем она состоит, мы не можем.
]]>Антон, моя почта wbp@mail.ru
Отправил письмо.
]]>