Вопрос теоретический по процессу подключения. В одной из статей есть такая иллюстрация, которая меня смущает. В ней указано, что после инициации соединения клиентом с сервера шлется челлендж, и клиент закрытым ключем должен его зашифровать, потом открытым ключем сообщение расшифровывается на стороне сервера, и если сообщение идентично начальному, аутентификация пройдена. Разве сообщение не должно шифроваться открытым ключем, а расшифровываться закрытым? Почему на картинке все наоборот?
На другом небезызвестном форуме мне ответили вот так:
Дальше были споры, но основной посыл (т.е. о смене ролей) не изменился.Потому что это не шифрование для отправки данных секретно, а подтверждение факта обладания приватным ключём. Оно работает, потому что оба ключа могут использоваться для шифрования и дешифрования (т.е. свободно меняться ролями; только приватный обычно короче поэтому его и скрывают, так как перебрать проще).
Сегодня я наткнулся на другую статью на том же портале что и первая (вероятно, того же автора), где *цитата*:
After the symmetrical encryption is established to secure communications between the server and client, the client must authenticate to be allowed access. The server can use the public key in this file to encrypt a challenge message to the client. If the client can prove that it was able to decrypt this message, it has demonstrated that it owns the associated private key. The server then can set up the environment for the client.
Т.е. в данном случае сервер уже шифрованный челлендж шлет, и клиент приватным ключем его расшифровывает (что выглядит логичней чем смена ролей). Так что же все таки происходит на самом деле? И о какой смене ролей идет речь, если одна из основных черт асимметричного шифрования в том, чтобы ключи не менялись ролями, и одним ключем можно было только зашифровывать, а другим - расшифровывать. Иначе это будет симметричное шифрование с общим секретом, разве нет?
P.S. в интернетах видел кучу таких картинок, где при аутентификации по ключу сервер в последствии расшифровывает открытым ключем зашифрованный на клиенте приватным ключем челлендж, например https://vmcentral.zendesk.com/hc/en-us/arti...key_based_2.png.
