#27 2012-04-02 10:52:39 (2012-04-02 10:54:23 отредактировано Антон Тихиенко)
Re: Переход от защиты 2-го поколения к защите 3-го
Антон, я сделал тестовый пример для 4 и 5 API.
По результатам видно, что идет несовпадение результатов при вызове EnCode и GrdEnCode для метода ASCII.
Подобное несовпадение НЕ является результатом, какой либо ошибки т.к. эти функции исключительно софтовые и алгоритм шифрования (а следственно и «вид» зашифрованных данных) для них может изменяться от версии к версии Guardant API.
Главное здесь то, что дешифрация проходит корректно.
Re: Переход от защиты 2-го поколения к защите 3-го
В нашем случае это очень плохо.
Поскольку на Encode на API 4 была завязана защита паролей для дальнейшего использования в функции Transformex.
А это три таблицы по 256 строк + 10 постоянных констант.
Причем вызов Decode осуществляется в более чем 100 процедурах.
Нам, чтобы заново сформировать таблицы для API 5 надо будет не менее месяца...:(
Да и потом главный вопрос, рационально ли это делать ???
Если программный алгоритм Encode меняется от версии к версии,
то есть вероятность, что при переходе к следующей версии придется опять всё переписывать...
Честно говоря, даже не знаю как поступить...
Полностью менять всю логику защиты ?
Это месяца два работы, это значит что проект, который мы должны сдать, уже по срокам точно срываем.
При этом надо обязательно переходить на ключи Sign...
Одно слово, засада...
Re: Переход от защиты 2-го поколения к защите 3-го
В нашем случае это очень плохо.
Поскольку на 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 увы не получится "без потерь".
Re: Переход от защиты 2-го поколения к защите 3-го
Антон, какую функцию использовать???
На 4 версии мы использовали Transformex и Encode/Decode.
Какие функции можно использовать сейчас, чтобы быть уверенным, что вы их сохраните в следующих API ???
Re: Переход от защиты 2-го поколения к защите 3-го
Антон, какую функцию использовать???
На 4 версии мы использовали Transformex и Encode/Decode.
Какие функции можно использовать сейчас, чтобы быть уверенным, что вы их сохраните в следующих API ???
Как и было сказано в предыдущем посте:
переделать на софтовый AES вряд ли нужно много времени, а он точно стандарт
лучше воспользоватся софтверной реализацией алгоритма AES. Для этого нужно вызывать GrdCrypt/GrdCryptEx с параметром dwAlgo = GrdSC_AES256.
Re: Переход от защиты 2-го поколения к защите 3-го
Антон, мы всё переписали. Спасибо за помощь.
Re: Переход от защиты 2-го поколения к защите 3-го
Нам также необходимо перейти со Stealth II на Sign. Проблема в том, что у нас около 50000 пользователей, защита была написана с использованием алгоритмов Encode/Decode на 4 версии API. Возможно ли в принципе дописать защиту так, чтобы программа определяла какой ключ используется и в зависимости от этого вызывала разные функции для расшифровки данных, при этом сами данные были одни и те же для разных типов ключей?
Re: Переход от защиты 2-го поколения к защите 3-го
Здравствуйте.
Возможно ли в принципе дописать защиту так, чтобы программа определяла какой ключ используется и в зависимости от этого вызывала разные функции для расшифровки данных, при этом сами данные были одни и те же для разных типов ключей?
Определить тип (модель) используемого электронного ключа не сложно, достаточно после вызова функции GrdFind воспользоваться структурой TGrdFindInfo или воспользоваться функцией GrdGetInfo. Однако, для того, чтобы расшифровать некоторые данные определенным алгоритмом, нужно чтобы эти данные, предварительно, были зашифрованы именно таким алгоритмом.
Наиболее просто осуществить миграцию с заданными условиями можно при помощи аппаратного алгоритма симметричного шифрования GSII64, поддержка которого имеется как в ключах Guardant Stealth II, так и в современных Guardant Sign. Таким образом, используя данный аппаратный алгоритм и идентичные определители, можно будет шифровать\дешифровать одинаковые данные при помощи ключей обоих типов.
Re: Переход от защиты 2-го поколения к защите 3-го
К сожалению, в написанной версии защиты на ключах StealthII, базы данных расшифровываются с помощью функций nskCodeInit/nnkCodeInit, nskDeCode/nnkDeCode алгоритмом 1(Fast). Я правильно понимаю, что на ключах Sign эти алгоритмы вообще не предусмотрены и данные, зашифрованные ключом StealthII функциями nskEnCode/nnkEnCode, расшифровать ключом Sign не получится?
Re: Переход от защиты 2-го поколения к защите 3-го
Я правильно понимаю, что на ключах Sign эти алгоритмы вообще не предусмотрены и данные, зашифрованные ключом StealthII функциями nskEnCode/nnkEnCode, расшифровать ключом Sign не получится?
Да, все верно.