Pull to refresh

Comments 35

Подобные производные не дают никакой дополнительной криптостойкости и основываются на том, что у злоумышленника нет алгоритма шифрования (security through obscurity)
Вы бы хоть прочитали, для начала.
Я прочитал. Что в моём комментарии не так?
1. Алгоритм в заметке, он не скрывается и не должен «скрываться».
2. Дополнительной криптостойкости мы и не пытаемся обеспечивать (дополнительной относительно чего?), это использование бесключевого примитива для построения симметричной схемы шифрования с заданными параметрами.
3. «Производными» в контексте вышеизложенного примитивы конечно можно назвать, но от этого их суть не меняется.

Ваш комментарий хорош, я и сам не редко напоминаю о подобной проблеме, однако здесь «пальцем в небо».
> Таким образом, мы обеспечиваем уверенность в верной расшифровке ее моделированием с различными параметрами.

Не совсем так. Ваш алгоритм не гарантирует 100% возврата той же самой msg для исходного key.

Существует ненулевая вероятность, что хэш от «key + n (где n < ожидамого N) + произвольная строка» даст те же 40 байт.

> дополнительной относительно чего?

Дополнительной относительно существующих синхронных и асинхронных методов?
Бррр, 40 бит, опечатался
О ужас, я и вправду всё прочитал невнимательно. Все мои комментарии в этом топике считайте бредом.

И извините :-)
> Существует ненулевая вероятность, что хэш от «key + n (где n < ожидамого N) + произвольная строка» даст те же 40 байт.

В методе шифрования мы как раз выбираем такое n, то алгоритм дешифрования, не зная этого n и исходного сообщения выдаст нам исходное сообщение по заданному ключу. То есть если это невозможно (хотя при верных ограничениях на N это невозможно) — ошибка видна будет на этапе шифрования.

> Дополнительной относительно существующих синхронных и асинхронных методов?
Это другой метод, это важно, его главное достоинство — возможность нескольких вариантов «расшифровки». Одним паролем вы расшифруете скачанный с трекера фильм, другим — свою коллекцию фотографий, и проверить что именно вы шифровали — не представляется возможным. Криптостойкость здесь вторичное свойство, и оно определяется стойкостью хеш-функции, проверить что оно не деградировало — нетривиальная задача, но в целом, при наличии первого свойства — не основная.
UFO just landed and posted this here
Немного не в тему, но мне достаточно интересен такой момент при существовании двух и более слоёв в одном криптоконтейнере.

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

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

> как избегается потеря данных?
В трукрипте есть режим безопасного монтирования контейнера. В этом режиме проверяется, не будут ли повреждены блоки, содержащие скрытый контейнер, и если будут, запись блокируется. Для такого режима требуются оба ключа, как от основного, так и от секретного контейнера.
Но ведь те, блоки, где контрольная сумма не совпадает вызовут определенные подозрения при детальном анализе (это уже ближе к стеганографии)?
Подход, впрочем, конечно, тоже имеет право на существование.
UFO just landed and posted this here
Длинный текст практически невозможно будет «расшифровать» даже с настоящим ключом. Если же текст делить на блоки, то при «фейковой» расшифровке из них обратно не соберётся осмысленный текст, что и выдаст «фейковость» ключа.
С длинным текстом — это верно. Текст придется делить на блоки. С блоками небольшой длины теоретически не должно быть проблем при достаточном пространстве для контрольных значений, кроме, конечно, производительности. Можно подумать о некотором trade-off между осмысленностью и скоростью, когда «фейк» — например видео или аудио-поток.
Будет точно понятно, когда напишу GPU-версию.
Текста же два. Брать два осмысленных одной длины.
Точнее даже не строго одинаковой длины, а разбивающихся на примерно равное количество блоков ограниченной длины (в прототипе до этого я не догадался, но в жизни — ничего не мешает). Все-таки очень сложно найти fake-текст строго заданной длины.
> Все-таки очень сложно найти fake-текст строго заданной длины.

При необходимости передать информацию, грамотно составленная дезинформация в качестве второго текста будет крайне полезна, можно заодно ввести противника в заблуждение.
В моем стареньком телефоне SE есть такая опция как «хранилище паролей».
При входе в этот раздел нужно ввести пароль, после чего будет высвечено контрольное слово. Ну и доступ к паролям открывается. Штука в том, что он открывается в любом случае, но только в случае неправильного пароля при входе все пароли в хранилище будут расшифрованы неверно. И определить это можно только по контрольному слову.
Вроде бы очень напоминает изложенную схему?
Да, у меня тоже такой был, может быть подсознательно и «вдохновился» этой идеей. Там, конечно, куда проще было реализовано (думаю обычным XOR-кодированием). Главное отличие — что здесь будет минимум два осмысленных текста и два контрольных слова (если мыслить в такой постановке). Появляется основание утверждать, что «я шифровал текст 1, а о наличии текста 2 ничего не знаю».
Архиваторы (тот же rar) примерно так же жмут с паролем: вы можете разархивировать файл с любым ключом, просто получите мусор, и CRC32 не сойдётся (а с вероятностью 2^-32 даже сойдётся).
Автору респект, изобрел оооочееень медленный блочный 40-битный шифр с ключем переменной длины
Хотя нет, 100% гарантии того что это блочный шифр нет, т.к. для md5 есть только гарантия того, что для разных 40-битных строк будет отличаться полный хеш, а для первых 40 бит хеша такой гарантии нет.
Так что для некоторых ключей возможно встретится коллизия.
Не блочный а поточный, тогда уж (я не зря написал как это обеспечить и указал ссылку на материал в статье). Хотя это алгоритм несколько другого класса, и если вы не понимаете идею, то не обязательно «кричать» об этом.

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

Пусть вы знаете часть шифрованного текста, можете ли вы получить другие его части?
Даже если они содержат в точности те же знаки, что и известные вам — нет. Т.к. применяется альтернация ключа, и для каждого блока хеш-значение различно.
Если различные — то получить полезную информацию из одного маленького блока даже сложнее чем из «большого», даже при учете что хеш-функции могли бы быть легко обратимы (количество информации в блоке просто недостаточно, чтобы «выбить» весь ключ).

Таким образом, при любом размере блока, пусть даже однобайтном, сложность атаки упирается в возможность строить обратные к хеш-функциям (не коллизии, а именно обратные, при учете что ключ короче выходного значения ф-ции).
Верно, прошу прощения, на выходе получается больше бит чем на входе, иначе Ваш подход не работал бы: для любого m при заданном key можно найти значение msg длиной порядка 40 бит, что результат хеширования с обрезанием на 40 бит будет равен заданному X.
UFO just landed and posted this here
UFO just landed and posted this here
Как и с вторым утверждением. Не все так примитивно там, читайте.
UFO just landed and posted this here
Я этого не утверждал в статье, и с чего бы мне это утверждать сейчас? Для обеспечения корректности алгоритма — этого не требуется, а вы так и не прочитали абзац начиная с «Магия».
UFO just landed and posted this here
Разумеется, описанная вами ситуация возможна, но тогда, m=5 — не дает подходящего шифр-текста, по определению функции encrypt, и она продолжит перебирать m дальше.

Относительно пустого результата строгой уверенности при ограниченном переборе m конечно нет, хотя это более актуальный вопрос при шифровании одновременно двух сообщений.
При шифровании одного, при учете что его длина (L) меньше разрядности выхода (N) первая коллизия и так будет почти во всех случаях с ним совпадать (с вероятностью 1-2^(N-L)).
UFO just landed and posted this here
уже ближе, но не совсем так.

>Тогда чтобы подсчитать encrypt(key,msg) мы ищем наименьшее m такое, что НЕ >существует msg2, что msg2<msg и R(key,m,msg2)=R(key,m,msg). Найдя такое m >возвращаем X=R(key,m,msg).

Правильнее звучит: не существует таких m2 и msg2<msg, таких, что R(key,m2,msg2) = R(key,m,msg).

>Корректность encrypt очень сомнительна, т.е. совершенно не понятно, вернёт она какой-то результат или нет на случайном входе.

Вернет, ежели R:(key,m,msg)->H и |msg| < |H| < |m| * |msg|. Однако это утверждение основывается на примерной равновероятности значений md5 от случайных строк (с равномерным распределением). Это свойство не доказано и не опровергнуто [поправьте, если появилась информация].

>Вообще старайтесь избегать вложенных в друг друга определений, на таких штуках построена куча парадоксов =)
здесь «друг в друга» определений нет, encrypt использует определение decrypt, но не наоборот, вполне допустимая схема.

«Магия» в данном случае шуточное понятие, думаю, должно быть очевидно.
UFO just landed and posted this here
Sign up to leave a comment.

Articles