LINUX.ORG.RU

Ответ на: комментарий от kto_tama

нетривиальный пароль ?

Да, как вариант. Тоже думал над тем, как держать баланс между длиной ключа и скоростью. Тут больше человеческий фактор.

Mirage1_ ()
Ответ на: комментарий от kto_tama

нетривиальный пароль ?

Никакой пароль не поможет - хоть простой, хоть нетривиальный! MitM перехватит и повторит любой пароль! Тут только шифрование всего обмена поможет.

sigurd ★★★★★ ()
Ответ на: комментарий от sigurd

Тут только шифрование всего обмена поможет.

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

Mirage1_ ()
Ответ на: комментарий от Mirage1_

Либо, асимметричное шифрование, но закрытый ключ тоже надо передавать.

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

token_polyak ★★ ()
Ответ на: комментарий от token_polyak

Но MitM подразумевает, что кроме возможности восстановления оригинального сообщения есть ещё возможность подделки сообщения. Вот этого и хотелось бы избежать. Ведь открытый-то ключ для «фейковых» блоков данных можно перехватить. Разумеется, если не погружаемся в декомпиляцию самого протокола/формата обмена.

Mirage1_ ()
Ответ на: комментарий от Mirage1_

Поэтому сообщения шифруются публичным ключём адресата *и* подписываются приватным ключём отправителя, а получатель проверяет подпись с помощью публичного ключа отправителя.

token_polyak ★★ ()
Ответ на: комментарий от sigurd

Тут только шифрование всего обмена поможет.

Я читал когда-то рекомендации ФСТЭК для таких систем и ГОСТы.

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

Mirage1_ ()
Ответ на: комментарий от Mirage1_

либо симметричное шифрование со сложным паролем

Всё уже придумано - dh для выработки общего секрета и остаётся только придумать механизм его согласования, чтобы исключить митм.

vvn_black ★★★★★ ()
Ответ на: комментарий от token_polyak

*и* подписываются приватным ключём отправителя

Теперь понятно. Пока не начал по шагам смотреть RSA, в теории не мог понять. Спасибо.

Mirage1_ ()
Ответ на: комментарий от vvn_black

и остаётся только придумать механизм его согласования

Который, следует заметить, тоже придуман, причем далеко не один.

token_polyak ★★ ()
Ответ на: комментарий от token_polyak

причем далеко не один.

Окей. Принцип я понял. Задача Core Wars - увлекательная, но очень уж головоломная.

Mirage1_ ()

Как обеспечивается защита от MitM для RPC-протоколов?

Кмк, вопрос не правильный. Потому что, правильный вопрос - как произвести аутентификацию вызывающей стороны и протокол тут уже вроде как и не причём.

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от vvn_black

аутентификацию вызывающей стороны

Канал связи считаем незащищённым. То есть, условный Wi-Fi. Вопрос сводится к шифрованию открытого протокола. Считаем, что протокол тоже не закрыт.

Mirage1_ ()
Ответ на: комментарий от vvn_black

Кмк, вопрос не правильный.

Как-то в 1990-е годы глянул на центральную теорему эллиптической криптографии (требовалось доказать её неразрешимость), и понял, что мне в этой сфере математики делать нечего. Даже не понял, как подступиться к этой теореме.

Mirage1_ ()
Ответ на: комментарий от slovazap

В локальной вдруг не работает HTTPS?

DH, в принципе, неплохой подход. Но... если нет закрытых ключей, для высоконагруженных RPC-сервисов это будет большой оверхед.

Mirage1_ ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей