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

  • Index
  1. Статус сети 2) _PRE прогресс сети 3) I2Phex 0.1.1.37 4) ???
    1. Net status

За последнюю неделю в основной сети не произошло существенных изменений, поэтому статус основной сети почти не изменился. С другой стороны…

    1. _PRE net progress

На прошлой неделе я начал вносить обратно несовместимый код для релиза 0.6.1.10 в отдельную ветку в CVS (i2p_0_6_1_10_PRE), и группа добровольцев помогла это протестировать. Эта новая сеть _PRE не может взаимодействовать с основной сетью и не обеспечивает сколь‑нибудь значимой анонимности (поскольку в ней менее 10 пиров). Используя журналы pen register (реестр соединений) с тех routers, удалось отследить и устранить несколько существенных ошибок как в новом, так и в старом коде, хотя дальнейшее тестирование и улучшение продолжаются.

Один аспект новой криптографии создания tunnel состоит в том, что создатель должен заранее выполнить ресурсоёмкое асимметричное шифрование для каждого хопа, тогда как старый механизм создания tunnel выполнял шифрование только если предыдущий хоп соглашался участвовать в tunnel. Это шифрование может занимать 400-1000 мс или больше, в зависимости как от производительности локального CPU, так и от длины tunnel (выполняется полное шифрование ElGamal для каждого хопа). Одна оптимизация, которая сейчас используется в _PRE net, заключается в использовании короткой экспоненты [1] - вместо использования 2048-битного ‘x’ в качестве ключа ElGamal мы используем 228-битный ‘x’, что является рекомендуемой длиной, соответствующей сложности задачи дискретного логарифма. Это снизило время шифрования на каждый хоп на порядок, однако не влияет на время расшифрования.

Существует множество противоречивых взглядов на использование коротких экспонент, и в общем случае это небезопасно, но, насколько я смог разобраться, поскольку мы используем фиксированное безопасное простое число (Oakley group 14 [2]), то порядок q не должен представлять проблемы. Если у кого-то есть дополнительные соображения в этом направлении, я бы с интересом услышал больше.

Единственная значимая альтернатива — перейти на 1024-битное шифрование (в рамках которого мы могли бы тогда использовать, возможно, 160-битную короткую экспоненту). Это может быть уместно в любом случае, и если с 2048-битным шифрованием на _PRE net всё окажется слишком проблематично, мы можем сделать этот переход внутри _PRE net. В противном случае мы можем подождать до релиза 0.6.1.10, когда новая криптография будет шире развернута, чтобы оценить, необходимо ли это. Гораздо больше информации будет предоставлено, если такой переход окажется вероятным.

[1] “О протоколе согласования ключа Диффи — Хеллмана с короткими показателями степени” - van Oorschot, Weiner на EuroCrypt 96. зеркало на http://dev.i2p.net/~jrandom/Euro96-DH.ps [2] http://www.ietf.org/rfc/rfc3526.txt

В любом случае, в сети _PRE достигнут значительный прогресс, а большая часть общения по этому поводу ведётся в канале #i2p_pre на irc2p.

    1. I2Phex 0.1.1.37

Complication объединил и пропатчил актуальный код I2Phex, добавив поддержку gwebcaches, совместимую с портом pycache от Rawn. Это означает, что пользователи могут скачать I2Phex, установить его, нажать «Connect to the network», и через минуту‑другую он получит ссылки на существующих пиров I2Phex и выйдет в сеть. Больше никакой мороки с ручным управлением файлами i2phex.hosts или ручным обменом ключами (w00t)! По умолчанию предусмотрены два gwebcache, но их можно изменить или добавить третий, изменив свойства i2pGWebCache0, i2pGWebCache1 или i2pGWebCache2 в i2phex.cfg.

Отличная работа, Complication и Rawn!

    1. ???

Пожалуй, на этом пока всё, что, впрочем, к лучшему, ведь я уже опаздываю на встречу :) Скоро увидимся в #i2p

=jr