| ||||
| ||||
| Можно ли CryptoPro использовать для симмметричной схемы шифрования ГОСТ-ом без генерации сессионных ГОСТ-ключей, обмена public-ключами и т.п.? (Продполагается использовать "закрытую" схему распределения ключей, хранящихся в e-Token и т.п. устройствах. Эти ключи генерятся и раздаются в одном месте.) | ||||
| Ответы: | ||||
| ||||
| Вообще КриптоПро CSP использует открытое распределение ключей. Но ГОСТ шифрования у нас симметричный, поэтому используются сессионные ключи. Если вы думаете, что в симметричной схеме распределения ключей информация шифруется на долговременных ключах, то это не так. Все равно используется сессионные ключи. Теперь про eToken и т.д. и т.п. и симметричное распределение ключей. Представьте, что у вас 1000 пользователей. Каждому из них нужно дать вектор ключей для связи с друг другом. Если информацию с ключом будет бат по 60, то у вас уже 65 Кб, которые нужно записать. И кончился eToken. Что касается централизованной генерации ключей. Открытое распределение ключей не отменяет такой возможности. Генерите ключи и раздавайте пользователям. | ||||
| ||||
| Большое спасибо за ответ! Понимаю преимущества открытого распределения ключей - только тут задача достаточно специфическая: есть сеть серверов и операторские консоли. Требуется, чтобы шифровался трафик между консолью и сервером - причем совсем не обязательно, чтобы каждый с каждым имел свою пару ключей - может быть одна на всех. Поэтому, при шифровании на долговременных ключах: 1. Память eToken не переполнится (там будет храниться 1 ключ) 2. Не нужно реализовывать механизм хранения public-ключей консолей и серверов. Если я правильно понимаю, при использовании CryptoPro, от сессионных ключей "не отвертеться". Поэтому, каждый сервер должен хранить список public-ключей консолей, а каждая консоль - список public-ключей серверов. Получаем проблемы для тех, кто занимается поддержкой - при добавлении/удалении операторского места надо обновить список ключей на всех серверах, а при добавлении/удалении сервера - список ключей на операторских консолях. Что, согласитесь, может быть неудобно. | ||||
| ||||
| Шифровать на одном ключе для всех смысла не имеет. Что будете делать когда у вас одна "консоль" вместе с ключом уволилась. Менять ключи у всех? В окрытом распределении добавлять ключи (сертификаты) каждому не нужно. Можно исходить из условий: 1. Сертификат выдан центром которому доверяют. 2. Сертификат не отозван. Кроме этого вам нужно будет реализовать собственный протокол. Зачем. Пользуйте SSL (TLS). | ||||
Сергей