Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение
что плохого в предложенном алгоритме ECMV, мне тоже непонятно


Если мы строим элиптическую кривую над полем Fq, где q состоит из s десятичных знаков, то каждый блок сообщения будет состоять из 2s ln 10 ≈ 6.64s битов. В ASCII (8 битов на символ) мы получаем 0.83s символов в блоке. Предположим энтропия английского языка равна 1.3 бита на символ. Тогда для перебора нам нужно 2ˆ1.3*0.83s ≈ 2ˆs операций. При сравнительно небольшом s это вполне возможно.
Сложно это обсуждать не видя код. То, что Вы получаете похоже на формат описанный в пункте 6 (Conversion Primitives) здесь: https://tools.ietf.org/html/rfc6637#page-4. Префикс 04 и дальше конкатенация двух координат.

ECDH сам по себе не шифрует сообщение, он формирует ключ, который в дальнейшем используется как симметричный ключ в AES.
ECC ключи должны использоваться ECDSA/ECDH алгоритмами. А какие параметры Вы задаете в gcry_pk_encrypt?
gcry_pk_encrypt требует публичного ключа, gcry_pk_decrypt — приватного. RSA и ElGamal генерируют эти пары ключей. Как Вы получаете эту пару используя EC?
Реализация ECC шифрования в libgcrypt есть, но очень специфична. Если коротко, то шифруемое сообщение m отображается на точку эллиптической кривой mG


Отображение сообщения/текста на точки кривой это очень нетривиальная задача, именно поэтому нет практической реализации ElGamal для EC, хотя теоретически такой алгоритм существует.

В libgcrypt есть протоколы для обмена ключами (ECDH) и создания цифровой подписи (ECDSA), в них речь не о шифровании сообщений все-таки.
А какие инструменты Вы используете для восстановления данных с исправных дисков?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность