Всем привет, снова наступило то самое время недели

  • Index
  1. squid/www/cvs/dev.i2p восстановлено 2) Тестирование SSU 3) криптография I2CP 4) ???
    1. squid/www/cvs/dev.i2p restored

После долгих мучений с несколькими серверами в колокации, часть старых сервисов была восстановлена - squid.i2p (один из двух стандартных outproxies (выходных прокси) по умолчанию), www.i2p (защищённая ссылка на www.i2p.net), dev.i2p (защищённая ссылка на dev.i2p.net, где находятся архивы списков рассылки, cvsweb и стандартные netDb seeds), и cvs.i2p (защищённая ссылка на наш сервер CVS - cvs.i2p.net:2401). Мой блог всё ещё недоступен, но его содержимое всё равно было потеряно, так что рано или поздно придётся начать с нуля. Теперь, когда эти сервисы снова стабильно работают в сети, пора переходить к …

    1. SSU testing

Как упомянуто в том маленьком жёлтом блоке на консоли router (маршрутизатор) у каждого, мы начали следующий раунд тестирования в реальной сети для SSU. Эти тесты подходят не всем, но если вы готовы к экспериментам и уверенно справляетесь с ручной настройкой, изучите подробности, на которые дана ссылка на вашей консоли router (http://localhost:7657/index.jsp). Возможно, будет несколько раундов тестирования, но я не предвижу каких-либо существенных изменений в SSU до релиза 0.6 (в 0.6.1 будет добавлена поддержка для тех, кто не может пробросить свои порты или иным образом принимать входящие UDP-соединения).

    1. I2CP crypto

Снова работая над новой вводной документацией, мне сложно обосновать дополнительный слой шифрования, реализованный внутри I2CP SDK. Первоначальной целью криптографического слоя I2CP было обеспечить базовую сквозную защиту передаваемых сообщений, а также позволить клиентам I2CP (aka I2PTunnel, the SAM bridge, I2Phex, azneti2p, etc) обмениваться данными через недоверенные routers. Однако по мере развития реализации сквозная защита на уровне I2CP стала избыточной, поскольку router шифрует все клиентские сообщения сквозным образом внутри garlic messages (сообщения типа garlic), включая leaseSet отправителя и иногда сообщение о статусе доставки. Этот garlic слой уже обеспечивает сквозное шифрование от router отправителя к router получателя - единственное отличие в том, что это не защищает от ситуации, когда сам router является враждебным.

Однако, если посмотреть на предвидимые варианты использования, мне не удаётся придумать обоснованный сценарий, в котором локальному router нельзя было бы доверять. Как минимум, криптография I2CP скрывает только содержимое сообщения, передаваемого от router - router всё равно должен знать, на какой destination (адрес назначения в I2P) его отправить. При необходимости мы можем добавить SSH/SSL I2CP listener, чтобы I2CP client и router могли работать на отдельных машинах, или тем, кому это требуется, можно воспользоваться существующими средствами туннелирования.

Для повторения: в настоящее время используются следующие уровни криптографической защиты:

  • Сквозной уровень ElGamal/AES+SessionTag в I2CP, шифрующий от Destination отправителя (идентификатор назначения в I2P) до Destination получателя.
  • Сквозной слой garlic encryption router (ElGamal/AES+SessionTag), шифрующий от router отправителя до router получателя.
  • Уровень шифрования tunnel как для входящих, так и для исходящих tunnel на промежуточных узлах каждого из них (но не между конечной точкой исходящего tunnel и входным шлюзом).
  • Уровень транспортного шифрования между каждым router.

Я хочу проявлять достаточную осторожность при отказе от одного из этих уровней, но не хочу тратить наши ресурсы на ненужную работу. Я предлагаю отказаться от первого уровня шифрования I2CP (но, разумеется, сохранить аутентификацию, используемую при установлении сеанса I2CP, авторизацию leaseSet и аутентификацию отправителя). Может кто-нибудь привести причину, по которой нам следует его сохранить?

    1. ???

На данный момент это, пожалуй, всё, но, как всегда, много всего происходит. На этой неделе встречи по‑прежнему не будет, но если у кого‑то есть что обсудить, пожалуйста, не стесняйтесь написать в рассылку или на форум. Кроме того, хотя я и читаю скроллбек (историю сообщений) в #i2p, общие вопросы или замечания лучше отправлять в рассылку, чтобы больше людей могли принять участие в обсуждении.

=jr