CodeKnight & Dravos
CodeKnight
Привет, Дравос. Я тут набросал новое правило для файрвола, основанное на фрактальном анализе трафика. Хочешь посмотреть, сходится ли теория?
Dravos
Конечно, но сначала покажи мне точную матрицу паттернов и хеш-функцию, которую планируешь использовать. Если глубина рекурсии не будет степенью двойки, или базовый случай не будет детерминированным – всё пойдёт прахом. И не забудь проверить на утечки по боковым каналам; фрактал может выглядеть красиво, но и раскрыть намерения пользователя может, если не укрепить защиту.
CodeKnight
Вот минимальная, детерминированная структура, чтобы рекурсия была аккуратной:
Матрица шаблонов (4x4, глубина 4, то есть степень двойки):
```
1 0 1 0
0 1 0 1
1 0 1 0
0 1 0 1
```
Базовый случай: когда глубина равна нулю, возвращаешь скаляр 1 (детерминировано).
Хеш-функция: берешь объединенную бинарную строку матрицы, дополняешь до 256 бит и применяешь SHA‑256. Выход используется как ключ правила.
Побочный канал: я запускаю хеш в режиме постоянного времени и маскирую любые ветвления по времени; матрица никогда не выводится на печать, только хранится во временном буфере. Дай знать, если потребуется более глубокий уровень или другой хеш.
Dravos
Вот перевод:
"Матрица - идеальная шахматная доска, поэтому каждый рекурсивный шаг просто воспроизведет один и тот же узор; глубина не добавляет энтропии. SHA‑256 на 256-битной паддинговой строке сойдет, но в итоге ты получишь один и тот же хеш для всех случаев, если не инициализировать буфер уникальными данными для каждого пакета. Константное время хеширования - это хорошо, но не забудь про ветвление в шаге XOR при объединении двух половин – это еще одна потенциальная утечка, если не проследишь. Если тебе нужна настоящая фрактальная сложность, введи нелинейное преобразование на каждом слое рекурсии. В текущем виде у тебя получится предсказуемый ключ, который любой атакующий сможет перебором взломать, используя один и тот же вход.
CodeKnight
Ты прав насчёт шахматной доски – это плохой корень проблемы. Я переделаю рекурсию, чтобы добавить нелинейный шаг: после каждого деления буду складывать половинки по-битовому, а потом применю простую, детерминированную S-box замену, чтобы перетасовать биты. Это даст хешу небольшой прирост псевдоэнтропии, но сохранит глубину степенью двойки. Для уникального семени на каждый пакет возьму 64-битный штамп времени пакета плюс счётчик, прогоню это через SHA-256, а потом XOR-ну в матрицу перед рекурсивным хешем. Это должно закрыть утечку ветвления, и XOR будет в плотном цикле без условных переходов. Скажи, если заметишь что-то упущенное.
Dravos
Звучит лучше, но S-box всё равно вводит фиксированное соответствие. Если нападающий его узнает, он сможет перевернуть его с помощью таблицы поиска; лучше использовать блочный шифр с ключом в режиме ECB для перемешивания. XOR timestamp+счетчик – нормально, но убедись, что счетчик переполняется с безопасной скоростью; 64-битный счетчик продержится долго, но если система перезагрузится, один и тот же счетчик может повториться. И ещё, следи, чтобы глубина рекурсии не выявила уязвимость padding oracle через длину финального хеша; поддерживай постоянную длину вывода в 256 бит. Если исправишь это, правило должно сработать.
CodeKnight
Да, переходим на небольшой 128-битный блочный шифр в режиме ECB для этапа шифрования – это закроет эту часть. Ключ буду получать из мастер-секрета, чтобы его нельзя было угадать. Установлю счетчик, чтобы он переносился после 2 в степени 48 пакетов, и сохраню последнее значение в энергонезависимой памяти, чтобы после перезагрузки он сохранился. Итоговый SHA-256 всегда будет 256 бит, без всяких ухищрений с дополнением. Прогоню патч через быструю проверку на побочные каналы – и все готово.
Dravos
Отлично, но помни, что ECB – режим слабый, если размер блока повторяется. Если счетчик переполнится после 2 в 48-й степени, рано или поздно ты увидишь один и тот же 128-битный блок, и повторение XOR-матрицы может быть обнаружено. Подумай о CTR или потоковом шифровании для этой операции. И храни главный ключ в защищенной среде; одна тайна – это одна уязвимость. И сделай аудит побочных каналов максимально полным – время вычисления ключа так же опасно, как и сам XOR. В целом, выглядит так, что ты движешься в правильном направлении.
CodeKnight
Понял. Переключаюсь на режим CTR, чтобы блок не повторялся, вытащу мастер-ключ из анклава и переделаю алгоритм генерации ключей, чтобы он работал за постоянное время. Запилю новый аудит, как только это будет сделано. Спасибо, что обратил внимание.
Dravos
Кажется, ты затягиваешь сеть. Только убедись, что убежище не станет узким местом, и не оставляй контрмеры в открытых логах – любой сможет использовать это, чтобы засечь твои пакеты. Удачи, и проводи проверки так же тщательно, как сама директива.