По многочисленным просьбам нуждающихся выкладываю ВЕСЬ проект. В нем есть готовый exe. Постарался расписать, что нужно для работы. Ну яснее просто некуда!
Рабочий, проверил перед опубликованием. CryptoFss.rar (1,316kb) загружен 101 раз(а).

P.S. Господа, если для решения поставленной задачи вы не знаете и не понимаете что делать, то в этом случае нужно учиться, разбираться, изучать материал. Получить готовый пример это хорошо, много раз так делал и сам, но так вы никогда не станете высококвалифицированным специалистом.

Я только не совсем понимаю, если теперь сертификат отправителя внутри зашифрованного сообщения, то как они получают ключ согласования для расшифровки. Регистрируете сертификат отправителя заранее?

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

Отредактировано пользователем 11 мая 2021 г. 12:41:44(UTC)  | Причина: Не указана

Посмотрел, не так чтобы совсем до деталей, но действительно фокус в эфемерной ключевой паре. Генерируется эфемерная ключевая пара. Ключ согласования (симметричный) вырабатывается с участием закрытой части эфемерной пары и открытого ключа из сертификата ФСС. Далее (как и раньше) генерируется сессионный ключ (симметричный). Данные (подписанный файл) шифруются сессионным ключом. Сессионный ключ шифруется ключом согласования. К зашифрованному сессионному симметричному ключу в блоб прикрепляется открытая часть эфемерной пары, после чего эфемерная пара, сессионный ключ, ключ согласования уничтожаются.

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

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

Итого: в процессе шифрования/расшифрования запроса участвуют эфемерная ключевая пара + пара ФСС, сессионный ключ. Для ответа - другая эфемерная ключевая пара + пара отправителя запроса, другой сессионный ключ. Раньше были и для запроса и для ответа пара отправителя запроса + пара ФСС, сессионный ключ.

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

Пытаюсь разобраться с примером от Alexcrool (#22)
Все собрал, скомпилировал, но вот незадача: при запросе ругается на незарегистрированный класс, который находится в c14n.dll

И зарегистрировать эту dll не удается (точка входа DllRegisterServer не найдена).
Если вы использовали этот вариант, как с этим справились?