банальный xor, продолжение :)

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

 

Hryukin
Учи алгоритмы.

А криптосистемы построенные на эллиптических кривых? Ладно фиг с ними с эллиптическими кривыми. Мало кто вообще ими умеет пользоваться а уж тем более на ассемблере.

Взять хотя бы RSA.
Есть публичный ключ - открытый
Есть секретный ключ - закрытый

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

На вход процедуры можешь подавать все что твоей душе угодно и смотреть что получилось на выходе.

А вот попробуй-ка теперь по этим данным определить секретный ключ.
Главное в этой задаче окончательно не свернуть себе мозги.

А ведь это константы. Представляешь

 

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

 

2 all во первых я не защищаю алгоритм xor, не собираюсь его использовать и все его дырки мне давно известны. Да xor слаб, но только при определенных условиях, а при дугих определенных условиях оказывается что с ним ничего не поделаешь

Я пытаюсь разобраться в проблеме восстановления открытых данных! Давайте концентрироваться на этом.

2 Miller Rabin

xor (как и большинство потоковых шифров) не применим для шифрования объектов файловой системы, однако встречаются ситуации типа этой: какой-нибудь первокурсник заксорил важные файлы, переименовал и изменил расширение, задача - восстановить данные. И что ты будешь делать?

Почитай про архитектуру потоковых шифров. Грубо говоря, они представляют собой xor + генератор безразмерного (в идеале) ключа. Отсюда ситуация №2: ты перехватил канал данных, фактически ты стал обладателем с1, с2, с3 ... задача - определить открытые данные.

Полная ерунда. Почитай про применение потоковых шифров!

Вообще-то мы говорим здесь про xor слегка затрагивая потоковые шифры

А вот попробуй-ка написать rsa на асме и запихнуть все это в смарткарту, думаю процесс шифрования займет столько же времени сколько и восстановление секретного ключа )) Смешно слышать про rsa от человека, который ничего не может поделать с простым xor-ом

Если у тебя нет реального способа восстановить данные "защищенные" (даже странно произносить XOR-ом это еще не повод говорить, что xor-детский лепет.

2 Dimson

)) респект

 

Мои 5 копеек.

В любом учебнике написано, что потоковый шифр с данным ключом и IV должен использоваться только ОДИН раз. Т.е. на данной гамме должен быть зашифрован только один открытыый текст. Это фундаментальное требование, и его нарушение сущесвенно снижает стойксоть системы.

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

Единственное такое условие -- однократное использование гаммы, размер которой равен размеру открытого текста. Одноразовый блокнот называется. Все остальные способы применения меют те или иные уязвимости.

 

userx
Знаешь, меня разозлил твой последний пост. А это нарушает общую гармонию и вообще это как-то не по-дзенски
Если ты знаешь все слабости xor, то я не понимаю зачем ты вообще создал этот топик.

Я не представляю что ты вообще можешь восстановить с таким узким взглядом на вещи.
Ты сейчас и есть тот первокурсник, "который заксорил важные данные с помощью генератора безразмерного (в идеале) ключа, переименовал и изменил расширение"
А теперь ищет способ эти данные восстановить.

С тем же успехом можно применить знаменитый алгоритм "IceBars'a - Фон Неймана" архивирования файла в 0 байт.
Иными словами если ты еще эти файлы заархивируешь, ты не только обеспечишь колоссальный уровень безопасности при огромном уровне быстродействия с помощью простого xor, но еще значительно сэкономишь место на "смарткарте".

Прочитай, пожалуйста, ВНИМАТЕЛЬНО мой пост, который #20. Не через строчку, как ты это обычно делаешь, а ВНИМАТЕЛЬНО.
Некоторые моменты я, видимо, не разжевал столь тщательно. Поэтому из-за маленького опыта в системах шифрования ты не смог уловить, что я тебе пытаюсь объяснить.

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

В защищенном канале данных когда ты шифруешь данные на одном конце, то на другом конце их должны как минимум расшифровать (Ты со своим безразмерным генератором ключа упорно игнорируешь этот факт. Пусть, типа этим хакеры занимаются). Это значит, что должна быть формула, связывающая p1, p2, ...pn, либо они должны быть заданы статично. И должен быть механизм синхронизации, гарантирующий что на обоих концах ключ будет одним и тем же. И то и другое содержится в исходном коде приложения, КОТОРОЕ ОБЩЕДОСТУПНО и если понадобится будет использовано ПРОТИВ ТЕБЯ ЖЕ. Криптостойкость РЕАЛЬНОГО алгоритма, в отличие от алгоритма на бумаге, определяется тем, что даже получив все необходимые данные из исполняемого файла расшифровать данные все равно будет очень тяжело. Как это делается с твоим xor я уже объяснял. см. #20

Dimson
Использование систем защиты исполняемых файлов от отладки для обеспечения криптостойкости используемого в нем алгоритма является ярким примером "Безопасности по-страусинному". Такая стратегия была очень популярна в 80-х годах и обеспечила веселый провал немалому числу защищенных систем.

userx

Систему электронных подписей по RSA на ассемблере я реализовал еще 4 года назад. Сейчас я работаю над более серьезными проектами. Скажу больше я программирую ТОЛЬКО на ассемблере, я не пользуюсь языками высокого уровня.

см. Пост #20

 

Господа, меньше флуда, больше практики. Алгоритмы, алгоритмы, алгоритмы! Давайте будет перебирать все на пальцах и кубиках. Теория известна всем, но практические примеры никто почему-то не выкладывает (исключение ASCII в теме "банальный xor" и DBF от gazlan ).

 

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

 

Miller Rabin

Да что Вы говорите? Неужели? Какое безобразие... Кстати, если мне не изменяет зрение и память, то про защиту от отладки я ничего не писал. Ну, раз пошла такая тема, то то, о чем Вы говорите, скорее всего верно. Есть работа, в которой это математически доказано (доказано то, что свойство Black-Box в общем случае для запутанного кода и данных невыполнимо). Есть критические замечания к этой работе. Однако, вопросы о практической пользе обфускации (это наверное то, что Вы имели в виду), оценке стойкости ряда алгоритмов этой самой обфускации, выборе подпрограмм, которые "можно запутывать" остаются все-еще открытыми. Это во-первых. Во вторых: а почему, интересно знать, если все так печально, очень многие разработчики программных защит (и весьма стойких надо сказать) тем не менее применяют такие методики?
Извиняюсь за флуд.

 

Вообще этот текст можно расшифровать в любую последовательность байт той же длины - одноразовый блокнот
Но что-то подсказывает, что текстом была фраза "Rabin Miller", а ключом байт 01h

 

roman_pro
Интуиция - великая вещь!