Хэш со странной закономерностью
Приветствую всех!
Который день борюсь с таким шифром.
Устройство выдает 11 байт. Причем в каждом сеансе разные, но уникальные для данного устройства.
Очередная комбинация строится из предыдущей.
Ну это я так решил, потому как заметил некую закономерность:
между предыдущей и очередной комбинацией повторяется XOR с некими изменениями.
например список XORов, которыми можно "предсказывать" след. комбинацию:
00 88 03 0F 77 7C D8 7C 10 FC C0 07
00 98 00 FC E8 F3 27 F3 60 F0 03 38
00 88 03 0F 77 7C D8 7C 10 FC C0 07
00 D4 00 0C 98 B3 27 73 6F 2C 23 38
00 88 03 0F 77 7C D8 7C 10 FC C0 07
00 98 00 FC E8 F3 27 F3 60 F0 03 38
Но эти "XORы" постепенно "модернизируются", затем снова повторяются... и т.д. Потом можно словить момент повторений XORов, но опять с небольшими изменениями.... Во такая херня....
Для примера список шифрованных последовательностей:
00 BE 7E 0E 2A 1A 12 69 A5 E5 46 7D
00 D6 7D E1 5D 66 CA 15 B5 19 86 7A
00 F2 7D 01 45 2A 32 1A D5 F9 A6 42
00 7A 7E 0E 32 56 EA 66 C5 05 66 45
00 E2 7E F2 DA A5 CD 95 A5 F5 65 7D
00 6A 7D FD AD D9 15 E9 B5 09 A5 7A
.......
Единственное, что прослеживается – это последний байт, меняющийся 4 раза по кругу – 7D-7A-42-45-7D-..... байты XORятся на 0x7 и 0x38
заметил, что все байты сообщения хорятся с результатом 01 или FE блоками по 4
xor = 01
xor = 01
xor = 01
xor = 01
xor = FE
xor = FE
xor = FE
xor = FE
xor = 01
значит, наверное, есть взаимосвязь между всеми байтами сообщения.......
Зациклился на том, что какой такой алгоритм может хэшировать данные так, что XOR между результатом сохраняется равным одному значению????
Спасибо.
Ссылки
[link1] https://www.pgpru.com/faq/kriptografijaobschievoprosy#h37247-13
Нестойкий. Построенный сам на какой-нибудь примитивной комбинации XOR с чем-то.
Ну и FAQ[link1] конечно. Всвязи с сомнительной пользой в помощи в дешифровке алгоритмов от неизвестных устройств.
В каких из известных алгоритмов может сохраняться XOR между байтами шифрованной последовательности???
В
В режиме шифрования ECB, в попытках использовать потоковый шифр вместа хэша (было где-то у Microsoft), да мало ли в чём.
Как я понял – такое явление свойственно только потоковым шифрам? Ну, т.е., по простому говоря, при побайтном шифровании?
Значит мой шифр НЕ будет хэшем? Потому как хэширование подразумевает сложное перемешивание, результат которого исключает "похожесть" комбинаций (не дает мне покоя XOR между байтами шифрованного сообщения)...
Хоть правильно размышляю? Пните в нужную сторону, знающие люди... Спасибо.
Такое явление не свойственно ни потоковым, ни блочным шифрам, если они стойкие и используются в правильном режиме шифрования.
А хэши для шифрования (пока не объявлен победитель конкурса на новый хэш-стандарт) вообще никак не используются.
С вашего позволения продолжу тему.
Удалось определить, что в данной шифрованной части есть счетчик, который инкрементируется в каждой последующей комбинации. Он там есть на 100%. Размерность пока определить не удалось, но 10 бит – это минимум.
Еще одна особенность – XOR между тетрадами всегда равен одному значению – какая-то сумасшедшая корреляция. Соответственно можно сделать вывод, что шифрование вполне может быть потетрадным... но это лишь предположения конечно же...
Вопрос в следующем – каким алгоритмом можно "шифровать" счетчик так, чтобы результат всегда оставался таким коррелированным??? Толкните хотя бы в нужную сторону. На ум ничего толкового не приходит. Спасибо.
Вы все-таки празнайтесь, что вы так ксорите, т.е. приведите пару открытый текст – шифртекст
ну на то он и шифр, чтобы не признаваться.
открытого текста у меня нет – зачем мне нужен был бы тогда весь этот "криптоанализ"??
Еще – почти в каждом бите присутствует составляющая счетчика – т.е., если разложить побитно, то все "битовые столбики" меняются с кратностью от 2 до 512, может и больше.
Мне вот одно интересно: если шифровать XORами счетчик разложив его побитно, причем биты еще и перемешивать между собой (как в данном примере), то как его потом восстановить?
Короче говоря я не силен в криптоанализе, но математику знаю и даже умею мыслить абстрактно. А тут я в реальном ступоре – что-то крутиться в голове, а как применить к данной ситуации не пойму...
Вы тут люди разумные – хоть пните в нужную сторону – может к какому-нибудь методу кого-нить известного человека это относиться – дальше я уж сам...
Чтобы восстановить выход XOR, надо наложить гамму, т.е. ещё раз поксорить с ключевой последовательностью, вы это спрашивали? Если все ваши преобразования обратимы, то выполнением их в обратном порядке вы восстановите открытый текст.
Возможно я неправильно выразился.
Поскольку счетчик инкрементируется на 1, то соответственно в тексте меняется только один бит, а после шифрования не меньше половины – это хорошо прослеживается после разложения всех байтов на биты. Причем биты счетчика "перемешаны" в шифротексте во всех тетрадах. НО!!! Почему и, главное, как сохраняется корреляция? – т.е. XOR между всеми тетрадами ВСЕГДА равен одному значению. Что ж это за метод такой?
Если то значит эта часть исходного текста не "перемешивается" перед XORом, правда же? Или блок (часть блока) XORится сам с собой, например, или ещё что либо. По каким причинам это происходит – нельзя сказать не зная алгоритма, да ещё при отсутствии ОТ-ШТ.
Исходный текст – счетчик преобразуется в какой-то хаос как-то очень линейно.
ну например: (^ – xor "по Си-шному")
0001 – AB CD EF GH – причем A^B°C^D^E°F^G^H = CONST
0010 – IJ KL MN OP – причем I^J°K^L^M^N^O^P = CONST
0011 – QR ST UV WX – причем Q^R^S^T^U^V^W^X = CONST
На входе разное кол-во бит – на выходе корреляция. Допустим есть таблица – по ней меняем, XOR-им – итого шифруем – получаем все эти A....X на выходе. Как тогда осуществить обратное преобразование? Думаю, если "намешать" между собой A...H, то получится какой-то хэш, который нельзя будет расшифровать. Но он-то расшифровывается......
есть еще мысль, что среди байт шифротекста есть контрольная сумма, которая получается тем же XOR-ом остальных байт – вот тогда будет корреляция.... соответственно ход мыслей нужно изменять....