Тема от mike_shubin (2016-12-09 17:57:14 отредактировано mike_shubin)

  • mike_shubin
  • Посетитель
  • Неактивен

Асимметричный алгоритм шифрования (не подпись!) на основе ECC160

Добрый вечер!

Очень не хватает асимметричной криптографии в ключе и в API.
RSA очень ресурсоёмкий и для ARM не подходит, а ECC на порядок легче и более криптостойкий (вроде ECC-160 аналогичен по криптостойкости RSA-2048).
С таким алгоритмом можно особо не заботиться о публичном ключе, чего не сказать о симметричных вариантах.
Примерное применения:
- частичное шифрование обмена между модулями/классами приложения (шифрование параметров методов)
- частичное шифрование обмена между клиентом и сервером (ключ установлен на сервере)
- выборочное периодическое шифрование/дешифрование полей БД (небольших и редко используемых таблиц)

Насколько я понимаю, алгоритм шифрования и дешифровки слабо отличается от алгоритма подписывания и проверки подписи (поправьте, если я не прав). Т.е. несложно реализовать аппаратную дешифрацию и организовать работу через ключ практически в любом методе, сделав невозможной эмуляцию и взлом.

Естественно, для подписи и шифрования нужно использовать разные пары ключей.

Ответ от mike_shubin

  • mike_shubin
  • Посетитель
  • Неактивен

Re: Асимметричный алгоритм шифрования (не подпись!) на основе ECC160

Добрый вечер!

Это стандартный алгоритм шифрования с публичным ключом по схеме Эль-Гамаля (Elgamal)
https://ru.wikipedia.org/wiki/%D0%A1%D1 … 0%BB%D1%8F

В сети есть много реализаций этого алгоритма на С:
https://github.com/Chronic-Dev/libgcryp … /elgamal.c
http://en.pudn.com/downloads154/sourcec … 53_en.html
http://ifsttar.power-lan.com/p/pegase/s … /elgamal.c
(и т.д., гугль в помощь)

Т.е. вопрос об использования этого шифрования на ключе Guardant Code не стоит - пиши да используй.
Но мне интересен аппаратный вариант этого алгоритма для ключей Guardant Sign. Математика та же самая, что используется при генерации ЭЦП...

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

Ответ от mike_shubin (2016-12-11 15:13:30 отредактировано mike_shubin)

  • mike_shubin
  • Посетитель
  • Неактивен

Re: Асимметричный алгоритм шифрования (не подпись!) на основе ECC160

Добрый день!

Алгоритм шифрования на открытом ключе ECC160 вовсю применяется для подготовки загружаемого кода в формате GCEXE:

GrdUtil.exe автоматически преобразует бинарный код в файл формата GCEXE, содержащий:

    Зашифрованный на AES исходный код
    Зашифрованный на открытом ключе ECC160 №#1 сеансовый ключ AES, использовавшийся ранее для шифрования кода
    ЭЦП файла, полученную на закрытом ключе ECC160 №#2

При этом в дескрипторе (ячейке) загружаемого кода хранится «ответная часть» ключей ECC, используемых при преобразовании бинарного кода:

    Закрытый ключ ECC160 №#1 для шифрования
    Открытый ключ ECC160 №#2 для ЭЦП

Что позволяет электронному ключу при обращении к загруженному коду успешно его проверять, расшифровывать и выполнять.

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

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

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Асимметричный алгоритм шифрования (не подпись!) на основе ECC160

Здравствуйте.

mike_shubin пишет:

либо мной был задан запредельно сложный технический вопрос, который требует недельной проработки...

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

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

Ответ от mike_shubin

  • mike_shubin
  • Посетитель
  • Неактивен

Re: Асимметричный алгоритм шифрования (не подпись!) на основе ECC160

Всё понятно, благодарю за ответ.

Видимо, я сильно избалован техподдержкой DevExpress, придётся отвыкать :-)
А в документации действительно есть мелкие, но неприятные неточности, например в описании списка параметров метода GrdCryptEx в разделе C# параметр data определён как [in], хотя в разделе С все корректно - pData [in, out].

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Асимметричный алгоритм шифрования (не подпись!) на основе ECC160

mike_shubin пишет:

А в документации действительно есть мелкие, но неприятные неточности, например в описании списка параметров метода GrdCryptEx в разделе C# параметр data определён как [in], хотя в разделе С все корректно - pData [in, out].

Большое спасибо, поправили.

Что же до шифрования ассиметричным ECC160, то здесь документация все же корректно, хоть и не совсем однозначно, описывает порядок подготовки GCEXE-файла. Тут действительно реализован механизм шифрования ключа AES на открытом ключе, хранящемся в дескрипторе ECC160. Сам алгоритм ECC160 в таком шифровании не участвует и шифровать не умеет (может подписывать данные).

Реализации аппаратного асимметричного алгоритма для шифрования данных в ближайшем будущем не ожидается, но, как и было верно отмечено, можно воспользоваться ключами Code для самостоятельной реализации подобного функционала.