Так всё таки закрытый ключ создаётся не на сервере?
Обычно ЭП подразумевает использование сертификатов, у вас они планируются?

Могу ли я с помощью библиотек крипто про, не используя сторонних кроме Microsft библиотек сделать создание контейнера в режиме Silent?
Чтобы контейнер у меня создавался по указанному пути и в него ложился ключ. Без использования сертификатов и без появления всплывающих окон?
Меня интересует позволяют ли библиотеки Sharpei задавать путь для создания (Не поиска) контейнера?
И возможно ли передать из вне случайное число сгенерированное с помощью алгоритма гамма распределения объекту Gost3410CryptoServiceProvider для создания приватного ключа?

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

Подписание можно сделать плагином на страничке, открытой на рабочем месте пользователя, а для проверки достаточно открыть криптопровайдер в VERIFY режиме и импортировать открытый ключ. Если говорить дальше, то в принципе открытый ключ должен быть включен в подпись и наличие открытого ключа в БД нужно только для идентификации чья подпись.

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

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

Отредактировано пользователем 10 января 2020 г. 6:47:37(UTC)  | Причина: Не указана

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

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

Отредактировано пользователем 13 января 2020 г. 15:14:39(UTC)  | Причина: Не указана