LINUX.ORG.RU

Последовательное применение алгоритмов шифрования с одним ключом.


0

1

Какие из свободных и хорошо известных алгоритмов шифрования, поддерживающих 256-битный ключ можно применять последовательно к тексту так, чтобы это не приводило к снижению криптостойкости зашифрованного сообщения. При этом предполагается применение одного и того же ключа. Интересует, в частности, возможность совместного применения алгоритмов AES, Serpent, Blowfish, HPC и ГОСТ.

★★★★★
Ответ на: комментарий от cdshines

а что ты хочешь? Он тут на коленке придумывает новый алгоритм шифрования. Наверное скоро увидим новый софт на секретных патентованных алгоритмах.

anonymous
()
Ответ на: комментарий от anonymous

Голосуйте за партию упоротых! Партия упоротых - dlog за O(1) уже завтра!

cdshines ★★★★★
()
Ответ на: комментарий от ziemin

А я про алгоритмы

Даже при условии нахождения некоторых не очень серьёзных уявимостей, даже при условии применения квантовых суперкомпьютеров, даже при условии открытия особых, хитрых способов упрощения вычисления функций внутри алгоритмов, всё равно, вдумайтесь: 2^256 = 1.15*10^77, 10 в 77 степени, это 100000000000000000000000000000000000000000000000000000000000000000000000000000 операций. При условии обратного преобразования наподобие xor, а у нас не xor, у нас двойной или тройной алгоритм шифрования. Даже если вы найдёте способ сократить время вычисления в 100 миллиардов раз, это будет не более чем капля в море, с точки зрения шансов на расшифровку сообщения.

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

Даже если вы найдёте способ сократить время вычисления в 100 миллиардов раз, это будет не более чем капля в море, с точки зрения шансов на расшифровку сообщения.

Ты всё про брут-форс, что ли? Уже ясно, что во многие современные алгоритмы протянулась рука АНБ. Спасибо Сноудену.

ziemin ★★
()
Ответ на: комментарий от next_time

да как с тобой можно рассуждать технически, если ты воспринимаешь два шифроалгоритма друг на друге, как два шифроалгоритма. А он один. Искать уязвимости тебе бесплатно никто не станет, так как это сложная работа. Зато есть истина: не изобретай шифроалгоритм, если в этом нифига не смыслишь.

Всё просто: хочешь два алгоритма — берёшь два независимых ключа. Длинный ключ? Берёшь один алгоритм и не паришь никому мозги.

anonymous
()
Ответ на: комментарий от ziemin

Ты всё про брут-форс, что ли?

суть в том, что любой метод расшифровки так или иначе содерржит в себе брутфорс, причём, чем хитрее метод расшифровки, например по известным парам шифртекст-сообщение, тем сложнее использовать выские мощности — с одной стороны, их вроде как меньше надо, но с другой, на длинных ключах, >128бит, они в любов случае потребуются, и тут же будет ой

Уже ясно, что во многие современные алгоритмы протянулась рука АНБ.

Не во все, это точно. Взять тот же ГОСТ, там вообще таблица замен может быть произвольной, фактически алгоритм можно менять на лету, а вот алгоритм расшифровки на лету уже не приспособишь. Да и blowfish — он настолько примитивен, что там тупо не может быть закладок.

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

суть в том, что любой метод расшифровки так или иначе содерржит в себе брутфорс, причём, чем хитрее метод расшифровки, например по известным парам шифртекст-сообщение, тем сложнее использовать выские мощности

Энигму сломали при трёх барабанах. В дистры включен по историческим причинам алгоритм, оперирующий 256. Никто и никогда не считал его серьёзным. Простое гаммирование. Основная проблема была в том, что бы немцы не сообразили, что шифр сломан.

ziemin ★★
()
Ответ на: комментарий от anonymous

А он один

Тред не читай, сразу отвечай. Я уже много раз об этом же тут отписался.

Искать уязвимости тебе бесплатно никто не станет, так как это сложная работа.

Почему мне? Я не первый и не последний кто до такого додумался. взгляните на True Crypt, хотя бы.

Зато есть истина: не изобретай шифроалгоритм, если в этом нифига не смыслишь.

А кто здесь собирался что-то изобретать? Как раз вопрос был о готовых решениях. Вы их знаете или нет? Вот Umberto по делу ответил, например, хотя бы ткнул, куда копать.

Всё просто: хочешь два алгоритма — берёшь два независимых ключа.

Ещё раз я хочу 2 алгоритма но с одним ключом. Решение в этом треде уже найдено: md5 сумма от исходного ключа для первого алгоритма, исходный ключ для второго алгоритма. Результирующая надёжность как минимум не меньше надёжности второго алгоритма.

Длинный ключ? Берёшь один алгоритм

Обоснование?

и не паришь никому мозги.

вы вообще анонимус. не нравится - проходите мимо, сюда вас никто не звал

next_time ★★★★★
() автор топика
Ответ на: комментарий от ziemin

Энигму сломали при трёх барабанах.

в алгоритме энигмы были сплошные уязвимые места, в те времена, криптография не была ещё развита, но даже так, расшифровка удалась только при наличии большого числа шифротекстов с доступной расшифровкой

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

Ты собираешься комбинировать давно известные алгортмы, тексты для которых может генерить любой человек в объёмах, на порядки превышающих всё переписку всех правительств до 1990г.

Или

будет открыто

ты уже передумал?

ziemin ★★
()
Ответ на: комментарий от next_time

Так вот, применение md5 суммы от основного ключа достаточно сильно устраняет вероятность уязвимости в результате «скрещивания» алгоритмов.

Тебе уже написали, что применение md5 добавляет коллизии, стало быть укорачивает ключ.

Алгоритм шифрования незасекречен. Это аксиома криптографии. Стало быть любые преобразования ключа не увеличивают криптостойкость.

Если ты собираешься секретить алгоритм, то это можно рассматривать, как допустимый технический прием в реальной жизни, но только не называй это криптографией.

О чём и речь. Это не тоже самое, что таблицы замен в ГОСТе. Кроме того, в ГОСТе она одна, а в DES их вроде несколько.

В DES одна стандартная таблица. Если изменишь таблицу, то это уже будет не DES. В ГОСТ допускаются разные таблицы, но насколько я знаю, в реальных криптографических продуктах используют 2 разные таблицы. Одна из стандарта, опубликованная, как пример реализации; другая еще кем то придуманная, не помню кем, но тоже открытая.

Если ты собираешься секретить таблицу и использовать ее, как часть более длинного ключа, то фактически ты обмениваешь сложность алгоритма на длину ключа.

ansky ★★★★★
()
Ответ на: комментарий от ansky

Тебе уже написали, что применение md5 добавляет коллизии, стало быть укорачивает ключ.

Я уже писал, почему, в данном случае, коллизии никак не помогут злоумышленику. Пускай там хоть 90% ключей будут друг с другом в коллизии входить.

Стало быть любые преобразования ключа не увеличивают криптостойкость.

Вообще-то, увеличивают. Простой пример: соление пароля увеличивает криптостойкость md5 суммы, несмотря на то, преобразование вполне примитивно и известно.

Если ты собираешься секретить таблицу и использовать ее

Нет, даже если таблица не засекречена, но своя, итоговая криптостойкость выше, чем у стандартного алгоритма с неизменной таблицей. Подумайте, почему.

next_time ★★★★★
() автор топика
Ответ на: комментарий от ziemin

Более того, в случае с энигмой, фактически, ключи шифрования были известны. Неизвестен был сам алгоритм. Как раз случай с энигмой доказывает, что как не скрывай алгоритм, он всё равно рано или поздгно станет известным.

next_time ★★★★★
() автор топика
Ответ на: комментарий от Winnerer

Плюс учтите, что ГОСТ (номер не вспомню) — практически слизанный с него.

Ну и заявочки… У ГОСТ 28147-89 и DES общего только то, что они основаны на сети Фейстеля.

sjinks ★★★
()

Любые. Если у тебя алгоритм который нельзя применять повторно - они уже хреновые. Да, при повторном применении, если есть возможность, переворачивай сообщение - увеличишь рассеивание.

Suntechnic ★★★★★
()
Последнее исправление: Suntechnic (всего исправлений: 1)

А, и еще, почему с одним ключом? Бери для следующего этапа хэшфункцию ключа. Если можешь изменять размер данных добавляй случайный байт в начало сообщения на каждом этапе, при расшифровки отрежешь.

Suntechnic ★★★★★
()
Ответ на: комментарий от Winnerer

Ну не надо же подходить к вопросу так тупо в лоб.

Возьми же уже в качестве первого ключа k+h1(k), в качестве второго k+h2(k) и т.д. Какие коллизии? А ты ведь можешь еще вместо хэша просто шифровать ключ каким нибудь стандартным ключом и алгоритмом. Тоже никаких коллизий.

Suntechnic ★★★★★
()
Последнее исправление: Suntechnic (всего исправлений: 1)
Ответ на: комментарий от next_time

то, что там написано совсем не к месту, ziemin предлагает «нестандартное» применение md5

Чей-то оно не стандартное? Туева хуча алгоритмов использует хэшфункции для разворачивания ключа в заданную длину.

Suntechnic ★★★★★
()
Ответ на: комментарий от anonymous

Придумать новый алгоритм, даже стойкий - не проблема совершенно. Проблема доказать что он стойкий.

Suntechnic ★★★★★
()
Ответ на: комментарий от next_time

Нет, даже если таблица не засекречена, но своя, итоговая криптостойкость выше, чем у стандартного алгоритма с неизменной таблицей. Подумайте, почему.

Нет. Даже где-то видел работы доказывающие что для ГОСТ есть варианты таблиц которые будут снижать стойкость. Более того некоторые из них были найдены.

Suntechnic ★★★★★
()
Ответ на: комментарий от Suntechnic

Есть такое. Но тут наступает такой интересный момент: на практике дешифровка часто подразумевает под собой радужные таблицы, здесь же, в худшем случая обнаружения уязвимостей алгоритма, коллизий, пускай даже использования кватовых суперкомпьютеров (хотя задачи защиты от такого уровня угроз и не стоит) и всего прочего, возникает такой момент, что радужных таблиц под все таблицы замен не понагенерируешь, аппаратную часть под каждую таблицу замен не соптимизируешь. Поэтому, пускай таблица замен будет открытая, может даже с небольшими уязвимостями, но своя, это сильно затруднит возможную атаку.

//Наконец-то адекватные люди в треде

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

но я в плане того, что в ГОСТ она ни разу не стандартизована

Не стандартизирована в ГОСТ, но приведена в RFC 4357. Что означает то, что сторонние реализации (типа openssl) будут использовать S-boxes из RFC.

sjinks ★★★
()
Ответ на: комментарий от sjinks

но приведена в RFC 4357

хм... интересно, не знал

next_time ★★★★★
() автор топика

Я бы не рисковал. С разными ключами стойкость точно не ухудшится.

segfault ★★★★★
()

в архиваторе rar, вроде бы, используется многократное шифрование

anonymous
()
Ответ на: комментарий от next_time

вы вообще анонимус. не нравится - проходите мимо, сюда вас никто не звал

вот так всегда 😐

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.