Comments 35
Подобные производные не дают никакой дополнительной криптостойкости и основываются на том, что у злоумышленника нет алгоритма шифрования (security through obscurity)
Вы бы хоть прочитали, для начала.
Я прочитал. Что в моём комментарии не так?
1. Алгоритм в заметке, он не скрывается и не должен «скрываться».
2. Дополнительной криптостойкости мы и не пытаемся обеспечивать (дополнительной относительно чего?), это использование бесключевого примитива для построения симметричной схемы шифрования с заданными параметрами.
3. «Производными» в контексте вышеизложенного примитивы конечно можно назвать, но от этого их суть не меняется.
Ваш комментарий хорош, я и сам не редко напоминаю о подобной проблеме, однако здесь «пальцем в небо».
2. Дополнительной криптостойкости мы и не пытаемся обеспечивать (дополнительной относительно чего?), это использование бесключевого примитива для построения симметричной схемы шифрования с заданными параметрами.
3. «Производными» в контексте вышеизложенного примитивы конечно можно назвать, но от этого их суть не меняется.
Ваш комментарий хорош, я и сам не редко напоминаю о подобной проблеме, однако здесь «пальцем в небо».
> Таким образом, мы обеспечиваем уверенность в верной расшифровке ее моделированием с различными параметрами.
Не совсем так. Ваш алгоритм не гарантирует 100% возврата той же самой msg для исходного key.
Существует ненулевая вероятность, что хэш от «key + n (где n < ожидамого N) + произвольная строка» даст те же 40 байт.
> дополнительной относительно чего?
Дополнительной относительно существующих синхронных и асинхронных методов?
Не совсем так. Ваш алгоритм не гарантирует 100% возврата той же самой msg для исходного key.
Существует ненулевая вероятность, что хэш от «key + n (где n < ожидамого N) + произвольная строка» даст те же 40 байт.
> дополнительной относительно чего?
Дополнительной относительно существующих синхронных и асинхронных методов?
Бррр, 40 бит, опечатался
О ужас, я и вправду всё прочитал невнимательно. Все мои комментарии в этом топике считайте бредом.
И извините :-)
И извините :-)
> Существует ненулевая вероятность, что хэш от «key + n (где n < ожидамого N) + произвольная строка» даст те же 40 байт.
В методе шифрования мы как раз выбираем такое n, то алгоритм дешифрования, не зная этого n и исходного сообщения выдаст нам исходное сообщение по заданному ключу. То есть если это невозможно (хотя при верных ограничениях на N это невозможно) — ошибка видна будет на этапе шифрования.
> Дополнительной относительно существующих синхронных и асинхронных методов?
Это другой метод, это важно, его главное достоинство — возможность нескольких вариантов «расшифровки». Одним паролем вы расшифруете скачанный с трекера фильм, другим — свою коллекцию фотографий, и проверить что именно вы шифровали — не представляется возможным. Криптостойкость здесь вторичное свойство, и оно определяется стойкостью хеш-функции, проверить что оно не деградировало — нетривиальная задача, но в целом, при наличии первого свойства — не основная.
В методе шифрования мы как раз выбираем такое n, то алгоритм дешифрования, не зная этого n и исходного сообщения выдаст нам исходное сообщение по заданному ключу. То есть если это невозможно (хотя при верных ограничениях на N это невозможно) — ошибка видна будет на этапе шифрования.
> Дополнительной относительно существующих синхронных и асинхронных методов?
Это другой метод, это важно, его главное достоинство — возможность нескольких вариантов «расшифровки». Одним паролем вы расшифруете скачанный с трекера фильм, другим — свою коллекцию фотографий, и проверить что именно вы шифровали — не представляется возможным. Криптостойкость здесь вторичное свойство, и оно определяется стойкостью хеш-функции, проверить что оно не деградировало — нетривиальная задача, но в целом, при наличии первого свойства — не основная.
UFO just landed and posted this here
Немного не в тему, но мне достаточно интересен такой момент при существовании двух и более слоёв в одном криптоконтейнере.
Например возьмём вариант трукрипта с фиксированным размером контейнера, соответвенно если мы создадим второе дно, то оно будет кушать место и соответственно когда мы попробуем заполнить «первое дно», то мы либо не досчитаемся объёма «второго дна», либо будем терять его данные. Последний вариант более вероятен, т.к. мы не должны уметь узнавать о существовании «второго дна». Соответственно вопрос, а что происходит с данными второго дна при записи в первый и как избегается потеря данных?
Воариант с неопределённым размером контейнера, описанный вами, конечно таких проблем лишён, но появляется сильный демаскриующий фактор, т.к. если во втором дне много данных, то его существование будет выдавать значительный оверхед.
Например возьмём вариант трукрипта с фиксированным размером контейнера, соответвенно если мы создадим второе дно, то оно будет кушать место и соответственно когда мы попробуем заполнить «первое дно», то мы либо не досчитаемся объёма «второго дна», либо будем терять его данные. Последний вариант более вероятен, т.к. мы не должны уметь узнавать о существовании «второго дна». Соответственно вопрос, а что происходит с данными второго дна при записи в первый и как избегается потеря данных?
Воариант с неопределённым размером контейнера, описанный вами, конечно таких проблем лишён, но появляется сильный демаскриующий фактор, т.к. если во втором дне много данных, то его существование будет выдавать значительный оверхед.
> что происходит с данными второго дна при записи в первый?
Они затираются.
> как избегается потеря данных?
В трукрипте есть режим безопасного монтирования контейнера. В этом режиме проверяется, не будут ли повреждены блоки, содержащие скрытый контейнер, и если будут, запись блокируется. Для такого режима требуются оба ключа, как от основного, так и от секретного контейнера.
Они затираются.
> как избегается потеря данных?
В трукрипте есть режим безопасного монтирования контейнера. В этом режиме проверяется, не будут ли повреждены блоки, содержащие скрытый контейнер, и если будут, запись блокируется. Для такого режима требуются оба ключа, как от основного, так и от секретного контейнера.
Но ведь те, блоки, где контрольная сумма не совпадает вызовут определенные подозрения при детальном анализе (это уже ближе к стеганографии)?
Подход, впрочем, конечно, тоже имеет право на существование.
Подход, впрочем, конечно, тоже имеет право на существование.
Длинный текст практически невозможно будет «расшифровать» даже с настоящим ключом. Если же текст делить на блоки, то при «фейковой» расшифровке из них обратно не соберётся осмысленный текст, что и выдаст «фейковость» ключа.
С длинным текстом — это верно. Текст придется делить на блоки. С блоками небольшой длины теоретически не должно быть проблем при достаточном пространстве для контрольных значений, кроме, конечно, производительности. Можно подумать о некотором trade-off между осмысленностью и скоростью, когда «фейк» — например видео или аудио-поток.
Будет точно понятно, когда напишу GPU-версию.
Будет точно понятно, когда напишу GPU-версию.
Текста же два. Брать два осмысленных одной длины.
Точнее даже не строго одинаковой длины, а разбивающихся на примерно равное количество блоков ограниченной длины (в прототипе до этого я не догадался, но в жизни — ничего не мешает). Все-таки очень сложно найти fake-текст строго заданной длины.
В моем стареньком телефоне SE есть такая опция как «хранилище паролей».
При входе в этот раздел нужно ввести пароль, после чего будет высвечено контрольное слово. Ну и доступ к паролям открывается. Штука в том, что он открывается в любом случае, но только в случае неправильного пароля при входе все пароли в хранилище будут расшифрованы неверно. И определить это можно только по контрольному слову.
Вроде бы очень напоминает изложенную схему?
При входе в этот раздел нужно ввести пароль, после чего будет высвечено контрольное слово. Ну и доступ к паролям открывается. Штука в том, что он открывается в любом случае, но только в случае неправильного пароля при входе все пароли в хранилище будут расшифрованы неверно. И определить это можно только по контрольному слову.
Вроде бы очень напоминает изложенную схему?
Да, у меня тоже такой был, может быть подсознательно и «вдохновился» этой идеей. Там, конечно, куда проще было реализовано (думаю обычным XOR-кодированием). Главное отличие — что здесь будет минимум два осмысленных текста и два контрольных слова (если мыслить в такой постановке). Появляется основание утверждать, что «я шифровал текст 1, а о наличии текста 2 ничего не знаю».
Архиваторы (тот же rar) примерно так же жмут с паролем: вы можете разархивировать файл с любым ключом, просто получите мусор, и CRC32 не сойдётся (а с вероятностью 2^-32 даже сойдётся).
Автору респект, изобрел оооочееень медленный блочный 40-битный шифр с ключем переменной длины
Хотя нет, 100% гарантии того что это блочный шифр нет, т.к. для md5 есть только гарантия того, что для разных 40-битных строк будет отличаться полный хеш, а для первых 40 бит хеша такой гарантии нет.
Так что для некоторых ключей возможно встретится коллизия.
Так что для некоторых ключей возможно встретится коллизия.
Не блочный а поточный, тогда уж (я не зря написал как это обеспечить и указал ссылку на материал в статье). Хотя это алгоритм несколько другого класса, и если вы не понимаете идею, то не обязательно «кричать» об этом.
А «битность» блока не имеет непосредственного значения для криптостойкости в данном случае.
Пусть вы знаете весь шифрованный текст, сможете ли вы получить ключ?
Нет, хоть вы и легко найдете коллизии ключей для отдельных блоков, но задача получения одного правильного ключа сводится к перебору набора символов ключа (тупо обращение хеш-функции).
Пусть вы знаете часть шифрованного текста, можете ли вы получить другие его части?
Даже если они содержат в точности те же знаки, что и известные вам — нет. Т.к. применяется альтернация ключа, и для каждого блока хеш-значение различно.
Если различные — то получить полезную информацию из одного маленького блока даже сложнее чем из «большого», даже при учете что хеш-функции могли бы быть легко обратимы (количество информации в блоке просто недостаточно, чтобы «выбить» весь ключ).
Таким образом, при любом размере блока, пусть даже однобайтном, сложность атаки упирается в возможность строить обратные к хеш-функциям (не коллизии, а именно обратные, при учете что ключ короче выходного значения ф-ции).
А «битность» блока не имеет непосредственного значения для криптостойкости в данном случае.
Пусть вы знаете весь шифрованный текст, сможете ли вы получить ключ?
Нет, хоть вы и легко найдете коллизии ключей для отдельных блоков, но задача получения одного правильного ключа сводится к перебору набора символов ключа (тупо обращение хеш-функции).
Пусть вы знаете часть шифрованного текста, можете ли вы получить другие его части?
Даже если они содержат в точности те же знаки, что и известные вам — нет. Т.к. применяется альтернация ключа, и для каждого блока хеш-значение различно.
Если различные — то получить полезную информацию из одного маленького блока даже сложнее чем из «большого», даже при учете что хеш-функции могли бы быть легко обратимы (количество информации в блоке просто недостаточно, чтобы «выбить» весь ключ).
Таким образом, при любом размере блока, пусть даже однобайтном, сложность атаки упирается в возможность строить обратные к хеш-функциям (не коллизии, а именно обратные, при учете что ключ короче выходного значения ф-ции).
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)).
Относительно пустого результата строгой уверенности при ограниченном переборе 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, но не наоборот, вполне допустимая схема.
«Магия» в данном случае шуточное понятие, думаю, должно быть очевидно.
>Тогда чтобы подсчитать 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, но не наоборот, вполне допустимая схема.
«Магия» в данном случае шуточное понятие, думаю, должно быть очевидно.
Sign up to leave a comment.
Многозначное шифрование с использованием хеш-функций