Обзор
Это предложение касается модернизации транспорта NTCP для улучшения его устойчивости к автоматической идентификации.
Мотивация
Данные NTCP шифруются после первого сообщения (и первое сообщение выглядит как случайные данные), что предотвращает идентификацию протокола через “анализ полезной нагрузки”. Однако он все еще уязвим к идентификации протокола через “анализ потока”. Это связано с тем, что первые 4 сообщения (т.е. рукопожатие) имеют фиксированную длину (288, 304, 448 и 48 байт).
Добавив случайное количество случайных данных в каждое из сообщений, мы можем значительно усложнить задачу.
Изменения в NTCP
Это довольно тяжеловесно, но предотвращает обнаружение оборудованием DPI.
Следующие данные будут добавлены в конец 288-байтового сообщения 1:
- 514-байтовый блок, зашифрованный ElGamal
- Случайная подкладка
Блок ElG зашифрован на открытом ключе Боба. При расшифровке до 222 байт он содержит:
- 214 байт случайной подкладки
- 4 байта, зарезервированных под 0
- 2 байта длины подкладки следом
- 2 байта версии протокола и флагов
В сообщениях 2-4 последние два байта подкладки теперь будут указывать длину дополнительной подкладки.
Обратите внимание, что блок ElG не имеет совершенной прямой секретности, но там нет ничего интересного.
Мы могли бы модифицировать нашу библиотеку ElG так, чтобы она шифровала меньшие размеры данных, если считаем, что 514 байта это слишком много? Является ли шифрование ElG для каждой настройки NTCP слишком затратным?
Поддержка этого будет объявлена в netdb RouterAddress с опцией “version=2”. Если получено только 288 байт в сообщении 1, предполагается, что Алиса использует версию 1, и подкладка не отправляется в последующих сообщениях. Обратите внимание, что связь может быть заблокирована, если MITM фрагментирует IP до 288 байт (очень маловероятно согласно Брендону).