Предлагаю провести known plaintext атаку на этот шифр. Я зашифровал 102400 нулевых байтов на каком-то ключе - вот результат (зеркало). Ваша задача вычислить мой ключ (int64). P.S. Задача имеет эффективное (непереборное) решение.
Seichas glianem... Mne interesno, a chto tam delayetsa algoritmu kogda uint64 * 2310 perepolniayetsa? Na perviy vzgliad algoritm ochen OCHEN deshoviy. Suka v C++ napisan, no vsio ravno seichas trahnem. RElf, a ti smozhesh zashifrovanniy RAR, JPEG ili GIF slomat? Ruptor
Prisoyediniayus k RElfu. Prisilaite kakiye ugodno files skolko ugodno raz zashifrovanniye etim "shifrom". Yesli oni dostatochno bolshiye, to dazhe known plaintext ne nado i dazhe format file ne nado ukazivat. Hot JPEG, hot ZIP, hot MP3...
RElf Зачем тебе это нужно? Ну я смог придумать быстрый алгоритм определения ключа где-то минут за 10. Но писать программу сейчас влом. Сейчас используются алгоритмы следующего вида: x_0=k (ключ) x_n+1=Ax_n, b_n=f(x_n). b_n - выходная последовательность. x_i - булевы вектора. f - булева функция.
Зачем нужно - разминка для мозгов. "писать программу сейчас влом" как решение не засчитывается. А, может, твой алгоритм ошибочен. Так что, уж будь добр программу написать и ключик вычислить.
RElf если уж хочешь разминку для мозгов - сломай вот этот шифр: c=t xor key xor key[key]+key[key+key[key]]. key - ключ, t-text, c-cipher. длинна ключа 128 байт
некоторые дополнения - алгос полностью выглядит так: a=key; b=key+key[key]; <if key>127> { a=key mod 127; } <if key+key[key>127> { b=key*key[key mod 127; } c=(t xor key xor key[a])+key;
flankerx не согласен: по известному тексту - шифровки обычно ищут ключ, а потом его юзают для взлома оставшегося шифра. infern0 это откуда? --------------------- а ясно, но по этой формуле одназначно ключ можно выщимить перебором. 2^1024 вариантов не ахти как мало, к тому же, есть ложные ключи и они вовсе не облегчают задачу. добавив ещё трансформацию ключа, мы получим весьма надёжный шифр.
UbIvItS А зачем находить ключ в первоначальном варианте? Как видно из кода шифра, у него имеется ключ key' = F(key), после чего зашифрование выглядит как c= t ^ key', значит key' = t ^ c. Следовательно нам надо иметь равное длине ключа количество плейнтекста чтобы вскрыть шифр не находя изначальный ключ.
hwegh вообще-то формула выглядит так: c=(t xor a) +b. как ты отшелушишь a & b(??) - сложение и ксор разные вещи.
UbIvItS Запарил Давай килобайт плейнтекста, килобайт шифртекста и код на C, который выполняет твое преобразование.
flankerx о реальный разговор - Уважаю. вот тебе алгос криптора: Код (Text): i=-1; while(abs(++i)<num_read) { buff_initial_file[i]+=buff_crypto_key[i]; buff_initial_file[i]^=buff_crypto_key[buff_crypto_key[i]/2]; } ключ статичен, длинна 128 байт, файл текст одной из моих любимых книг, первые 1024 байт найдёшь в архиве: http://depositfiles.com/files/2032796 и там же шифровка. Удачи в бою, Воин Кода !!!!!!!!!!!!!!!!!
ЧТо-то начало плейнтекста странновато выглядит. Выложи все же полный исходник программки, а то не все понятно...
hwegh ты оскорбляешь сам себя такими жалобами... flankerx такие претензии не принимаю - там то, что в начальном файле........ всё остальное в проге не имеет значение - у тебя в руках криптор и часть известного текста.......... взломщику больше не нужно. Зы. алгос со стат. ключом чуть надёжней ксора...... считай это за мою подсказку.
Надо выкладывать там, откуда можно скачать. Я уже давно прогу для слома сделал, а твоих файлегов достать не могу. Так что хрен с ними, имхо с тебя хватит кода: Поиск ключа: Код (Text): for (i = 0; i < 128; i++) { for (k1 = 0; k1 < 256; k1++) { for (k2 = 0; k2 < 256; k2++) { eqt = 1; for (x = 0; x < 3; x++) { idx = (128 * x) + i; if ( crypt[idx] != ((playn[idx] ^ k1) + k2) ) { eqt = 0; break; } } if (eqt != 0) { key1[i] = k1; key2[i] = k2; goto kfnd; } } } kfnd:; } Дешифрование по ключу: Код (Text): for (i = 0; i < length; i++) { idx = (i % 128); playn[i] = ((crypt[i] - key2[idx]) % 256) ^ key1[idx]; }
UbIvItS Это не так. Там тот же текст, но в DOS-кодировке. Это принципиально. И предоставление "левых" данных — это проявление неуважения к hwegh и ко мне. Несколькими постами выше ты убеждал всех что твой алгоритм имеет стойкость около 2^1024. Так чему же верить-то? А на момент "подсказки" как минимум у двух людей был рабочий код разлома твоего алгоритма, который не работал по причинам, изложенным выше. Твой алгоритм не тянет на шифрование вообще. Его стойкость при самой тупой реализации перебора стсавляет 2^16 на каждый байт ключа. Более того, приведенный тобой шифртекст можно сломать вообще без плейнтекста, т.к. твой шифр сохраняет статистику исходного сообщения, и является он по сути полиалфавитным шифром побайтовой замены с кол-вом алфавитов 128. В общем, забей на криптографию и займись чем-нибудь, что у тебя получается лучше.