Мне тоже не нравится категоричный тон автора статьи
Это вполне сознательная провокация.
А как работают с исключениями, на самом деле? Вот список всех кодов исключений. Мне просто интересно, какие из них можно «обработать» и после этого продолжить работу приложения, с конкретными примерами из жизни.
Ее так называют в литературе. И система эта очень напоминает RSA или ElGamal, которым Вы, я надеюсь, не отказываете в праве также являться криптосистемами.
RSA, кстати, также как и ECMV подвержен атаке с угадываением открытого текста, так как шифрование RSA является полностью детерминированным (шифротекст зависит только от открытого текста и ключа), и зная публичный ключ, можно перебирать варианты открытого текста, шифровать на публичном ключе и искать совпадение полученного шифротекста с имеющимся. Однако наличие такой «проблемы» нисколько не мешает криптосистеме RSA быть повсеместно реализованной и успешно работать чуть ли не в любой железке.
И нужно-то от такой системы очень немного: Уметь шифровать на публичном ключе, расшифровывать на приватном, уметь делать подпись на приватном ключе и проверять ее на публичном.
То, что Вы упорно пытаетесь подменить тему обсуждения и перейти к протоколам, сторонам, парам ключей, о чем в моей статье нет ни слова (это другой уровень), на мой взгляд — достойно сожаления. Но в любом случае — спасибо Вам за внимание и высказанные Вами мнения, даже если я с ними и не согласен.
Опять, зачем обсуждать протоколы, когда обсуждаемая статья посвящена алгоритмам асимметричного шифрования, и конкретно — отсутствию реализации алгоритма шифрования на публичном ключе и расшифровки на приватном для ECC. Как следует из статьи, описание такого алгоритма было дано более 20 лет назад, но почему-то не попало ни в openssl, ни в libgcrypt. Вот это странно. И что плохого в предложенном алгоритме ECMV, мне тоже непонятно. По сравнению со своими аналогами RSA и ElGamal он мало в чем им уступает, как мне кажется.
Мне по своей темности непонятно, зачем менять тему обсуждения и обсуждать протоколы, когда обсуждаемая статья посвящена алгоритмам асимметричного шифрования, и конкретно — отсутствию реализации алгоритма шифрования на публичном ключе и расшифровки на приватном для ECC.
ECC ключи должны использоваться ECDSA/ECDH алгоритмами
Ну, если gcry_pk_algo_info сообщает про то, что алгоритм ecc может GCRY_PK_USAGE_ENCR, то я просто вынужден в это поверить.
А какие параметры Вы задаете в gcry_pk_encrypt?
"(data (flags raw) (value #01020304050607080910111213141516#))" и public key.
Шифрование проходит без ошибок. В результате появляется шифротекст из двух элементов (по виду заголовков 0x04 — точек)
Как обычно, gcry_pk_genkey с параметром "(genkey (ecc (curve \«secp192r1\») ))"
В результате появляются приватный и публичный ключи ECC. Это все работает правильно, претензий нет.
В libgcrypt есть протоколы для обмена ключами (ECDH) и создания цифровой подписи (ECDSA), в них речь не о шифровании сообщений все-таки.
Простите мне мою безграмотность, но все-таки в libgcrypt есть функции gcry_pk_encrypt и gcry_pk_decrypt,
которые, будучи применены с ключами RSA или ElGamal шифруют и расшифровывают, т.е. ведут себя ожидаемо и в соответствии с документацией. Однако, если ключ ECC, то при шифровании открытый текст «012345678» превращается в шифротекст из двух элементов (точек), и это похоже на норму, а вот дешифровка дает большой бинарный блок с префиксом 0x04, т.е. точку… Или я чего-то не понимаю? В общем, libgcrypt меня разочаровал.
Ну, это… как-бы надо сравнивать подобное с подобным, при равной криптостойкости.
Возьмем RSA-2048: размер шифротекста 256 байт, размер шифруемых данных менее 256 байт
Возьмем ElGamal-2048: размер шифротекста 512 байт, размер шифруемых данных менее 256 байт
ECMV-224: размер шифротекста 112 байт, размер шифруемых данных менее 56 байт…
Если ECMV даже по относительному оверхеду ничем не хуже ElGamal, в чем вопрос?
И это даже без компрессии точек (а можно сохранять только одну координату x), которая, будучи применена, может уменьшить размер шифротекста еще на 1 модуль… тогда размер шифротекста будет 3 модуля, при размере шифруемых данных 2 модуля.
Про абсолютные размеры шифротекстов я уже молчу.
Совершенно заслуженно, существует ElGamal для ECC и ECIES. В частности, даже современный GPG позволяет генерировать ключи ECC и шифровать данные с помощью ECDH.
Мне показалось несправедливым, что для RSA и ElGamal есть алгоритмы шифрования на публичном ключе и расшифровки на приватном, а для ECC такой простейшей схемы нет.
ECDH работает с двумя публичными ключами, стороны А и стороны Б, из двух публичных ключей получается общий секрет. В своей статье я попытался найти классический вариант с одним ключом — шифрование на публичном ключе, расшифровка на приватном, описано, что нашел и как реализовал.
Это вполне сознательная провокация.
А как работают с исключениями, на самом деле? Вот список всех кодов исключений. Мне просто интересно, какие из них можно «обработать» и после этого продолжить работу приложения, с конкретными примерами из жизни.
Ее так называют в литературе. И система эта очень напоминает RSA или ElGamal, которым Вы, я надеюсь, не отказываете в праве также являться криптосистемами.
RSA, кстати, также как и ECMV подвержен атаке с угадываением открытого текста, так как шифрование RSA является полностью детерминированным (шифротекст зависит только от открытого текста и ключа), и зная публичный ключ, можно перебирать варианты открытого текста, шифровать на публичном ключе и искать совпадение полученного шифротекста с имеющимся. Однако наличие такой «проблемы» нисколько не мешает криптосистеме RSA быть повсеместно реализованной и успешно работать чуть ли не в любой железке.
И нужно-то от такой системы очень немного: Уметь шифровать на публичном ключе, расшифровывать на приватном, уметь делать подпись на приватном ключе и проверять ее на публичном.
То, что Вы упорно пытаетесь подменить тему обсуждения и перейти к протоколам, сторонам, парам ключей, о чем в моей статье нет ни слова (это другой уровень), на мой взгляд — достойно сожаления. Но в любом случае — спасибо Вам за внимание и высказанные Вами мнения, даже если я с ними и не согласен.
Опять, зачем обсуждать протоколы, когда обсуждаемая статья посвящена алгоритмам асимметричного шифрования, и конкретно — отсутствию реализации алгоритма шифрования на публичном ключе и расшифровки на приватном для ECC. Как следует из статьи, описание такого алгоритма было дано более 20 лет назад, но почему-то не попало ни в openssl, ни в libgcrypt. Вот это странно. И что плохого в предложенном алгоритме ECMV, мне тоже непонятно. По сравнению со своими аналогами RSA и ElGamal он мало в чем им уступает, как мне кажется.
Мне по своей темности непонятно, зачем менять тему обсуждения и обсуждать протоколы, когда обсуждаемая статья посвящена алгоритмам асимметричного шифрования, и конкретно — отсутствию реализации алгоритма шифрования на публичном ключе и расшифровки на приватном для ECC.
Ну, если gcry_pk_algo_info сообщает про то, что алгоритм ecc может GCRY_PK_USAGE_ENCR, то я просто вынужден в это поверить.
"(data (flags raw) (value #01020304050607080910111213141516#))" и public key.
Шифрование проходит без ошибок. В результате появляется шифротекст из двух элементов (по виду заголовков 0x04 — точек)
Как обычно, gcry_pk_genkey с параметром "(genkey (ecc (curve \«secp192r1\») ))"
В результате появляются приватный и публичный ключи ECC. Это все работает правильно, претензий нет.
Простите мне мою безграмотность, но все-таки в libgcrypt есть функции gcry_pk_encrypt и gcry_pk_decrypt,
которые, будучи применены с ключами RSA или ElGamal шифруют и расшифровывают, т.е. ведут себя ожидаемо и в соответствии с документацией. Однако, если ключ ECC, то при шифровании открытый текст «012345678» превращается в шифротекст из двух элементов (точек), и это похоже на норму, а вот дешифровка дает большой бинарный блок с префиксом 0x04, т.е. точку… Или я чего-то не понимаю? В общем, libgcrypt меня разочаровал.
Ну, это… как-бы надо сравнивать подобное с подобным, при равной криптостойкости.
Возьмем RSA-2048: размер шифротекста 256 байт, размер шифруемых данных менее 256 байт
Возьмем ElGamal-2048: размер шифротекста 512 байт, размер шифруемых данных менее 256 байт
ECMV-224: размер шифротекста 112 байт, размер шифруемых данных менее 56 байт…
Если ECMV даже по относительному оверхеду ничем не хуже ElGamal, в чем вопрос?
И это даже без компрессии точек (а можно сохранять только одну координату x), которая, будучи применена, может уменьшить размер шифротекста еще на 1 модуль… тогда размер шифротекста будет 3 модуля, при размере шифруемых данных 2 модуля.
Про абсолютные размеры шифротекстов я уже молчу.
Спасибо, исправил.
Мне показалось несправедливым, что для RSA и ElGamal есть алгоритмы шифрования на публичном ключе и расшифровки на приватном, а для ECC такой простейшей схемы нет.