Peter> В любом случае, описанные атаки, не совсем атаки. Так как любая нода может забрать netmail если она доверена.

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

Peter> Доверенность подтверждается ЭЦП. Так что я не понял суть твоего примера до конца. Если я доверяю твоей ноде, и убеждаюсь с помощью ЭЦП в аутентичности твоих запросов, почему бы мне и не слить тебе netmail?

Мы совершенно про разные вещи говорим. При схеме

                      abcde
                        |
нода1(from) > нода2 > нода3 > syscall (to)

нода 2 может организовывать атаку MITM, подменяя части сообщений. Например, подменив адрес получателя, она может добиться того, что нода3 отправит сообщение не получателю syscall, а левой ноде abcde. А если она подменит адрес отправителя, то может сама отлавливать чужую почту. Поэтому схемы без шифрования обречены на провал.

Возвращаясь к полю адреса, мы уже высказывали когда-то идею, что в поле адреса можно вписывать открытый ключ или ID этого ключа (неважно, для станции или для самого человека). При этом ЭЦП должна применяться не только для текста сообщения, но и для этого самого поля адреса, чтобы остальные ноды во время синхронизации не смогли подделать "обратный адрес" следования.

И теперь насчёт того, делать шифрование + ЭЦП на ноде или на клиенте.

1. На клиенте
+ не надо доверять сисопам
+ не надо сильно переделывать код станций
+ юзверь может получить свою почту с любой станции, с какой захочет
- надо совершенствовать клиенты
- нужен актуальный keystore для базы данных поинтов

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