Добрый день.
Также нужно учесть особенность алгоритмов гост, если требование шифровать гостом. Особенность заключается в том, что алгоритм гост-89 симметричный, то есть и ключ шифрования тоже симметричный и есть проблема передачи его по открытым каналам связи. Плюс потенциальная возможность варьировать список получателей, у которых есть доступ к данным.
Короче: Вы пытаетесь изобрести велосипед. Все это уже учтено в "схеме обмена ключами" ГОСТ, надо только посмотреть на схему под углом Вашей задачи.
Суть схемы кратко:
1) Для каждой стороны участвующей в обмене генерируется ассиметричная ключевая пара. Открытый можно использовать как есть, но чаще всего делают сертификат, в котором указан открытый ключ. Допустим, делаете это раз в год. Если делаете обмен только внутри компании - можете выпустить сертификаты на внутреннем удостоверяющем центре, сертификаты в схеме просто для удобства, все сработает и с "голым" открытым ключом. Далее я пишу с предположением, что все-таки сертификат сделали.
2) для каждой порции данных (документа, например) "отправителем" генерируется уникальный сессионный (симметричный!) ключ, которым шифруются данные. Размер зашифрованных данных равен размеру исходных данных плюс вектор инициализации плюс выравнивание.
3) из двух ассиметричных пар ключей (закрытый ключ одной пары "отправителя" и открытый ключ второй пары "получателя") вычисляют симметричный ключ согласования. Другими словами, потребуется сертификат второй стороны (каждого "получателя") - для извлечения открытого ключа второй стороны. Фокус в том, что можно взяв с потолка 2 разные ключевые пары одинакового гост одинаковых параметров, и имея в наличии одну пару плюс открытый ключ другой независимо в двух местах получить одинаковый ключ, без его передачи по открытым каналам связи и без раскрытия закрытого ключа кому-либо.
Важно: технически сработает и с одной ключевой парой как "отправителя" и "получателя", но если хотите протестировать шифрование используйте две разные, так как с одной не все части алгоритма реально проверятся.
Почему не шифровать данные сразу ключом согласования: это создает возможность подбора ключа со временем и неудобно при шифровании для нескольких получателей - размер исходных данных будет умножен на количество получателей. Ключ несколько байт, а данные могут измеряться гигабайтами, разумнее зашифровать несколько вариантов вторичного (сессионного) ключа для каждого получателя чем несколько вариантов данных.
4) ключом согласования шифруют сессионный ключ, в какой-нибудь обертке вокруг зашифрованного ключа указывается для какого сертификата получателя этот зашифрованный сессионный ключ.
5) шаги 3-4 повторяются для всех кому потребуется доступ к данным, то есть "получатели" и возможно сам "отправитель".
6) передают другой стороне (загружаются на сервер в Вашем случае): сертификат "отправителя" (один экземпляр), набор зашифрованных вариантов сессионного ключа (по одному варианту на каждого "получателя" и возможно "отправителя"), сами зашифрованные данные (один экземпляр).
Любой кто имеет доступ может сделать еще вариант зашифрованного сессионного ключа на какую-то новую ключевую пару (свою новую пару, например), но тогда уже сделавший копию будет считаться "отправителем".
Перед окончанием срока использования закрытого ключа можно просто перешифровать все зашифрованные сессионные ключи получателя на новую ключевую пару. Это может сделать как получатель, так и отправитель. Сам сессионный ключ нет необходимости менять часто и данные можно не перешифровать. В типовом виде, как в утилите - результат хранится в одном файле, но возможно для замены Вам будет удобнее на FTP хранить "россыпью" - отдельно зашифрованные данные и отдельно ключи.
Для размышления: интересен вариант с первоначальной отправкой подразделением зашифрованных данных (плюс зашифрованный список рассылки), указав получателем сертификат центральной информационной системы (ИТ-отдела ?), а далее центральная ИС может уже выступить "отправителем" и сделать по списку рассылки доступ остальным подразделениям (создать зашифрованные сессионные ключи на сертификаты "получателей"). В этом случае раздача доступа будет централизована и замена ключей легко поддается автоматизации, а при необходимости можно добавить получателей или наоборот удалить. Подразделениям не понадобятся сертификаты всех подразделений, только сертификат центральной ИС. Минус: есть значительные риски при компрометации закрытого ключа центральной ИС (этакого суперключа).
Есть еще вариант шифрования на эфемерной ключевой паре (без постоянной ключевой пары "отправителя" и сертификата "отправителя"), но если собираетесь перешифровать ключи через год - он не подойдет.
Соответственно при расшифровке:
1) скачиваются зашифрованные данные, нужный зашифрованный ключ (выбирается по указанию для кого), сертификат отправителя.
2) из сертификата (открытого ключа) "отправителя" (другой стороны) и закрытого ключа "получателя" (своего) "получатель" вычисляет ключ согласования
3) ключом согласования расшифровывается зашифрованный сессионный ключ - полается сессионный ключ
4) сессионным ключом расшифровываются данные.
