>В асимметричной два ключа: если что-то зашифровали одним, то дешифровать можно другим (и наоборот). Один из ключей называют приватным, а другой публичным. Отсюда возникает два варианта использования частых: если зашифровать сообщение приватным ключом и дешифровать публичным, то мы получаем функцию подписи (подписать может только владелец приватного, а проверить (дешифровать) может кто-угодно). Если зашифровать публичным, а дешифровать приватным, то мы получим асимметричное шифрование (отправить шифрованное сообщение может любой, а прочитать только владелец приватного ключа)Есть отправитель с ключами Priv и Pub, который передаёт сообщение M.
1) Функция crypt(M, Priv) = M_C1, M_C1 - шифрованное сообщение, но такое, что decrypt(M_C1, Pub) = M.
Успешная расшифровка публичным ключом Pub подтверждает факт того, что сообщение пришло именно от отправителя, а не кого-нибудь другого.
2) Функция crypt(M, Pub) = M_C2, M_C2 - такое шифрованное сообщение, что decrypt(M_C2, Priv) = M. [Тут вопрос, это те же самые функции, или сопряжённые с ними, допустим crypt2 и decrypt2?]
Если есть желание передать секретное сообщение человеку (получателю), отправитель берёт его публичный ключ, пропускает через crypt(M, Pub), и уже передаёт, в том числе и через посредников, шифрованное сообщение M_C2. Получатель делает decrypt(M_C2, Priv), у него же есть приватный ключ Priv, и может даже оформленный в сертификат, и читает секретное сообщение.
3) Приватный ключ Priv пользователя/клиента хранится в сертификате, выданным УЦ, вместе с дополнительный полями, такими как даты и время начала и конца действия этого сертификата. Сам сертификат подписан УЦ той же (а можно иной) функцией crypt. УЦ это такой большой мальчик, которому все верят, также предоставляет свой публичный ключ, оформленный в сертификат. А сертификат большого мальчика подписал, например его папа, а папе - товарищ из милиции и т.д.
Это и есть так называемая цепочка доверия в системах PKI?
Верим большим дядям с их сертификатам (и хранящимся в них публичным ключам), и по цепочке сверху вниз делаем decrypt(M_C1, Pub) , где M_C1 - сертификаты, которые проверяем и начинаем доверять, если всё в порядке.
>Однако в настоящих на практике используемых алгоритмах часто отсутствует шифрование как таковое и есть только создание подписи и проверка -- ECDSA, Ed25519, Ed448 алгоритмы например.
Кажется я уже начинаю понимать, можно не шифровать сам файл, а допустим его хэш (если предположить, что хэши уникальны для разных файлов). Получили хэш, пропустили его через криптофункцию и получили цифровую подпись: crypt(hash, Priv) = sign.
https://en.wikipedia.org/wiki/Electronic_signature#/media/Fi...
Тут меня смущает аналогия с обыкновенной подписью - цифровая подпись каждый раз разная для разных файлов. Куда больше на цифровой аналог рукописной подписи подходят именно приватные ключи (рукописная подпись не меняется, за исключением небольших вариаций и отклонений из-за непостоянства почерка). Но приватные ключи показывать не стоит. Да и в таких схемах (и в схеме с MACами) и не нужно.
>А Диффи-Хельман вообще не вписывается в эти примеры с шифрованием/дешифрованием, поэтому о нём часто умалчивают, чтобы не усложнять объяснение в чём отличие асимметричной криптографии от симметричной.
Идею DH я в целом понял - безопасно согласовать ключ (ну или передать сообщение в целом), когда есть посредник, который ещё по совместительству и злоумышленник. Буду пересматривать https://www.youtube.com/watch?v=F3zzNa42-tQ до просветления.
