Безопасность в децентрализованных сетях. Как?

Может кто на пальцах объяснить, как в этом случае 2 человека из любой точки сети могут безопасно обменяться сообщениями? Или куда на эту тему можно почитать?

https://www.pgpru.com/biblioteka/osnovy/setjdoverija как вариант

в любом случае все сводится к тому что ключами надо обменяться по доверенному каналу

Может кто на пальцах объяснить, как в этом случае 2 человека из любой точки сети могут безопасно обменяться сообщениями?

они должны встретиться лично и обменяться ключами

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

если будет какой-то общий CA сети, то она получится не совсем децентрализованной.

Хм, странное заявление. То есть, когда 1к клиентов делают сertificate signing request за ssl-сертификатом, они тоже все централизованы?

Просто пользуйтесь доверенными сертификатами, тогда

Потому как один из узлов на пути может оказаться «товарищем майором»

Не станет особой проблемой.

но тут же как раз нужен сертификат. То есть его изначально нужно получить, а второй стороне нужно проверить, что он не уворован.

Если 2 узла как-то обменялись ключами вне сети, то вопросов нет.

когда 1к клиентов делают сertificate signing request за ssl-сертификатом, они тоже все централизованы?

Они делают это у довоенной 3 стороны, верно? И потом они могут проверить сертификат, например, через доверенный CA/CRL. И вот если их перекрыть, то не будет ни сертификатов, ни revocation list'ов. Так что они могут быть сами децентрализованны, но 3 сторона будет центром безопасности по-сути своей.

у довоенной 3 стороны

доверенной

все просто

нужен еще один «посредник»

ты отправляешь ключь «посреднику» посредник передает ключь твоему «клиенту»

очевидно что «ключь» передавать не в открытой форме а ф форме зашифрованного архива(к примеру),код к архиву приложив в «псевдошифровке» в прямом сообщении «клиенту»

тоесть банально:
у тебя прямое соеденение IP<->IP ты берешь ключь кладешь в архив zip с паролем и отправляешь по электронной почте «второму IP»,эл почта-гмаил или яндекс неважно,также напрямую передав пароль к архиву в псевдошифровке
второй-ип получат ключь расшифровывает и коннектится к тебе уже с шифрованием

и третий человек(это твой провайдер с фильтром по ключевым словам в трафике) сидит и видит бинарный поток и ключи не были переданы через провайдер(в открытом виде) поэтому автоматически нерасшифровать

...можно еще как уже сказали выше-через «видеозвонок» в реалтайме показывать хешсуммы ключей...много вариантов можно придумать

Окей, а вы разве можете сможете предложить другую схему контроля?

Оба клиента, потенциально, могут подменять. Вплоть до подмены друг друга :) И как тут без CA обойтись, чтобы быть уверенным наверняка?

Ну и «доверенный CA» является в этой схеме точно таким же звеном, как и клиент, поэтому, строго говоря, его нельзя назвать централизирующим.

Поздравляю, вы только что изобрели CA.

Окей, а вы разве можете сможете предложить другую схему контроля?

Увы :( Пока вижу, что все равно нужен будет как-то узел, который скажет, что сертификат «такой-то» невалиден, потому что украли.

Ну а вдруг что-то упустил.

Либо ноды впервые друг друга видят, и адрес и есть отпечаток открытого ключа, либо ноды уже знают друг друга и имеют общий секрет/отпечатки ключей друг у друга.

ох, и чего это я не заметил этого сообщения. Да, у меня была такая мысль (то то, что id и есть подпись публичного ключа) и ее сейчас думаю. Вот что получается.

* Клиент генерит пару ключей и получает id (sha2, как вариант) от открытого ключа.
* Другой клиент, зная id (например его сказали по телефону/на форуме/в письме), запрашивает открытый ключ.
* Проверяет то, что ключ реально принадлежит указанному id и может его использовать для шифрования мессаджа либо получения ключа для сессии.

далее получается почти красиво.

Нода может в любой момент добавить себе другой id (тобишь сгенерить новую пару), уничтожить id. Может задать «время жизни» для конкретного открытого ключа (тоже будет входить в открытую инфу, из которой получается id).

+ можно будет к паре добавить некий «пароль», без которого невозможно будет получить валидный id из открытой информации => проверить валидность узла. И не возможно будет раскрыть закрытое приватным/публичным ключом сообщение. Тогда помимо id, нужно будет знать еще и пароль.
Вот тут, как это правильно сделать, пока не придумал.

Есть какие-то явные косяки в схеме?