Previous Entry Share Next Entry
Asymmetric encryption
victor_sudakov
Что-то непонятное мне написано в курсе CCNA про сабж.

Public key encryption is a variant of asymmetric encryption that uses a combination of a private key and a public key. The recipient gives a public key to any sender with whom the recipient wants to communicate. The sender uses a private key that is combined with the public key of the recipient to encrypt the message. Also, the sender must share its public key with the recipient. To decrypt a message, the recipient will use the public key of the sender with its own private key.

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

Или таки нужен, и как-то присутствует внутри сообщения в неявном виде?

UPD и это звучит странно:

The sender uses a private key that is combined with the public key of the recipient to encrypt the message.

Когда я отправляю кому-то PGP сообщение (только зашифрованное, не подписанное мной), то пароль от моего приватного ключа gnupg не спрашивает, значит мой приватный ключ в процессе вроде бы не участвует.

Оригинал сообщения находится по адресу https://victor-sudakov.dreamwidth.org/446749.html. Пожалуйста оставляйте комментарии там. Всего сейчас comment count unavailable комментариев.

  • 1

Re: Диффи-Хельман вместо асимметричного шифрования

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

    * вы знаете долгоживущий Диффи-Хельман ключ получателя: DHBobPub
    * генерируете эфемерную (сессионную) ключевую пару Диффи-Хельмана:
      DHAlicePriv, DHAlicePub = DHGenerate()
    * выполняете алгоритм DH для выработки сессионного симметричного
      ключа: K = DH(DHAlicePriv, DHBobPub)
      Подчеркну: как-раз именно в нём участвует *ваш* приватный и *их*
      публичный ключ. Аналогично, если сделать тоже самое на
      противоположной стороне (только с *нашим* публичным ключом и
      *ихним* приватным), то их результат работы DH() будет такой же
    * шифруете сообщение: Menc = AESEncrypt(K, M)
    * отправляете получателю: DHAlicePub, Menc
    * получатель делает следующее:
      K = DH(DHBobPriv, DHAlivePub)
      M = AESDecrypt(K, M)

То есть, да -- вы явно передаёте свой *эфемерный* публичный ключ. Можно
использовать и долгоживущие, но это не обязательно и скорее всего даже
может навредить. Поэтому иметь ключевую пару вам не обязательно для
отправки зашифрованного сообщения, но она будет сгенерированна
эфемерная, временная, только для этого сообщения и передана вместе с ним.

Это здорово тем, что исчезает целый криптографический примитив. Алгоритм
согласования ключей (Диффи-Хельман) используется почти всегда (в OpenPGP
это не так, но это действительно архаичный стандарт (но не хочу сказать
что не работающий), сейчас так не делают) и поэтому можно считать что он
априори будет. А раз он есть, то бесполезным становится асимметричное
шифрование. Это всё упрощает, делает более надёжным.

Более того, если вы используете долгоживущие ключи Диффи-Хельмана, то их
можно использовать и для аутентификации собеседника, так как факт
успешного согласования ключей уже говорит о том, что противоположная
сторона знает приватный ключ. Например вы хотите аутентифицировать
сервер (Bob), зная его публичный ключ DHBobPub и хотите согласовать с
ним эфемерный ключ, для PFS свойства, чтобы компрометация DHBob ключа не
была страшна (очень грубый пример):

    * вы знаете DHBobPub
    * генерируете свою эфемерную DH пару:
      DHAliceEphPrv, DHAliceEphPub = DHGenerate()
    * подключаетесь к Bob и отсылаете свой эфемерный ключ: DHAliceEphPub
    * Bob делает следующее:
      DHBobEphPrv, DHBobEphPub = DHGenerate()
      K1 = DH(DHBobPrv, DHAliceEphPub)
      K2 = DH(DHBobEphPrv, DHAliceEphPub)
      Kencryption, Kauthentication = HASH(K1 || K2)
      Mauth = MACAuthenticate(Kauthentication, HASH(DHAliceEphPub || DHBobEphPub))
    * Bob отсылает: DHBobEphPub, Mauth
    * Alice делает следующее:
      K1 = DH(DHAliceEphPrv, DHBobPub))
      K2 = DH(DHAliceEphPrv, DHBobEphPub)
      Kencryption, Kauthentication = HASH(K1 || K2)
      MACVerify(Kauthentication, HASH(DHAliceEphPub || DHBobEphPub), Mauth)
    * Kencryption они дальше могут использовать для шифрования (как и
      Kauthentication для аутентификации сообщений)

Можно делать "тройной" Диффи-Хельман с эфемерными ключами и двумя
долгоживущими ключами для аутентификации обеих сторон. Плюс этого
подхода в том, что теперь вообще не нужна асимметричная подпись. Но
подобные протоколы конечно же можно использовать только при
online-коммуникации, так как ключи надо согласовать чтобы хотя бы одно
сообщение с полезной нагрузкой отправить. Но по факту, опять же,
протоколы типа Noise, TLS 1.3, Signal -- подписи либо не используют,
либо только для сертификатов.

Повторюсь: асимметричное шифрование сейчас не используют (если не
какая-нибудь старая система где есть только RSA например), так как нет
смысла и каких-либо плюсов, так как алгоритмы согласования ключей в
любом случае будут и они полностью заменяют в этой задаче их. OpenPGP с
curve25519 ключевой парой именно так и делает: действительно встраивает
эфемерную curve25519 Диффи-Хельман пару в сообщение. CCNA действительно
очень точно описало как используются ключевые пары. OpenPGP архаичен в
этом плане и современные системы так бы больше не делались :-)


  • 1
?

Log in

No account? Create an account