https://www.opennet.ru/openforum/vsluhforumID3/139809.html Состоялся релиз библиотеки OpenSSL 4.0.0, предлагающей с реализацию протоколов TLS и различных алгоритмов шифрования. OpenSSL 4.0 отнесён к выпускам с обычным сроком поддержки, обновления для которых выпускаются в течение 13 месяцев. Поддержка прошлых веток OpenSSL 3.6, 3.5 LTS, 3.4 и 3.0 LTS продлится до ноября 2026 года, апреля 2030 года, октября 2026 года и сентября 2026 года соответственно. Код проекта распространяется под лицензией Apache 2.0...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65208<br> https://www.opennet.ru/openforum/vsluhforumID3/139809.html#89 Sun, 19 Apr 2026 16:30:01 GMT Получается примерно так:<br><br>seeds генерируются через NewSeed{128,256,512} из crypto/rand при keyBits ≥ 512. Пространство состояний seed'а огромно (на 1024 битах это 2^1024 возможных значений), вероятность совпадения на раунд ≈ 2^-128, а на всю цепочку ChainHash ≈ 2^-125.<br><br>За всё обозримое время при любой разумной нагрузке такого не случится.<br><br>Вероятность события на раунд: 1 / 2^ширина (128 / 256 / 512 бит)<br><br>Если случилось: тот раунд выдаёт H(data, 0) &#8212; предсказуемую функцию от данных, теряет свойство случайности, при этом безопасность цепочки в целом сохраняется: следующий раунд подмешивает новый секретный s_{i+1} и восстанавливает непредсказуемость.<br><br>Атакующий не видит промежуточные h_i, не может определить факт совпадения и не может его спровоцировать, суммарная вероятность n &#215; 2^-ширина ≈ 2^-125 &#8212; на уровне шума самого crypto/rand<br><br>Это кстати известное явление "слабого ключа" в цепочках хеширования с ничтожно малой вероятностью. Не является дефектом конструкции и не является вект https://www.opennet.ru/openforum/vsluhforumID3/139809.html#88 Sun, 19 Apr 2026 13:15:44 GMT что будет если в ChainHash seed совпадет с предыдущим выходом хеша?<br><br>S = {s_0, s_1, s_2 ... s_n-1}, n = keyBits/w, w = {128&#124;256&#124;512}<br><br>h_0 = H(data, s_0)<br><br>h_a = H(data, s_1 XOR h_0)<br><br>....<br><br>ChainHash(data, S)<br> https://www.opennet.ru/openforum/vsluhforumID3/139809.html#87 Sat, 18 Apr 2026 13:08:09 GMT Привет. Автор выложил тестирование конструкции, можно скачать и потестить теперь, и я увидел в этой конструкции нелинейность, которой думал что там нет и она не нужна.<br><br>https://github.com/everanium/itb/blob/main/REDTEAM.md<br><br>Это если было бы обычно:<br><br> Over GF(2) (bit-level linear algebra &#8212; что важно для линейного cryptanalysis):<br> - XOR: линейно<br> - Shift/rotate: линейно (permutation бит)<br> - Integer multiplication *: нелинейно (carry bits между позициями)<br> - Integer addition +: нелинейно (тоже carry)<br><br>А у него вот это при его ChainHash:<br><br> Over Z/2^n (integer arithmetic mod 2^n):<br> - XOR: нелинейно в этой структуре<br> - Integer multiplication: линейно (distributes)<br> - Integer addition: линейно<br><br>Какой PRF... там FNV1a 128 бит 100% инвертируемый становится нелинейным, уже не развернешь просто так через его ChainHash, если не убрать CCA шум и еще startPixel неизвестен. Но кто же будет MAC Reject светить чтобы убрать CCA шум бит флипом. SAT задача в любом случае, даже если убрать всю ко https://www.opennet.ru/openforum/vsluhforumID3/139809.html#86 Fri, 17 Apr 2026 23:19:44 GMT ARIA? Нет, не слышал.<br> https://www.opennet.ru/openforum/vsluhforumID3/139809.html#85 Fri, 17 Apr 2026 11:24:01 GMT Ну вот пока не делишься - так и будешь форкать openssl сам.<br> https://www.opennet.ru/openforum/vsluhforumID3/139809.html#84 Fri, 17 Apr 2026 11:18:41 GMT 4.0? Опять API сломали? Да сколько ж можно-то, 1.1 жил вечность.<br> https://www.opennet.ru/openforum/vsluhforumID3/139809.html#83 Thu, 16 Apr 2026 16:14:07 GMT Не, я так не думаю, как раз triple-seed isolation то я впервые и увидел здесь и без него у него ничего бы не вышло, это не ратчет: Ratchet это последовательная эволюция ключа (key[n+1] = f(key[n]), forward secrecy). А там в ITB три ключа параллельны и статичны &#8212; это domain separation, не ратчет. Разные механизмы, разные цели.<br><br>Смотрите, если бы он не сделал эту изоляцию, тогда было бы примерно так:<br><br>Даже при Partial KPA, знаешь один байт, не знаешь соседний. Но без изоляции, noisePos известен, допустим утечка CCA, startPixel вообще можно игнорировать тогда, знаешь какие биты plaintext в каком канале хотя бы частично. Байтовый split больше не имеет смысла, маппинг уже известен. Для каналов где plaintext биты известны частично, уже сужается поиск кандидатов ротации. Каждый подтверждённый бит сужает еще дальше.<br><br>Подобрал ротацию, значит XOR mask раскрыта, значит PRF выход наблюдаем полностью. 100% сразу же на ладони и можно применять всю математику, все анализы и квантовые вычисления.<br><br>А с изоляцие https://www.opennet.ru/openforum/vsluhforumID3/139809.html#82 Thu, 16 Apr 2026 15:19:57 GMT &gt; Все разные.<br><br>все верно, потому-что нечетное количество битов.<br> https://www.opennet.ru/openforum/vsluhforumID3/139809.html#81 Thu, 16 Apr 2026 15:18:33 GMT &gt; И про шум и ротацию все равно не забываем, все это работает за счет triple-seed isolation в сумме, то есть оно связующее звено которого не хватало чтобы такая конструкция стала устойчивой впринципе. Каждый слой по отдельности недостаточен, но изоляция доменов делает их неразделимыми для атакующего.<br><br>Да все это давно уже известно, банальный механизм независимых ратчетов (ratchet). Я не вижу никакой новизны, кроме использования кодирования COBS (Consistent Overhead Byte Stuffing), и представления данных в виде мусорного контейнера с пикселями, все можно сделать куда проще.<br>