Криптостойкость XOR-шифра

M,
хотя нет,
М мало, пусть будет N
и оба реактивные

Я ничего не понял, если честно. Что за N ?

как что, приборы

Хватит стебаться. Я нуб в криптографии.

Шифр вскрывается за константное время. Надо подать на вход открытый текст из нулей, и на выходе получится ключ.

Смотря что за данные. Если это фоточка котика предварительно зашифрованная бесконечным блокнотом, то абсолютная.

Шифр вскрывается за константное время. Надо подать на вход открытый текст из нулей, и на выходе получится ключ.

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

зависит от типа файла

если у файла заголовок соизмерим с ключом, то вообще ниже плинтуса

Смотря что за данные. Если это фоточка котика предварительно зашифрованная бесконечным блокнотом, то абсолютная.

Да, но в моем примере размер блокнота меньше размера фоточки, и блокнот просто повторяется несколько раз

Зависит от данных и аналитика. Человеку с пристреленным глазом твой повторяющийся ксор сразу виден будет.

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

C тем же успехом можешь просто дублировать каждый байт

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

Посоветуйте тогда какой-нибудь модный симметричный шифр, с вменяемой длиной ключа

А зачем ты вообще изобретал, а не взял любой шифр на выбор из openssl?

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

Да, хочется повелосипедить. Спасибо, посмотрю

Я тебе о данных поступающих на вход твоего шифратора. Если это хаос - по нему не восстановишь ключ, даже если твой ключ в один байт.

Криптостойкость такого шифра сравнительно высокая, если перебирать на слабом cpu :). Найти ключ можно только если знать позицию мета-данных таких как jpg-теги, gif, html заголовки и прочее: методом перебора. Если перебирать на сотнях GPU - перебрать/найти ключ не проблема, ключи для xor должны быть огромными, чтобы противостоять такому взлому.
http://en.m.wikipedia.org/wiki/XOR_cipher
Для шифрования своего фотоархива вполне тру AES-256 алгоритм:
http://ru.m.wikipedia.org/wiki/Advanced_Encryption_Standard
Если бы лично я шифровал какие-то данные, чувствительные к приватности, например, фотки летающих тарелок, то использовал бы длину ключа AES как минимум 16 384 байт. Ключ сохранить - не проблема, а вот что за процессорные мощности есть у США - это мало кто знает, но уверен, что колоссальные.

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

Представим, что есть ключ длины M, которым я XOR-ю свои данные, причем размер данных много больше длины ключа, и если дошли до конца ключа, то опять начинаем с его начала.

Частотный анализ щелкает такое как семечки. Придётся для начала идеально отбелить поток данных.

Если использовать ключ только 1 раз, то есть длина ключа больше равна длине текста, то шифр невзламываем. А если больше 1 раза, то взломает даже третьеклассник.

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

Гаммирование... А че, симметричность))) Только вот длинна ключа будет не меньше шифруемых данных. Шифр Вернама ещё никто не скомпрометировал.

Serpent.

в криптотексте будут повторения - значит шифр блочный и просто. криптоаналитик будет брать блоки текста, длиной 1,2,3,4... символов и сравнивать разницы между ними. как только разница резко упадет - вуаля, он нашел длину ключа. а дальше нули на вход.

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

в криптотексте будут повторения - значит шифр блочный и просто. криптоаналитик будет брать блоки текста, длиной 1,2,3,4... символов и сравнивать разницы между ними

какие такие повторения? Сам текст не повторяется ведь.

Если использовать ключ только 1 раз, то есть длина ключа больше равна длине текста, то шифр невзламываем. А если больше 1 раза, то взломает даже третьеклассник.

Посмотрим как третьекласник взломает фоточку, зашифрованную ключом в половину размера фоточки (повторённый два раза).

Ну положим, по заголовку файла он где-то в середине пару байт увидит — и толку?

Посмотрим как третьекласник взломает фоточку, зашифрованную ключом в половину размера фоточки (повторённый два раза).

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

Т.е. исходную фотку он конечно не получит, но догадаться, что на ней, сможет вполне.

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

идиотский вопрос, по-моему. Это вам к Бехтереву и последователям.

Да, но в моем примере размер блокнота меньше размера фоточки, и блокнот просто повторяется несколько раз

в фоточке есть неизвестные(более-менее) данные, а между ними вполне предсказуемые. Тут больше от везения зависит, угадает-ли криптоаналитик формат? Очень возможно — да, т.к. у всех люмии да айподы на три режима, из которых используется один. Ну и как карта ляжет с перекрытием ключа на файл. Ну и ещё нужно посмотреть, что там у современной техники с непредсказуемостью самих данных. Теоретически можно сделать почти идеально, но ведь это никому не нужно, потому как получилось — hz.

Т.е. на практике всё зависит от бюджета. Если бюджет $1000000, то сломают 146%, а если $1, то 146% не сломают.

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

GnuPG

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

плохая криптостойкость, очень. Скажем, настолько плохая, что можно считать, что ее нет.

Если это хаос - по нему не восстановишь ключ, даже если твой ключ в один байт.

даже если 0 бит. Ну вот дам я тебе хаос, и что ты с ним будешь делать?

DES например, хотя он устаревший.

Т.е. исходную фотку он конечно не получит, но догадаться, что на ней, сможет вполне.

у ТСа в облаке Over9000 фоток. Даже артефактов не будет.

Ну я как бы об этом и говорю.

Выглядит это примерно так

Интересоваться сабжем и не узнать Лену? =)

DES например

Лучше уж тогда AES (256)

Ответ зависит от начальных условий. 1. Если криптоаналитик имеет только зашифрованное сообщение (криптограмму), то стойкость составляет М, при условии, что исходное сообщение не содержало избыточности. Если исходное сообщение содержало избыточность (например естественный текст или картинка в bmp), то еще меньше, т.к. вскрывается частотным анализом. 2. Если криптоаналитик знает пару исходное сообщение-криптограмма (или ее часть), то стойкость падает до 0, т.к. ключ восстанавливается обратным XOR. Вобщем следуй совету Шнаера - не пиши сам криптографию, используй готовые шифры и криптобиблиотеки.

Описанный режим шифра называется ECB и подвержен соответствующим атакам.

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

#лоллировал с треда

Лена?

что за лена?

http://en.m.wikipedia.org/wiki/Lenna

Вопрос - какая в данном случае криптостойкость

Никакая. Если есть A xor X и B xor X, то X вычисляется элементарно. Весьма и весьма распространенная ошибка, ахиллесова пята многих и многих криптопротоколов. Если мы знаем A и A xor X, то X тоже вычисляется элементарно.

в зависимости от длины ключа

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

Ради бога не парься, у Бернштейна есть хороший набор алгоритмов с несколькими эталонными реализациями, например tweetnacl.cr.yp.to. Есть сторонние реализации, например, на ява-скрипте.

Лена?

Ага.

то использовал бы длину ключа AES как минимум 16 384 байт.

И сели бы глубоко и надолго.

В Cryptography I на курсэре самая первая лабораторка посвящена взлому такого «шифра». Если поксорить два куска такого шифротекста друг с другом, то результатом будет два поксоренных друг с другом куска открытого текста.

Тут зависит от данных. А вот зависеть от данных в криптографии считается неприлично

И сели бы глубоко и надолго.

можно поподробнее? Что именно запрещено, и в какой стране?

https://ru.wikipedia.org/wiki/Salsa20

В Российской Федерации коммерческая деятельность, связанная с использованием криптографических средств, подлежит обязательному лицензированию. С 22 января 2008 года действует Постановление Правительства РФ от 29 декабря 2007 N 957 «Об утверждении положений о лицензировании отдельных видов деятельности, связанных с шифровальными (криптографическими) средствами», которым приняты Положения о лицензировании деятельности по: - распространению шифровальных (криптографических) средств - техническому обслуживанию шифровальных (криптографических) средств - предоставлению услуг в области шифрования информации - разработке, производству шифровальных (криптографических) средств, защищенных с использованием шифровальных (криптографических) средств информационных и телекоммуникационных систем

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

Следует отметить, что данное Постановление в прилагаемых приложения содержит жесткие требования к лицу — соискателю лицензии, включая его образование, квалификацию, стаж, требования к помещению, охране, информационной и эксплуатационной безопасности при разработке и реализации средств. К примеру, требуется «наличие в штате у соискателя … следующего квалифицированного персонала: руководитель и (или) лицо, уполномоченное руководить работами по лицензируемой деятельности, имеющие высшее профессиональное образование и (или) профессиональную подготовку в области информационной безопасности, а также стаж работы в этой области не менее 5 лет; инженерно-технические работники, имеющие высшее профессиональное образование или прошедшие переподготовку … в области информационной безопасности с получением специализации, необходимой для работы с шифровальными (криптографическими) средствами»

В настоящее время действует так же Приказ ФСБ России от 9 февраля 2005 г. N 66 «Об утверждении положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (положение пкз-2005)», который определяет порядок разработки и эксплуатации криптографических средств.

В частности, согласно приказу, средства криптографии реализуются «юридическим лицом или индивидуальным предпринимателем, имеющим право на осуществление данного вида деятельности, связанного с шифровальными (криптографическими) средствами … вместе с правилами пользования ими, согласованными с ФСБ России».

Подробностей не помню, но там есть какая-то длина ключа, которую вы не имеет права использовать просто как пользователь, а при разработке *своих* алгоритмов шифрования должны идти лицензироваться в ФСБ. Если используете готовую сертифицированную библиотеку в разработке - то там длина ключа не должна превышать какой-то там порог. Немного туту: https://ru.wikipedia.org/wiki/Криптография#.D0.97.D0.B0.D0.BF.D1.80.D0.B5.D1.... дальше сами погуглите.