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

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

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

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

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

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

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

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

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

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

Это стандартный алгоритм шифрования с публичным ключом по схеме Эль-Гамаля (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. Математика та же самая, что используется при генерации ЭЦП...

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

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

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

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