Андрей

В защищенном документообороте обычно нужны 3 составляющие (некоторые могут быть неактуальны именно для Вашей организации):

• подтверждение авторства документа (реализуется в 99% посредством ЭП; но видел решения, в которых это достигается правами пользователей - такие схемы беззащитны перед админом)
  
• подтверждение даты/времени подписания документа (правильный путь - использовать сервер доверенного времени - Timestamp Authority (TSA) (он накладывает свою ЭП на хеш документа и собственную дату/время), не очень правильный путь - решать этот вопрос за счет подсистемы доступа)
  
• разграничение доступа к документам и комментариям к ним (текстам задач) (правильный путь снова - криптографический - secret sharing, не очень правильный - за счет подсистемы доступа)
  

Плюс очень важным в плане юзабилити системы свойством является поддержка workflow - то есть возможности передавать документы определенного рода по заранее предопределенным маршрутам между пользователями (например, заявления, согласование/ознакомление с приказами и т.п.).

И вот если я верю, что все криптографиечские задачи, описанные в списке реально реализовать "на коленке", например на OpenSSL (пусть и неудобно для пользователя), то последнюю позицию (workflow) самостоятельно построить очень сложно. Возьмите лучше какую нибудь бесплатную СЭД.

В реальной жизни используются "правильные" (криптостойкие) хеш-функции, например, SHA-256. А размер подписываемого по ElGamal сообщения со стойким размером асимметричного ключа примерно и будет в этом диапазоне (если меньше - дробят на 2-3 сообщения, если больше - расширяют padding-ом).

Не проще ли хранить информацию о том, что клиент с таким то уникальным ID уже получил обновление, и повторно ему обновление не выдавать. Тогда пользователь, "поделившийся" своим дистрибутивом, сам вырыл себе яму.

Квалифицированная ЭП может быть выдана только аккредитованным УЦ.
Аккредитованный УЦ должен быть отдельным юр.лицом и этот вид деятельности должен быть прописан в Уставе.
Либо занимайтесь организацией УЦ - а это немаленькие затраты, либо покупайте для клиентов квалифицированную ЭП в любом из УЦ, входящих в пространство доверия.
Подробнее о первом и втором - здесь minsvyaz.ru/ru/directions/?regulator=118

IP-адрес отправителя записывает в заголовки письма почтовый сервер, получающий от Вас письмо, а дополняют информацию все последующие сервера в цепочке передачи

(про IP-адрес в ЭЦП ни разу не слышал, но гарантировать отсутствие не могу)

Простая электронная подпись - не использует криптографию и соответственно не может использоваться для подтверждения целостности какого-либо документа/сообщения/файла (о чём в принципе явно указано в 63-ФЗ). Ее применяют на свой страх и риск участники обмена по взаимной договоренности в основном в тех случаях, когда риски, связанные с ее использованием невелики, а сама информационная система имеет массу сертификатов и заключений об отсутствии НДВ.

В принципе, конечно, достаточно выполнить все требования статьи 9 63-ФЗ и ЭП будет считаться имеющей юридическую значимость. Однако, в случае, если разработчик информационной системы - Вы (а не стороннее юр.лицо с лицензией на ТЗКИ), то не забывайте, что Вы будете фактически находиться в заведомо неравных условиях против пользователя (иметь техническую возможность манипулировать переданными Вам данными) и в суде клиент может потребовать независимую экспертизу, результат которой может оказаться непредсказуемым.

Вот такой вариант Вам не подойдет ?
www.cryptopro.ru/forum2/default.aspx?g=posts&t=1721

Да, налицо деятельность (получение прибыли), связанная с криптографией. (Если бы Вы разрабатывали ПО находясь в штате заказчика - другой вопрос).

Это попадает под ПП-313 в отдельных статьях и у ФСБ будут соответствующие требования к Вашим разработчикам и к самой организации. Плюс это попадает под ПКЗ-2005 - также рекомендую внимательно прочесть.

Сейчас разработка криптографии весьма строго контролируется ФСБ.
(P.S. ФСО никакого отношения к этому контролю в Вашем случае не имеет)