Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
Меня смущает следующее: я не знаю о широком применении абсолютно стойких криптосистем, скорее всего они широко не применяются и автору текста это должно быть известно. Следовательно, применяются не абсолютно стойкие системы и их реальная стойкость по большей части неизвестна. То есть программист вынужден использовать алгоритм неизвестной стойкости, значит мы имеем два потенциально слабых звена: программиста и алгоритм. Меня бы смущало в первую очередь использование алгоритма непонятной стойкости и меня смущает, что автор об этом не говорит.
И мое отдельное ИМХО: лучше посвятить себя исследованию криптоалгоритмов, а не тому, как писать без ошибок :)
И мое отдельное ИМХО: лучше посвятить себя исследованию криптоалгоритмов, а не тому, как писать без ошибок :)
В криптоалгоритмах к счастью/сожалению отклонение на йоту и несёт всю соль… А вот про стойкость да, судя по статье они не используют стандарты или хотя бы части их. А это уже не фонтан.
Вы имеете в виду, что всевозможные стандатры типа ГОСТ, AES, DSA имеют неизвестную стойкость? Или что зачастую в программах используются какие то свои проприетарные алгоритмы? Если второе, то я с вами согласен более, чем на 100%. Ну а стандартам я все-таки доверяю. Вспомнить хоть отбор на конкурсе sha3. После стольких лет исследований алгоритму думаю можно верить.
Да, стандарты имеют неизвестную стойкость. Более того, даже стойкий алгоритм при неправильном применении (а это уже не программисту решать) будет не сильно стоек…
Время не доказывает стойкость, оно только доказывает, что за это время никто из живущих не смог стойкость доказать ;-)
Время не доказывает стойкость, оно только доказывает, что за это время никто из живущих не смог стойкость доказать ;-)
Из определения нужно доказать нестойкость. Вкратце: стойкий — это когда нет эффективного теста, который мог бы различить случайный выход и шифр. Так что пока такого теста нет — метод стойкий.
Не согласен относительно теста. Я могу передать на простейший XOR кусок ZIP-архива и на выходе получить то, что не отличить от случайных данных (на входе, кста, тоже не отличить). Но никто не скажет что простейший XOR — стойкий алгоритм шифрования.
Стойкий — тот, который невозможно взломать (за некоторое время, как дополнительное условие). На данный момент СЧИТАЕТСЯ стойким RSA с длиной ключа больше N бит потому что нет быстрых методов факторизации в целых.
Стойкий — тот, который невозможно взломать (за некоторое время, как дополнительное условие). На данный момент СЧИТАЕТСЯ стойким RSA с длиной ключа больше N бит потому что нет быстрых методов факторизации в целых.
Почему это XOR не стойкий? А как же одноразовый шифроблокнот?
Сорри, не указал длину ключика, подразумевал что «простейший» не наведет на мысль о длинных-длинных ключах :-) Например, ключ — 1 байт.
Шифруете два одинаковых байта — если в шифре они равны — вы имеете дело с шифром, иначе — случайный текст. Вот простейший тест который позволяет отличить не зная ключа.
P. S. Сорри, немного не понял коммент. Но этот тест работает для любой длины ключа, когда ключ повторяется.
P. S. Сорри, немного не понял коммент. Но этот тест работает для любой длины ключа, когда ключ повторяется.
Есть подозрение, что я не понимаю назначение и применение этого теста. Я могу сделать некоторую функцию F, которая выдаст на выходе нечто, по статистическим характеристикам не отличающееся (я так полагаю по крайней мере) от случайных данных. При этом стойкость преобразования внутри функции будет никакой. Для проведения теста требуется возможность загнать в функцию свои данные или достаточно только результата работы на неизвестных данных?
Есть разные виды атак на шифры: en.wikipedia.org/wiki/Attack_model. Если шифр подвержен одной из них — нельзя назвать его стойким. На неизвестных данных называется ciphertext only, и против XOR с повторяющимся ключом он тоже работает. Повторяющийся ключ размазывает вероятности появления определенных символов в тексте, но они остаются. Есть различные ciphertext only атаки, которые позволяют выяснить длину ключа и далее вскрыть шифр.
Это-то понятно… Но у меня имеется стойкой чувство, что если данные выглядят мусором еще не значит, что они зашифрованы с применением стойких алгоритмов.
Не просто мусором, а равномерным (с вашей точки зрения, т. к. если шифр стойкий, вы не можете отличить равномерное от шифра). А если оно равномерное, т. е. вероятность появления каждого байта равна (опять же, с вашей точки зрения), то шифр не содержит никакой дополнительной информации. А без дополнительной информации анализировать-то нечего, все что вы видите — случайные числа (они не случайны, но вы-то этого не можете определить ни одним тестом).
Как только тест находит метод отделить случайный текст от шифра — он находит некую закономерность, которую можно эксплуатировать для ускорения подбора ключа или получения текста или получения информации о тексте, в общем, того, чего у злоумышленника быть не должно.
Как только тест находит метод отделить случайный текст от шифра — он находит некую закономерность, которую можно эксплуатировать для ускорения подбора ключа или получения текста или получения информации о тексте, в общем, того, чего у злоумышленника быть не должно.
Кстати, решал 3 недели назад задачу: были зашифрованы именно что случайные данные, точнее полученные с одного из PRNG. И в итоге успешно научились подбирать ключ, так что можно проверить данные, даже если они кажутся случайными :-)
Не Вихрь Мерсенна случайно?)
Случайный текст не имеет никакого значения, кстати :) Потому что при нестойком шифре то равномерное, что уже было, портится и появляются закономерности, которых быть не должно.
Обычно после шифрования размер файла не меняется.
Берём белый шум, шифруем нестойким шифром, появляются закономерности, сжимаем.
Профит — мы сжали белый шум.
Берём белый шум, шифруем нестойким шифром, появляются закономерности, сжимаем.
Профит — мы сжали белый шум.
Откуда там появляются закономерности? Нестойкий шифр будет сохранять некоторые закономерности, если они есть, но не привносить их. А то ведь так индуктивно можно и до архиватора Бабушкина договориться.
Вы подумали, что я серьёзно?
Это был сарказм к предыдущему комментарию.
Это был сарказм к предыдущему комментарию.
Меня сбило с толку то, что комментарии не «лесенкой». Специально мотал вверх, думал это ответ на habrahabr.ru/post/186416/#comment_6484566 Извиняюсь=)
Даже если мы сожмем белый шум таким способом, то нам нужен будет ключ (дополнительная информация), чтобы его разжать. Ничего магического не происходит.
Но ведь ключ выбирается пользователем произвольный, а не из тех соображений, чтобы проявились закономерности в зашифрованном файле.
Можно считать, что сначала Алиса загадывает ключ, а Боб, не зная ключа, пытается предложить алгоритм шифрования, снижающий энтропию. Мне кажется, у Боба ничего не выйдет.
Можно считать, что сначала Алиса загадывает ключ, а Боб, не зная ключа, пытается предложить алгоритм шифрования, снижающий энтропию. Мне кажется, у Боба ничего не выйдет.
С википедии:
Два одинаковых байта в шифре не обязательно равны.
Пото́чный шифр — это симметричный шифр, в котором каждый символ открытого текста преобразуется в символ шифрованного текста в зависимости не только от используемого ключа, но и от его расположения в потоке открытого текста.
Два одинаковых байта в шифре не обязательно равны.
Простой XOR не поточный шифр. Основная фишка поточных шифров — они берут ключ и делают из него последовательность криптографически псевдослучайных чисел, и уже эти числа XOR-ят с текстом.
Они решают проблему с длиной ключа у OTP: нам нужен очень длинный не повторяющийся (по крайней мере непредсказуемо повторяющийся) ключ, но большой ключ непрактичный, а маленький — нестойкий. Они берут маленький и расширяют его так, что атакующий не может выявить никакой закономерности в потоке ключа.
Я описал атаку на простой XOR шифр с повторением ключа.
Они решают проблему с длиной ключа у OTP: нам нужен очень длинный не повторяющийся (по крайней мере непредсказуемо повторяющийся) ключ, но большой ключ непрактичный, а маленький — нестойкий. Они берут маленький и расширяют его так, что атакующий не может выявить никакой закономерности в потоке ключа.
Я описал атаку на простой XOR шифр с повторением ключа.
Говоря об одноразовом блокноте, все забывают, что его еще нужно правильно применять:
1. Длина блокнота должна быть как минимум равна длине сообщения
2. Нельзя использовать шифрблокнот повторно
3. Алгоритм генерации самого шифрблокнота должен быть абсолютно случайным.
Нарушение любого из правил — и все пропало. Собственно, об этом автор и писал :)
1. Длина блокнота должна быть как минимум равна длине сообщения
2. Нельзя использовать шифрблокнот повторно
3. Алгоритм генерации самого шифрблокнота должен быть абсолютно случайным.
Нарушение любого из правил — и все пропало. Собственно, об этом автор и писал :)
Простейший XOR – самый стойкий алроритм шифрования в паре с одноразовым блокнотом ;-)
XOR — стойкий алгоритм. Абсолютно стойкий, если быть точным, если вы используете одноразовый статистически случайный ключ с длиной равной длине сообщения. Как только одно из этих условий нарушено — ваш шифр перестает быть стойким, потому что есть тесты, которые позволят отличить его от случайного (они тривиальны, кстати).
СЧИТАЕТСЯ стойким RSA с длиной ключа больше N бит потому что нет быстрых методов факторизации в целыхО чем я и говорю. Нет эффективного теста, который позволит определить случайный текст вы получили или RSA-шифр.
>Я могу передать на простейший XOR кусок ZIP-архива и на выходе получить то, что не отличить от случайных данных (на входе, кста, тоже не отличить)
… И криптоаналитик взломает ваш xor архив очень быстро.
Даже если отбросить magic в заголовке, в начале архива есть информация, необходимая для распаковки — словарь, размеры структур, вектора и т.д.
… И криптоаналитик взломает ваш xor архив очень быстро.
Даже если отбросить magic в заголовке, в начале архива есть информация, необходимая для распаковки — словарь, размеры структур, вектора и т.д.
Из определения нужно доказать нестойкость. Вкратце: стойкий — это когда нет эффективного теста, который мог бы различить случайный выход и шифр. Так что пока такого теста нет — метод стойкий.
А если алгоритм шифрования содержит баг и эффективная длина ключа уменьшается с 256 до 128 бит?
Ничего не меняется. Если вы не сможете эффективно найти закономерность — шифр стойкий. Просто представьте: если эффективная длина ключа уменьшается до 32 бит — вы просто переберете все возможные ключи и получите ответ. Ведь это эффективно на современных компьютерах.
128 бит сложно перебрать в данный момент, поэтому нужны дополнительные закономерности. Например AES-128 и сегодня можно взломать перебрав в примерно 4 раза меньше ключей, чем брутфорсом, т. е. эффективная длина ключа — 126 бит. Но он все равно считается стойким.
128 бит сложно перебрать в данный момент, поэтому нужны дополнительные закономерности. Например AES-128 и сегодня можно взломать перебрав в примерно 4 раза меньше ключей, чем брутфорсом, т. е. эффективная длина ключа — 126 бит. Но он все равно считается стойким.
Т.е. если математически доказано что стойкость алгоритма M, вместо N (M < N), то доказательство можно выбросить в корзину, пока доказывающий, не сделает соизволит сбрутфорсить M вариантов ключей?
С точки зрения математики — это победа. С практической точки зрения эту победу никак не применишь. Потом на основе этого доказательства либо сделают еще более эффективную атаку, либо компьютеры станут настолько мощными, что переберут и M достаточно быстро. С AES, например, если не будет эффективных атак, то при появлении быстрых компьютеров достаточно будет поднять ключ до 256 бит. С RSA так уже давно поступают.
Из определения нужно доказать нестойкость. Вкратце: стойкий — это когда нет эффективного теста
Нет, Ну Вы даёте новое определение стойкости тогда. С ним я не согласен. Никогда «стойкостью» не считалась практическая возможность взломать шифр.
Такое определение стойкости «стойкость=практическая стойкость» очень не практично. Никто не будет использовать алгоритм, написанный студентом, если доказана его теоретическая нестойкость, но ни один уважаемый криптограф не захотел писать софт и брутфорсить его месяц чтобы что-то доказать на практике.
Возможно я не прав, тогда хотелось бы узнать определение стойкости.
В криптографии все связано с практичностью, единственный абсолютно стойкий шифр — OTP, все остальное — попытки сделать его более практичным.
А софт писать никто и не будет, вычислительную сложность можно доказать математически. А как иначе доказать что AES можно взломать не за 2^128, а за 2^126 попыток не потратив несколько миллиардов лет? :)
В криптографии все связано с практичностью, единственный абсолютно стойкий шифр — OTP, все остальное — попытки сделать его более практичным.
А софт писать никто и не будет, вычислительную сложность можно доказать математически. А как иначе доказать что AES можно взломать не за 2^128, а за 2^126 попыток не потратив несколько миллиардов лет? :)
В моей вольной интерпретации (честно сказать, не помню в какой именно книге читал). Теоретически стойкий криптографический протокол — есть протокол, в основе которого применяется алгоритм с секретом, совершающий преобразование входной строки таким образом, что не зная этого секрета, восстановить исходную строку невозможно. То есть не существует такой машины Тьюринга, которая смогла бы за полиномиально ограниченное время по заданной криптограмме восстановить сообщение, не используя секрета.
Собственно, поэтому все и ищут разгадку о равенстве или не равенстве P и NP классов задач. Если равенство, то такая машина Тьюринга существует и все для криптографии плохо… разве только в квантовую теорию пойдет развиваться :)
Алгоритм с секретом может быть разным. Это и перестановочные шифры и шифры, основанные на математических структурах, и даже физические явления (но это, думаю, пока не так развито).
Для симметричных криптосистем (те, которые используют один и тот же секретный ключ для расшифрования) чаще всего используются XOR и перестановки (например тот же наш ГОСТ 28147-89, основанный на сетях Фейстеля). Для ассиметричных систем (2 ключа: один секретный, второй — открытый, полученный путем преобразования закрытого) — трудно разрешимые задачи. Это задачи, которые теоретически имеют решение, но чтобы найти его, требуется очень много времени (в этом случае сложность решения неполиномиальная). Однако такая сложность достигается только при особо подобранных параметрах (алгебраические структуры, длины ключей и т.д.).
Можно использовать действительно стойкий протокол, проверенный временем, тестами и т.д. Но, соглашусь с автором статьи, где тонко, там и рвется: управление ключами, «случайность» (на деле псевдослучайность) ГСЧ, архитектура, на которой реализован протокол и т.д. и т.п. За всем этим нужно следить, все это нужно контролировать, учитывать и анализировать.
Собственно, поэтому все и ищут разгадку о равенстве или не равенстве P и NP классов задач. Если равенство, то такая машина Тьюринга существует и все для криптографии плохо… разве только в квантовую теорию пойдет развиваться :)
Алгоритм с секретом может быть разным. Это и перестановочные шифры и шифры, основанные на математических структурах, и даже физические явления (но это, думаю, пока не так развито).
Для симметричных криптосистем (те, которые используют один и тот же секретный ключ для расшифрования) чаще всего используются XOR и перестановки (например тот же наш ГОСТ 28147-89, основанный на сетях Фейстеля). Для ассиметричных систем (2 ключа: один секретный, второй — открытый, полученный путем преобразования закрытого) — трудно разрешимые задачи. Это задачи, которые теоретически имеют решение, но чтобы найти его, требуется очень много времени (в этом случае сложность решения неполиномиальная). Однако такая сложность достигается только при особо подобранных параметрах (алгебраические структуры, длины ключей и т.д.).
Можно использовать действительно стойкий протокол, проверенный временем, тестами и т.д. Но, соглашусь с автором статьи, где тонко, там и рвется: управление ключами, «случайность» (на деле псевдослучайность) ГСЧ, архитектура, на которой реализован протокол и т.д. и т.п. За всем этим нужно следить, все это нужно контролировать, учитывать и анализировать.
С практической точки зрения эту победу никак не применишь.
С практической точки зрения зависит от величины M.
Согласен, время стойкость не доказывает, но вероятность потенциального взлома значительно уменьшает.
Кстати, стойкость гостовского алгоритма вроде как сильно зависит от его параметров и быстро узнать будут ли конкретные параметры стойкие — невозможно.
Почему я не лезу в криптографию
Выглядит как «в области криптографии в случае бага будет много проблем, поэтому я не буду заниматься криптографией, а займусь чем-то, где смогу быть некомпетентным и смогу закрывать глаза на многие баги/ошибки».
Автору оригинала лучше тогда и C++ заниматься, а то ведь там утечки памяти есть, а он их и не заметит, так как программа то функционирует нормально.
Ну для поиска утечек памяти есть инструменты, да и допустить утечки в С++ не так уж и просто при грамотном использовании умных указателей. А вы знаете какие нибудь инструменты, которые позволят проверить криптостойкость некой системы?
Я с криптографией не работал никогда, но сомневаюсь, что за столько лет не придумали никаких механизмов.
Просто позиция автора:
выглядит как «криптография — это слишком сложно, поэтому я не буду ей заниматься».
C++ я лишь как пример привёл. Есть много действительно сложных областей, но это не значит, что нужно проходить мимо них из-за боязни накосячить.
Просто позиция автора:
Криптография — это то, что я лучше доверю другим. Либо они смогли достичь совершенства, таких я крайне уважаю, либо у них тоже не вышло, таким я посочувствую.
выглядит как «криптография — это слишком сложно, поэтому я не буду ей заниматься».
C++ я лишь как пример привёл. Есть много действительно сложных областей, но это не значит, что нужно проходить мимо них из-за боязни накосячить.
Ну если автор не хочет — пускай проходит мимо. Я каждый день наблюдаю всевозможные косяки в криптографии и пусть лучше там, где она используется во благо, их будет поменьше.
А какой вы способ проверки можете придумать? Я не связывался с криптографией и вообще еще студент, но писал простейший алгоритм Хаффмана, так вот тут же вылились проблемы кодировок, почему-то английские буквы кодировались нормальные, а русские — только небольшие тексты. Я не знаю как на такое написать тесты, возможно просто мне не хватает знаний, но суть такова: когда на выходе вы получаете бинарные данные, которые выглядят как мусор, сложно разобраться и понять что есть хорошо, а что плохо, и где ошибка
сложно разобраться и понять что есть хорошо, а что плохо, и где ошибка
Поэтому лучше этим не заниматься?
Я же не говорил, что там всё просто.
Нет, это я к вашему утверждению о боязни накосячить. Каждую строчку кода нужно обосновывать математически, на мой взгляд даже ПО для марсохода писать проще, потому что на все можно написать тесты.
И автор не утверждает что этим не надо заниматься, он пишет, что в это не лезет, это разные вещи
И автор не утверждает что этим не надо заниматься, он пишет, что в это не лезет, это разные вещи
Эта маленькая ошибка на одну позицию вмиг сломала приложение целиком
Вот почему, друзья мои, я держусь подальше от криптографии. Я просто не настолько крут.
Маленькие ошибка сломала всю систему. Автор понимает, что не может писать без ошибок, поэтому решает заниматься своими делами там, где его ошибки не критичны.
А почему бы не прокачать скилл и делать без ошибок?
p.s. лучше не продолжать дискуссию… я не знаю, как ещё объяснить мои мысли. Может я единственный не так трактую статью автора. Но мне видится всё именно так )
Вы вырываете слова из контекста:
А тут все абсолютно работает, но в какой-то момент нашлась ошибка, которая перечеркивает все что сделала программа до этого. На сколько я понимаю если найти ошибку в генераторе случайных чисел, а на основе этого генератора создан криптографичесикй алогоритм хеширования, то все созданные хеши проще взломать, ведь ошибка ГСС может быть лишь в одном, вместо случайных он выдает не случайные — последовательность.
И я не верю что что-то новое, чего никогда раньше небыло можно написать без ошибок, хотябы потому, что во время написания не с чем сравнивать
Обычно узнаём об этом сразу же: у нас валятся тесты, где-нибудь в логах видны возникшие исключения, или мы слышим жалобы от наших клиентов — мол, то и сё перестало работать.
А тут все абсолютно работает, но в какой-то момент нашлась ошибка, которая перечеркивает все что сделала программа до этого. На сколько я понимаю если найти ошибку в генераторе случайных чисел, а на основе этого генератора создан криптографичесикй алогоритм хеширования, то все созданные хеши проще взломать, ведь ошибка ГСС может быть лишь в одном, вместо случайных он выдает не случайные — последовательность.
И я не верю что что-то новое, чего никогда раньше небыло можно написать без ошибок, хотябы потому, что во время написания не с чем сравнивать
Для проверки тех же ГПСЧ есть куча стандартных тестов: хи квадрат, сжатие и пр. Они как минимум проверяют статистические характеристики последовательностей. Так же может анализироваться шифртекст.
Я с криптографией не работал никогда, но сомневаюсь, что за столько лет не придумали никаких механизмов.
Не читал, но осуждаю? Дело же не в том, что автор боится делать ошибки. В случае с криптографией вы скорее всего даже не сможете понять, что допустили баг. Первое, что приходит в голову — сигнализации на основе алгоритма KeeLoq.
Криптографическую стойкость алгоритмов обсуждают математики-криптографы. Задача подтверждения стойкости алгоритма аналогична задаче подтверждения доказательства теоремы, и пока автоматически ни то, ни другое делать не умеют. Или вы будете утверждать, что программировать на С++ и проверить доказательство гипотезы Пуанкаре — задачи одного уровня сложности? Национальный институт стандартов и технологий США вон 4 года проверял стойкость алгоритмов и решал, какой выбрать: en.wikipedia.org/wiki/NIST_hash_function_competition.
А что KeeLoq?
На него существует алгебраическая атака, подбирающая мастерключ на ноуте в среднем за 3 дня.
На него существует алгебраическая атака, подбирающая мастерключ на ноуте в среднем за 3 дня.
Так о чём и речь, Микрочипу его продали за $10млн в середине 90х, а он оказался не так уж и хорош, и сразу это не увидели. А потом ещё расширили брешь до уровня гигантских ворот, когда 36 бит кода производителя решили лепить одинаковыми на всю серию сигнализаций. В итоге к конкретной машине код подбирается вообще за несколько секунд на современном железе.
Проблема в том что нет методологии позволяющей проверить отсутствие багов. Только грубые ошибки могут быть выявлены тестами.
Кроме криптографии есть еще численные методы. Там тоже ошибка может привести к получению внешне выглядящего нормально, но по сути неверного результата. Или результат может быть правильным, но область сходимости может оказаться суженной из-за ошибки. Как криптографические алгоритмы проверяются на известных выходных данных, так и для численных методов реализовать тесты — нетривиальная задача. И ничего. Есть люди, которые и этого не боятся :)
Вы обязаны ставить перед собой цель достичь совершенства. Если достичь не удаётся — вы безнадёжны.
Что имеется под понятием совершенства? Давайте без утопий.
Любой код шифр можно сломать, вопрос времени и умения. Если в текущих условиях ваши возможности по шифрованию позволяют содержать информацию скрытой в течении нужного вам периода времени то, ваша задача по скрытию выполнена — вы совершенны.
«Любой код шифр можно сломать, вопрос времени и умения.» — А как же т.н. абсолютно стойкие системы?
Они требуют ключа равного длиной сообщению. Какой тогда в них практический смысл? Если у вас есть защищенный канал для передачи большого ключа, передайте сразу сообщение (той же длины).
Требуют, да. Но, к примеру, защищенный канал существует очень недолго, а сообщения надо передавать сильно после этого момента времени.
Те же шифроблокноты с одноразовыми страницами — чем не вариант?
Секретный канал может быть даже личной встречей на пять минут — обменяться последовательностями ключей. Зато потом можно будет на расстоянии передавать множество сообщений — количество ограничено только размером «блокнота».
А ведь в его роли может выступать цифровой носитель с нереальным количеством ключиков — терабайтный хард, например.
Секретный канал может быть даже личной встречей на пять минут — обменяться последовательностями ключей. Зато потом можно будет на расстоянии передавать множество сообщений — количество ограничено только размером «блокнота».
А ведь в его роли может выступать цифровой носитель с нереальным количеством ключиков — терабайтный хард, например.
Не забывайте, в статье в основном речь о программистах и практическом применении (скорее всего в ИТ).
Ассиметричные шифры гораздо более полезны в цифровых системах, чем симметричные, но у них куча недостатков и часто это решается шифрованием симметричного ключа ассиметричным, с OTP такое не прокатит.
Плюс, у OTP есть еще недостаток, его нужно где-то хранить и нельзя потерять, в то время как более короткий симметричный ключ можно вывести из легкозапоминаемого пароля c помощью любой PBKDF.
Конечно, OTP хорош, но слишком трудоемок и непрактичен (не в том плане, что нельзя применить, а в том что нецелесообразно в большинстве случаев).
Ассиметричные шифры гораздо более полезны в цифровых системах, чем симметричные, но у них куча недостатков и часто это решается шифрованием симметричного ключа ассиметричным, с OTP такое не прокатит.
Плюс, у OTP есть еще недостаток, его нужно где-то хранить и нельзя потерять, в то время как более короткий симметричный ключ можно вывести из легкозапоминаемого пароля c помощью любой PBKDF.
Конечно, OTP хорош, но слишком трудоемок и непрактичен (не в том плане, что нельзя применить, а в том что нецелесообразно в большинстве случаев).
Не забывайте, в статье в основном речь о программистах и практическом применении (скорее всего в ИТ).
Это комментарий к комментарию, а не к статье. В комментарии было сказано:
Какой тогда в них практический смысл? Если у вас есть защищенный канал для передачи большого ключа, передайте сразу сообщение (той же длины).
Я указал на возможные варианты.
Ассиметричные шифры гораздо более полезны в цифровых системах, чем симметричные, но у них куча недостатков и часто это решается шифрованием симметричного ключа ассиметричным, с OTP такое не прокатит.
Благодарю, я знаю.
Плюс, у OTP есть еще недостаток, его нужно где-то хранить и нельзя потерять, в то время как более короткий симметричный ключ можно вывести из легкозапоминаемого пароля c помощью любой PBKDF.
Конечно, OTP хорош, но слишком трудоемок и непрактичен (не в том плане, что нельзя применить, а в том что нецелесообразно в большинстве случаев).
Да, это всё понятно.
Согласен, теоретически возможно, но точки зрения реализации очень очень накладно.
Слабое звено рвёт всю цепь.Это не всегда так. В SSH, например, до сих пор используется Encrypt-and-MAC, который не считается стойким, но тем не менее он не вносит проблем с безопасностью. В TLS недавно рекомендовали использовать RC4, который тоже менее надежный, чем AES, но из-за особенностей реализации AES-CBC оказался подвержен атаке, а RC4 — нет.
Написание теста для этого случая требовало бы специальных навыков и умений, да и вероятность допущения ошибки в тесте настолько же высока, насколько высока вероятность ошибки в самом коде, требующем тестирования.Даже в статье об ошибке показано, что относительно простого chi square хватило бы для выявления этой ошибки.
Мысль автора лучше перефразировать так: не пишите свою криптографию, не придумывайте алгоритмов, если вы в этом не разбираетесь. А использовать готовые библиотеки можно и нужно, но осторожно, не добавляя своих изысканий (a one time pad is perfectly secure, but I've encrypted it 1000 times, just in case) :)
Мысль автора лучше перефразировать так: не пишите свою криптографию, не придумывайте алгоритмов, если вы в этом не разбираетесь.
Да! Да, черт возьми! Спасибо за формулировку!
Судя по информации из вики, RC4 вообще живучая и повсеместная штука.
да и вероятность допущения ошибки в тесте настолько же высока, насколько высока вероятность ошибки в самом коде, требующем тестирования.
А вероятность одновременной одинаковой ошибки и в тесте и в коде?
p.s.
вообще я со статьёй согласен, но у этого довода не хватает аргументации имхо.
Действительно — не стоит пытаться изобретать велосипед, если не уверен в своих силах.
Сам с этим столкнулся на практике.
Когда у Lineage2 был украден код PTS сервера — и поставлен на сотни пиратских серверов — пароли игроков на таких серверах были захешированы самописным алгоритмом, напоминающим MD5. Однако у похожих паролей начальные символа хеша совпадали, что позволило написать код, очень быстро подбирающий коллизии. Например, база из 50 тысяч записей расшифровывалась минут за 5.
Ситуация длилась минимум до пятых хроник, а возможно и еще дольше. А все потому, что не использовали уже существующую реализацию надежного хеширования.
Сам с этим столкнулся на практике.
Когда у Lineage2 был украден код PTS сервера — и поставлен на сотни пиратских серверов — пароли игроков на таких серверах были захешированы самописным алгоритмом, напоминающим MD5. Однако у похожих паролей начальные символа хеша совпадали, что позволило написать код, очень быстро подбирающий коллизии. Например, база из 50 тысяч записей расшифровывалась минут за 5.
Ситуация длилась минимум до пятых хроник, а возможно и еще дольше. А все потому, что не использовали уже существующую реализацию надежного хеширования.
Как говорит Dan Boneh из Стэнфорда: «Don't implement crypto yourself» ( c )
На протяжении своего курса по криптографии на Coursea, он это повторял по нескольку раз за каждую лекцию, приводя наглядные примеры что будет если таки самому пытаться реализовывать криптоконструкции без опыта их разработки и глубокого понимания того, что лежит в их основе.
На протяжении своего курса по криптографии на Coursea, он это повторял по нескольку раз за каждую лекцию, приводя наглядные примеры что будет если таки самому пытаться реализовывать криптоконструкции без опыта их разработки и глубокого понимания того, что лежит в их основе.
Как говорит Dan Boneh из Стэнфорда: «Don't implement crypto yourself» ( c )
Правильно он говорит, конечно же. Но, с другой стороны, можно наткнуться на то, что в библиотеке что-нибудь оптимизировали до int random() { return 4; }. ;)
Речь о разработке криптоалгоритмов или о реализации уже существующих?
Для криптоалгоритмов известных можно написать тесты — с известными входными данными и известным шифротекстом.
Но да, ошибки в криптографии — это жестко. О чём-нибудь мелком забудешь — и весь результат не сходится. Много раз спотыкался на этом, когда для университета реализовывал twofish.
Но да, ошибки в криптографии — это жестко. О чём-нибудь мелком забудешь — и весь результат не сходится. Много раз спотыкался на этом, когда для университета реализовывал twofish.
Я чего-то не понимаю, куда лезть, если все уже реализовано и проверено? OpenSSL, PolarSSL и т.д. Там документации на час изучения.
Свои велосипеды городить — да, этим заниматься нельзя ни в коем случае. А5 тому хороший пример.
Свои велосипеды городить — да, этим заниматься нельзя ни в коем случае. А5 тому хороший пример.
А вообще, очень смешно получается, когда программисты из-за лени разобраться с openssl шифруют пароли xor.
Ошибки можно допустить и при использовании готовых библиотек, поэтому надо тщательно изучить применение алгоритмов и параметры, которые обеспечивают приемлемый уровень безопасности. Кроме того, вычислительная мощность растет, государство может располагать суперкомпьютерами, поэтому нужно оценивать и с этой точки зрения. Необходимо своевременно проверять актуальность используемых алгоритмов.
C habrahabr.ru/post/168025/
Забавно…
Слабость генератора случайных чисел, используемого Mega при создании RSA-пары (создатель Cryptocat, Nadim Kobeissi, долго и зло проходился по их генератору в твиттере)
Забавно…
в свое время для проверки правильности шифрации а потом дешифрации в проге CopyMik использовал сравнение md5 порядка 360 000 фалов до шифрования и после дешифровки (как вариант в процедуру кроме шифрования могло вклиниваться ещё и сжатие перед шифрованием). Для удобства анализа даже свою утилиту md5 написал (которая потом позволяла удобно слить md5 в однин текстовик а потом сравнить текстовики до и после в kDiff) Это конечно не гаранития на все 100%, но учитывая большое количество файлов и отсутствие хоть одного не совпадения статистически можно было предположить что тест отработал без ошибок. По криптостойкости анализ не требовался т.к. использовались известные алгоритмы шифрации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я не лезу в криптографию