асимметричная криптография не требует сертификатов с центральной подписывальней, можно

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

DH подвержено MitM без подписания.

Тебе в любом случае надо как-то валидировать что сервер - твой, а не MitM

Как понимаю схема следующая.

Клиент генерирует пару своих ключей, и отправляет публичный серверу, сервер подписывает своим приватником публичный ключ клиента и отправляет обратно. Клиент может проверить сигнатуру имея публичный ключ сервера и сопоставить пайлоад со своим публичным ключём

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

Client.SendToServer(Encrypt(key: PublicKeyServer, payload: PublicKeyClient))
Server.ResponseToClient(payload: PublicKeyClient + Sign(key: PrivateKeyServer, payload: PublicKeyClient))
Client.Verify(key: PublicKeyServer, payload: PublicKeyClient, sign: Sign)

А дальше уже асимметричное шифрование, двух участников знаящих паблики друг-друга

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

Любое сколько-нибудь безопасное приложение с сервером как раз так и устроено. Даже если там https простой, с удостоверенным сертификатом — то всё равно конкретный ключ лучше прибить гвоздями, чтобы давление на CA не позволило условному китайскому правительству перехватывать соединение.
Даже браузер Хром так делает для гугловых доменов, кстати

Нет канала связи, везде враги. Есть только код клиента в который захардкожены айпишки серваков и их паблики, ни доменных имён, ни сертификатов

В общем, делать так можно, если ты будешь очень-очень аккуратен.
Я бы посоветовал взять любую TLS1.3 (не раньше) либу, и в ней запинить ключ и набор шифров поновее для твоего сервера

Ну, я предполагаю что сертификаты есть, просто доверенным центром не подписаны

А можешь чуть побольше контекста дать, что за сервера, что за протокол?

смотри. айпишники захардкожены. значит канал есть - средство доставки приложения. захардкодь туда сертификат рутовый и всё

А то может для тебя и TLS это оверкилл, и тебе достаточно noise просто воткнуть? Там вопрос доверия ключам как раз вынесен из протокола, и никаких CA вообще нет

Сделаю умный вид что я понял о чём речь)

В само приложение? Не совсем понял про канал

ну если ты доверяешь что приложение доедет до пользователя с верным адресом, то ты можешь доверить что оно доедет и с неизменным рутовым сертификатом

Ну, есть такой протокол transport level security, TLS.
Это именно он обеспечивает буковку S в https.
Он в общем нормальный, выстраданный криптопротокол — но сложный и тяжеловесный.
Если у тебя вдруг не хттп-апи там, а какие-нибудь кастомные клиенты с бинарным протоколом — стоит взять более простой (и от этого более надёжный/быстрый) протокол шифрования, который называется noise

TCP, с бинарными данными, если быть еще точнее то gRPC. Там из коробки есть TLS, но мне сертификаты показались избыточными, вот решил выяснить можно ли без них обойтись, если не использовать доменные имена и функцию отзыва центром

Если там какой-то из общепринятых gRPC сервер, то там TLS уже сделан скорее всего. Так что и нечего лезть.
Разбирайся как в твоей клиентской библиотеке делать certificate pinning и вперёд