Алгоритмы шифрования. Почему не смешать несколько?

Будет, сделай.

Ты лучше по теме ответь, почему это так, или не так.

А почему ты считаешь, что от этого возрастет безопасность? Только потому, что проект становится сложнее?

Это так не всегда работает. Иногда можно и обратный эффект получить в плане безопасности.
А в конкретно этом вопросе — проблема у мессенджеров не в сферическом в вакууме алгоритме.

Есть же открытые библиотеки криптографии, которые прошли аудит. Их используют во всяких мессенджерах типа Signal, Jami и других. Никто же не лезет их менять, просто берут готовое. Так почему бы не взять несколько таких библиотек, и последовательно не зашифровать с использованием их всех? Почему несколько слоев шифрования по-твоему хуже, чем один?

А в чем главная проблема?

которые прошли аудит

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

В TLS была поддержка сжатия данных для экономии трафика. Сжатие происходило до шифрования, не было никак связано с шифрованием. Но от него сейчас отказались. И более того, советуют важные данные не сжимать, а шифровать как есть. Знаешь почему? Потому что TLS защищает содержимое сообщений, но не защищает размер сообщений. Размер видно. И вот этот побочный канал давал возможность при определённых ситуациях восстановить пользовательские Cookies. Я даже как-то видел статью, где по шифрованному трафику голосового мессенжера научились определять язык, на котором собеседники общались. Опять-таки, без взлома шифра как такового.

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

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

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

Это еще не считая потенциальных проблем с совместимостью алгоритмов и сюрпризов а-ля 3DES

А почему ты считаешь, что от этого возрастет безопасность?

Шифруешь аесом, потом гостом. Аес нейтрализует бэкдоры фсб в госте, гост нейтрализует бэкдоры нса в аес. Обе стороны негоду

Можно и одним алгоритмом десять раз с десятью разными ключами, но это же безумие.

Шифруешь аесом, потом гостом. Аес нейтрализует бэкдоры фсб в госте, гост нейтрализует бэкдоры нса в аес. Обе стороны негоду

Алгоритмы шиврования это как два уравнения которые друг в друга подстваляешь и не факт что сложность расшифровки после подстановки вырастет.

Разве что алгоритмы будут принципиально разными, один например комбинаторный/перестановочный, другой по разложению на простые числа или элиптические кривые.

Хм, можно ли CBC-режим называть шифрованием с разными ключами?))

Отдельно взятый алгоритм имеет определённую математически доказанную криптостойкость. Любые произвольные комбинации - уже нет.

Отдельно взятый алгоритм имеет определённую математически доказанную криптостойкость. Любые произвольные комбинации - уже нет.

Есть два алгоритма с доказанной криптостойкостью. Оба используются для того чтоб шифровать открытый текст. Так почему если взять зашифрованный тест первым алгоритмом и зашифровать его еще и вторым оба вдруг потеряют криптостойкость(ключи для каждого алгоритма естественно свои)?

Мысль что надо брать цепочку алгоритмов шифрования для надежности для своих нужд у меня давно появилась, если вдруг найдут уязвимость в одном из алгоритмов, то в запасе еще парочка будет. Это как идея с проверкой целостности файлов/данных несколькими разными хеш алгоритмами, даже если сумели взломать один из алгоритмов и модифицировать файл так что данные внутри другие а хеш тот-же, то проделать такое-же уже с двумя алгоритмами становится еще сложнее если вообще возможно.
Но в массовом софте делать такого никто не будет. Ведь на это нужны дополнительные вычислительные мощности, а это стоит денег.

будет, но только если будешь в каждом алгоритме использовать разные ключи. тогда, суммарная надежность шифрования будет соответствовать однократному шифрованию с суммарной длиной ключа, например 128+56=184

если будешь использовать один ключ, то это будет эквивалентно однократному шифрованию + шифрование по методу «неуловимого ковбоя Джо»

Есть два алгоритма с доказанной криптостойкостью. Оба используются для того чтоб шифровать открытый текст. Так почему если взять зашифрованный тест первым алгоритмом и зашифровать его еще и вторым оба вдруг потеряют криптостойкость(ключи для каждого алгоритма естественно свои)?

А где гарантия, что нет? От этой комбинации ты получаешь третий, неисследованный алгоритм.

Ну, тут же получается по одному ключу на блок.

Я придумал «шифр Бабушкина». Берёшь несколько алгоритмов, шифруешь сообщение реальным ключом, потом берёшь зашифрованное сообщение в качестве ключа для другого адгоритма, случайно выбранного из списка, и так в цикле случайное количество раз.

От этой комбинации ты получаешь третий, неисследованный алгоритм.

Да не получится никакой третий алгоритм. Вот еслиб первый алгоритм менял бы размер тогда да. Ты ведь не хочешь сказать что заливая зашифрованный файл через HTTPS соединение(которое все шифрует независимо от того шифрованные данные передаются или текст) этот файл вдруг ломает шифрование HTTPS?

Ну вот такая аналогия. Есть, допустим, две хитрожопые многоэтажные математические функции f1(x) и f2(x). Где гарантия, что, например, f3(x)=f2(f1(x)) не выродится в более простое выражение? А для практического применения нужно точно знать сложность f3.

Где гарантия, что, например, f3(x)=f2(f1(x)) не выродится в более простое выражение?

Ну тогда надо срочно запретить передавать шифрованные файлы по HTTPS/SSH, а то мало-ли повторное шифрование расшифрует эти самые шифрованные файлы.

Запрещай.

Ну ещё аналогия: давай rar сожмем gz, потом bz2, xz итд. И так в цикле, пока файл до бита не уменьшится. Норм же идея?

То есть, достаточно дешифровать конечную версию, и зная ключ — повторить всё в обратном порядке? И предыдущие итерации других алгоритмов в лучшем случае не ослабят ключ (в сравнении с полученным с качественного ГСЧ такого же размера).

Информация о выбранном алгоритме всё равно должна где-то храниться, чтобы правильно расшифровывать.

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

То есть, достаточно дешифровать конечную версию, и зная ключ — повторить всё в обратном порядке?

Нет ведь, даже вычислив ключ от последней версии, ты не узнаешь ключа предыдущей.

Информация о выбранном алгоритме всё равно должна где-то храниться, чтобы правильно расшифровывать

Ты не в курсах, похоже. Гугли «Архиватор Бабушкина» и просвещайся.

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

Чот наркомания. Тебе придется как-то передавать данные о том, какой алгоритм в каком месте использовался, это во-первых, во-вторых - или подбирать алгоритмы так, что бы они работали с ключами одного размера, или городить еще какие-то костыли для выравнивания при передаче из алгоритма в алгоритм.

Ну, и в любом случае у тебя остается spof - твой первый ключ.

И да, если ты используешь шифротекст блока A как ключ для блоки A+1 без каких-либо преобразований - то атакующему будут известны все ключи, кроме первого, и вопрос будет только в том, какие алгоритмы там использовать. А алгоритмов шифрования куда меньше, чем 128-битных ключей :)) И это не считая того, что криптосистема не должна терять стойкости при раскрытии реализации атакующему. Стойкость должна заключаться только в ключе.

PS ты, по сути, описал CBC, только с новым алгоритмом для каждого блока.

Вроде как кроме шифра Вернама ни один не поломанный алгоритм не имеет доказанной криптостойкости при помощи математического аппарата.

Напомни мне внести тебя в профиль. Cast peregrine

Так c DES пока тоже не придумали как его сломать без брутфорса

А почему ты считаешь, что от этого возрастет безопасность? Только потому, что проект становится сложнее?

Если параноик и не разбираешься в крипте, то в качестве причины испольования двух алгоритмов шифрования можно указать – что они должны происходить из разных юрисдикций. Типа если АНБ и ФСБ подсуетились, то обломаются и те и те. Разумеется хэши, на которых они основанны тоже должны быть из тех же разных юрисдикций. Ну ещё сверху добавить третий – стойкий к алгоритму Шора (ЕМНП), на тот случай если Гугл на своём квантовом компьютере захочет почитать мою переписку.

Пока это всё что может подсказать мне паранойя на этот счёт.

Почему несколько слоев шифрования по-твоему хуже, чем один?

1. Больше смысла имеет присаливание данных маленьких размером.
2. Нагрузка на проц возрастает в 2 раза, но вроятность расшифровки прямым перебором становится настолько заоблачной, что никто не готов платить тем процессорным временем за эту заоблачность в реальности. Ну это как говорить задом наперёд, чтобы никто не догадался. Онтополх мокшилс он, онченок оньлокирп апит.

Ок, залогинился, внёс правку

чувакъ поздравляю ты придумал Triple_DES

обычно исходят из того, что алгоритм шифрации известен злоумышленику и неизвестен только ключ. так что твои замудрения лишь увеличивают длину ключа (что есть хорошо) и ресурсы необходимые для шифровки сообщения.

Збс будет только при соблюдении некоторых условий.

Вообще, давненько такой концентрации бредятины в треде не читал (треды о метапроге и отставке Рихарда Данилыча не в счёт). Единственная разумная мысль, прозвучавшая в оном — последовательность применения этих алгоритмов тоже желательно скрывать. Ну и по размеру сообщения выравнивать, да, если есть возможность. От себя могу добавить лишь, что ещё желательно иметь алгоритмы разных классов. Например, AES + SNOW или какой-нибудь DES с поточным самопалом на базе SHA256 (могу провести ликбез, как из любой криптографически стойкой хэш-функции сделать вполне рабочий поточный шифр). Ну и самое главное — срок жизни ключа и безопасность обмена оными. Вернамыч вообще обычным XOR реализуется (исторически — сложением/вычитанием по модулю 10), но он неломаем исключительно потому, что ключи используются только один раз. Проблема лишь в доставке этих ключей всем корреспондентам.

P.S. И да, на принцип Керкгоффса в современном мире многие кладут большой и толстый, поэтому можно невозбранно декларировать одно, а в криптомодуль зашивать совершенно другое. Стоимость реверс-инжиниринга оных всё равно чаще всего превышает стоимость защищаемой информации.

Ну ещё аналогия: давай rar сожмем gz, потом bz2, xz итд. И так в цикле, пока файл до бита не уменьшится. Норм же идея?

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

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

но почему-бы не сделать несколько, чтоб безопасность возросла?

Это называется, не важен результат, главное «чтобы все задолбались».

Применительно к мессенджерам атака скорее идёт не на зашифрованное сообщение, а на самих Алису или Боба, или на окружение которое они используют. И сложность реализации шифрования здесь не причём.

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

Ты не в курсах, похоже. Гугли «Архиватор Бабушкина» и просвещайся

И ты.

Нет ведь, даже вычислив ключ от последней версии, ты не узнаешь ключа предыдущей.

И, конечно же, предыдущие ключи нигде не хранятся, если я правильно понял отсылку? :-)

Ты не в курсах, похоже. Гугли «Архиватор Бабушкина» и просвещайся.

Нашёл этот опус, вспомнил.

Алгоритмы шифрования. Почему не смешать несколько?

Примерно по той же причине, по которой не рекомендуют смешивать пиво с водкой с коньяком.

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

И вообще, есть секретные данные? НУЖНО шифрование? Шируйте руками через gpg или подобные. Откуда вы знаете, что и как мессенджер шифрует, где хранит нешифрованные кеши и куда пересылает ключи.

почему-бы не сделать несколько, чтоб безопасность возросла

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

Для повышения же «безопасности» гораздо эффективнее в плане соотношения затраты/результат использовать организационные меры. e2e вместо серверного ключа, например, или блокчейн как в bitmessage и т.п.

Не совсем Triple_DES. Некоторый алгоритм может быть скомпрометирован. Тогда сложность ляжет на внутренние, которые будут отличаться и метод их взлома может быть неизвестен злоумышленнику. Догадки о том, что криптостойкость только ухудшится ни к селу ни к городу (если не 1 ключ на всех слоях), т.к. ты сам всегда можешь зашифровать уже зашифрованное если тебе от этого станет легче.