Привет, народ, снова настало то самое время недели,
- Index
- Статус разработки 2) Векторы инициализации Tunnel 3) MAC-коды SSU 4) ???
- Dev status
Ещё одна неделя — ещё одно сообщение: «Есть значительный прогресс по транспорту SSU» ;) Мои локальные изменения стабильны и отправлены в CVS (HEAD сейчас на 0.5.0.7-9), но релиза пока нет. Скоро будут новости на этом фронте. Подробности по изменениям, не связанным с SSU, есть в истории [1], хотя я пока не включаю изменения, связанные с SSU, в тот список, так как SSU ещё не используется никем, кроме разработчиков (а разработчики читают i2p-cvs@ :)
[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
- Tunnel IVs
За последние несколько дней dvorak время от времени публиковал мысли о разных способах атаковать шифрование tunnel, и хотя большинство из них уже было разобрано, нам удалось придумать один сценарий, который позволил бы участникам помечать пару сообщений, чтобы определить, что они находятся в одном и том же tunnel. Работало это так: более ранний узел пропускал мимо себя сообщение, а позднее подменял в новом сообщении IV (инициализационный вектор) и первый блок данных, заменяя их на взятые из того первого сообщения tunnel. Новое сообщение, разумеется, было бы испорчено, но оно не выглядело бы как повторная передача (replay), поскольку IV были разными. Дальше по цепочке второй узел мог бы просто отбросить это сообщение, чтобы конечная точка tunnel не смогла обнаружить атаку.
Одна из ключевых проблем здесь в том, что нет способов проверять сообщение tunnel по мере его прохождения по tunnel, не открывая целый ряд атак (см. более раннее предложение по криптографии tunnel [2] с одним методом, который близок к решению, но имеет довольно сомнительные вероятностные оценки и накладывает некоторые искусственные ограничения на tunnels).
[2] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD
Тем не менее, существует тривиальный способ обойти описанную атаку — просто рассматривать xor(IV, first data block) как уникальный идентификатор, подаваемый в фильтр Блума, вместо одного лишь IV (вектора инициализации). Таким образом, промежуточные пиры увидят дубликат и отбросят его до того, как он достигнет второго сговаривающегося пира. CVS уже обновлён, чтобы включить эту защиту, хотя я очень-очень сомневаюсь, что это практическая угроза при текущем размере сети, поэтому я не собираюсь выпускать это как отдельный релиз.
This doesn’t affect the viability of other timing or shaping attacks however, but its best to clear up the easy to handle attacks when we see ’em.
- SSU MACs
Как описано в спецификации [3], транспорт SSU использует MAC (код аутентификации сообщения) для каждой передаваемой датаграммы. Это дополняет проверочный хеш, отправляемый с каждым сообщением I2NP (а также сквозные проверочные хеши в клиентских сообщениях). Сейчас спецификация и код используют усеченный HMAC-SHA256 — передаются и проверяются только первые 16 байт MAC. Это, кхм, несколько расточительно, так как HMAC использует хеш SHA256 дважды, каждый раз работая с 32-байтным хешем, и недавнее профилирование транспорта SSU показывает, что это находится близко к критическому пути для нагрузки на CPU. В связи с этим я немного поэкспериментировал с заменой HMAC-SHA256-128 на обычный HMAC-MD5(-128) — хотя MD5 явно не так силен, как SHA256, мы все равно усекаем SHA256 до того же размера, что и MD5, так что объем перебора, необходимый для коллизии, тот же (2^64 попыток). Сейчас я с этим экспериментирую, и ускорение существенно (пропускная способность HMAC на пакетах 2KB более чем в 3 раза выше, чем с SHA256), так что, возможно, мы перейдем на это. Или, если кто-то сможет привести вескую причину этого не делать (или предложить лучшую альтернативу), заменить достаточно просто (всего одна строка кода).
[3] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD
- ???
На данный момент это, пожалуй, всё, и, как всегда, не стесняйтесь в любое время публиковать свои мысли и замечания. CVS HEAD снова собирается для тех, у кого не установлен junit (пока что я вынес тесты из i2p.jar, но их всё ещё можно запускать с целью ant test), и я ожидаю, что довольно скоро появятся новые новости о тестировании 0.6 (я всё ещё борюсь со странностями colo box (сервер в colocation-центре) — подключение по telnet к собственным интерфейсам локально завершается неудачей (без какого-либо внятного errno), а удалённо — работает, и всё это без каких-либо iptables или других фильтров. прелесть). Дома у меня всё ещё нет доступа в сеть, так что на сегодняшней встрече меня не будет, возможно, на следующей неделе.
=jr