
Я читал о генерации двух ключей (закрытого и открытого) на клиентском хосте и копировании открытого ключа на серверный хост.
Насколько я понимаю (поправьте меня, если я ошибаюсь): сервер шифрует данные открытым ключом и отправляет их клиенту, клиент расшифровывает их закрытым ключом.
Но если мне нужно зашифровать данные на клиенте для отправки на сервер, как это сделать?
Открытый ключ шифрует данные на клиенте? Но как сервер может их расшифровать, если у него есть только открытый ключ?
Как работает SSH-шифрование?
решение1
Первым делом после установления TCP-соединения обе системы договариваются осеансовый ключ, используя такие протоколы какОбмен ключами DH,ECDHили GSSAPI. Этот ключ симметричен и временен — обе стороны используют один и тот же ключ для шифрования и дешифрования данных с использованием таких алгоритмов, какАЕСилиRC4.
Пара ключей клиента никогда не используется для шифрования данных, только дляаутентификация– "publickey" – один из нескольких доступных методов, где клиент представляет свой собственный открытый ключ вместе с доказательством владения закрытым ключом. Аналогично, пара ключей сервера используется только для аутентификации сервера во время обмена ключами DH или ECDH; никакие данные не шифруются с ее помощью.
Протокол SSH2 задокументирован внесколько RFC, включая:
- RFC 4253 – Протокол транспортного уровня Secure Shell (SSH)
- Запрос на изменение 4419– Группа обмена Диффи-Хеллмана
- RFC4432– Обмен ключами RSA
- RFC4462– Аутентификация GSSAPI и обмен ключами
решение2
Первое, что, я думаю, вам нужно понять, это то, что, хотя многие протоколы шифрования, такие как SSH и SSL, используют PKI для аутентификации, почти ни одна из этих систем не будет использовать PKI для фактической передачи полезной нагрузки.
PKI слишком загружает процессор, чтобы использовать его для передачи фактических данных полезной нагрузки. Происходит следующее: PKI используется для согласования случайно сгенерированного ключа, который будет использоваться с симметричным протоколом шифрования. Протокол, который будет использоваться, также согласовывается и должен быть самым сильным протоколом, о котором могут договориться две системы. Поэтому после того, как первоначальное рукопожатие и согласование выполнены, практически все представляет собой просто стандартную симметричную криптографию.
решение3
Вот несколько практических примеров. Предположим, что ключ A хранился в секрете и поэтому является закрытым ключом, а ключ B был размещен в общедоступном месте и поэтому является открытым ключом.
Итак, если вы хотите отправить сообщение всем и хотите, чтобы они убедились, что оно пришло от вас и не было изменено во время доставки, вы отправляете свое сообщение и включаете хэш сообщения, зашифрованный с помощью ключа A. Затем любой, у кого есть ключ B, может расшифровать хэш, сравнить его с полученным сообщением и убедиться, что сообщение пришло от вас (поскольку только человек с ключом A мог сгенерировать зашифрованную полезную нагрузку, которая успешно расшифровала хэш, и поскольку вы единственный человек с ключом A, сообщение могло прийти только от вас).Это называется Подписание..
Теперь предположим, что кто-то хочет отправить вам секретное сообщение, но не хочет раскрывать, кто он. Он может зашифровать свое сообщение симметричным ключом (как упомянул Zoredache, симметричный ключ гораздо дешевле), затем взять этот ключ, зашифровать его с помощью ключа B и отправить его вам. Поскольку только ключ A может расшифровать то, что было зашифровано с помощью ключа B, никто другой не сможет увидеть, что находится в сообщении, которое было отправлено вам. Вот как работает обычное шифрование и как SSH обменивается данными.
решение4
ты пишешь
«Открытый ключ шифрует данные на клиенте? Но как сервер может их расшифровать, если у него есть только открытый ключ?»
Я не так уж много знаю об этом, но думаю, что могу ответить на этот вопрос достаточно ясно.
Если A хочет отправить сообщение B, A использует открытый ключ B. Таким образом B может его расшифровать.
Если бы А использовал свой собственный открытый ключ для шифрования сообщения, то Б действительно не смог бы его расшифровать.
Это объясняется здесь.
http://www.comodo.com/resources/small-business/digital-certificates2.php