Подтверждение личности в асимметрично зашифрованном сообщении

Предположим такой сценарий. Человек А будет транслировать свой открытый ключ и человека Б будет транслировать свой открытый ключ. Теперь они могут общаться. Но допустим, что вдруг другой человек С напишу человеку А олицетворение человека Б. Как человек может Б доказать свою личность. Мы можем реализовать подпись система. Человек А сгенерирует определенную подпись и передаст ее человеку Б, чтобы всегда присоединять его к сообщению, адресованному человеку А и доказать личность таким образом, но все равно возникнет та же проблема. Как человек Б знает, что полученная подпись принадлежит человеку А. Есть ли способ доказать личность в такой системе.

Я пришел к выводу, что сам ответил на свой вопрос. Если человек А сгенерирует подпись для человека Б и отправить его с помощью лиц Б открытый ключ для его шифрования, только эти два человека будут знать секрет. Поэтому сейчас важно, чтобы человек Б всегда присоединяется к своей подписи, полученной от лица А. Чтобы идентифицировать получателя сообщения, мы используем открытый ключ, а чтобы идентифицировать человека, от которого мы получили сообщения, мы используем сгенерированную подпись. Таким образом, мы можем сопоставить открытый ключ с сгенерированной подписью один к одному. Благодаря комментарию микеро, я посмотрел на свой вопрос под другим углом. Кроме того, я приму во внимание алгоритмы, предложенные п-ратье при создании системы обмена ключами.

Когда вы предполагаете, что C действует как противник, подслушивает и способен создавать сообщения на основе полученной информации, вам нужно тщательно разрабатывать свой протокол. Это происходит из-за того, что C потенциально может ретранслировать, воспроизводить и создавать сообщения. Следовательно, вам необходимо предотвращать повторные атаки и атаки «человек посередине», а также обрабатывать несколько (одновременных) сеансов протокола. Вы уже поняли, что статической подписи может быть недостаточно. По сути, ваша проблема заключается в мотивации протоколов аутентификации, и их дизайн нетривиален: если вы посмотрите на протокол Нидхэма-Шредера 1 или протокол Ву-Лама 2 вы увидите, что непредвиденные векторы атаки могут нарушить ваш протокол, поскольку оба примера небезопасны в своих исходных версиях.

В основном, некоторые лучшие практики для разработки безопасного протокола:

• Сделать максимально пессимистическое предположение
• Поместите отправителя и получателя в сообщения (т.е. их открытые ключи)
• Используйте шифрование, чтобы гарантировать, что только правильный получатель может прочитать содержимое
• Используйте одноразовые номера / временные метки, чтобы получить свежесть
• Создавайте одноразовые номера самостоятельно, чтобы предотвратить повторные атаки
• Всегда подписывать и шифровать компоненты вместе

Но все же: есть протоколы, считающиеся безопасными, которые не следуют всем пунктам, и небезопасные протоколы, которые соблюдают. В любом случае вы хотели бы проанализировать свой протокол (полуавтоматически), используя, например, проверку модели или доказательство теоремы.