Добрый день,

имея ключ 2048-бит rsa, я могу зашифровать сообщение не больше 190 байт (строка 358)

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

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

Anatoly Moskovsky,

Т.е основная причина скорость шифрования. Спасибо.

Да, но контейнеры криптопро работают именно через ассиметричные ключи(сертификаты) и инструмент соотвественно нужен как воркэраунд над криптопро-контейнерами

Dimitry Sibiryakov,

автор each to be encrypted with RSA, is not normally done, for a variety of reasons: it is difficult to do it right without adding extra weaknesses; each block would be expanded by 11 bytes

Ну вот же - "это трудно реализовать без добавления некоей слабины, плюс каждый блок увеличится на 11 байт". Последнее я не писал, т.к я не понимаю почему каждый блок должен увеличиваться на 11 байт, я просто зарезервировал первые 10 байт(uint64) для размера сообщения, а дальше уже идут спаренные шифрованные блоки.
Откуда вы выбрали про plain text я не нашел, но говорит он о том что если хочешь rsa - то умещайся в 1 блок всем сообщением.

Anatoly MoskovskyOracleLoverДа, но контейнеры криптопро работают именно через ассиметричные ключи(сертификаты) и инструмент соотвественно нужен как воркэраунд над криптопро-контейнерами
Вы читаете, что вам пишут?
Никто данные не шифрует асимметричными шифрами.
Вам кажется.

Да, спасибо, я понял что используют смешанный подход, когда rsa шифруют сеансовый ключ, а сами данные шифруют с помощью этого сеансового ключа через aes. Но я вижу подобный кейс:




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




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

Leonid Kudryavtsev,

криптопро не шифрует отдельные сообщения - он шифрует либо трафик, либо файлы

авторПервые 16 байт зашифрованного сообщения рассмотри внимательнее.
Хорошо

Leonid KudryavtsevOracleLoverкриптопро не шифрует отдельные сообщения - он шифрует либо трафик, либо файлы
AFAIK Насколько я помню MS Crypto API, там шифруется просто набор (массив) байт.

Что это - файл, письмо или что-то другое, наверное не принципиально ))).

именно, но "наружу" криптопро не дает апи которые бы работало с набором байт. Это все в контексте того "почему я напрямую не использую криптопро".
Предугадывая следующий вопрос - "почему бы тогда не использовать напрямую MS CryptoAPI", я скажу что не знаю почему, наверное потому что криптопро не просто враппер над cryptoapi, но и вносит какие-то ГОСТОвскиесвои коррективы.