Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
|
Автор: learner158  Вот что мне известно про цифровую подпись:
Если мы говорим про цифровую подпись сертификата, то рассчитанный CA сервером хэш от полей сертификата, зашифрованный закрытым ключом и помещенный в поле digital signature того же самого сертификата, и есть цифровая подпись этого сертификата.
Если мы говорим про цифровую подпись для аутентификации в том же VPN, то цифровая подпись, это некие аутентификационные данные (хэш), зашифрованный закрытым ключом отправителя.
Процедура использования цифровой подписи при аутентификации выглядит следующим образом: рабочая станция, используя закрытый ключ из токена, шифрует аутентификационные данные и посылает на удаленный сервер. Сервер, используя открытый ключ рабочей станции (сертификат), расшифровывает эти аутентификационные данные. Если открытым ключом рабочей станции удалось расшифровать аутентификационные данные, зашифрованные закрытым ключом рабочей станции, значит рабочая станция является истинным владельцем открытого ключа (сертификата). Никто не похитил открытый ключ рабочей станции и не пытается выдать себя за неё. Таким образом, цифровая подпись, это хэш от неких данных, зашифрованный закрытым ключом отправителя.
Это, конечно, если здесь ошибки нет. Фактически шифрование это неотъемлемая часть цифровой подписи.
ГОСТ также работает, или нет? Есть пара кардинальных отличий: 1) в схемах до гост-2012 используется симметричный алгоритм гост-89, в гост-2015 он переименован в "магма" и введен новый алгоритм шифрования "Кузнечик". Таким образом, "открытый" и "закрытый" ключи из ключевой пары гост напрямую использовать в шифровании нельзя. Для шифрования как правило используется "схема обмена ключей": сначала из двух ключевых пар отправителя и получателя вырабатывается симметричный ключ согласования (открытый ключ одной пары и закрытый ключ другой, поэтому его можно выработать не раскрывая своего ЗК, а только имея открытый ключ другой стороны - из сертификата или иным способом), потом генерируется случайный симметричный сессионный ключ (вообще никак не связан с ключевой парой). Данные шифруются сессионным ключом, а сессионный ключ шифруется ключом согласования. Как справедливо отметили выше это позволяет отправить сообщение 1Мб 100 получателям используя один и тот же блок зашифрованных данных 1 Мб, но при этом 100 экземпляров зашифрованного сессионного ключа (для каждого получателя) 100*64=6400 байт (плюс обертки). 2) легко понять, что если "открытый" и "закрытый" ключ не используются напрямую в шифровании, то туда напихали каких-то других данных. Эти данные "закрытого" ключа (в совокупности с прописанными жестко в алгоритме) могут напрямую использоваться для вычисления цифровой подписи, симметричный ключ шифрования при этом не формируется. Соответственно при проверке также симметричный ключ не формируется. При вычислении цифровой подписи генерируется случайное значение и половина выходного значения подписи - именно это случайное значение, вторая половина - некое проверочное значение, полученное из хеша, случайного значения и частей закрытого ключа. При проверке снова вычисляется хэш данных, и с помощью частей открытого ключа плюс случайного значения в одной половине значения подписи вычисляется проверочное значение, которое должно совпасть со второй половиной подписи. Отредактировано пользователем 18 марта 2020 г. 5:39:58(UTC)
| Причина: Не указана
|
