Хэш со странной закономерностью
Приветствую всех!
Который день борюсь с таким шифром.
Устройство выдает 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 между результатом сохраняется равным одному значению????
Спасибо.
комментариев: 9796 документов: 488 редакций: 5664
Нестойкий. Построенный сам на какой-нибудь примитивной комбинации XOR с чем-то.
Ну и FAQ конечно. Всвязи с сомнительной пользой в помощи в дешифровке алгоритмов от неизвестных устройств.
комментариев: 6 документов: 1 редакций: 0
комментариев: 9796 документов: 488 редакций: 5664
В
В режиме шифрования ECB, в попытках использовать потоковый шифр вместа хэша (было где-то у Microsoft), да мало ли в чём.
комментариев: 6 документов: 1 редакций: 0
Как я понял – такое явление свойственно только потоковым шифрам? Ну, т.е., по простому говоря, при побайтном шифровании?
Значит мой шифр НЕ будет хэшем? Потому как хэширование подразумевает сложное перемешивание, результат которого исключает "похожесть" комбинаций (не дает мне покоя XOR между байтами шифрованного сообщения)...
Хоть правильно размышляю? Пните в нужную сторону, знающие люди... Спасибо.
комментариев: 9796 документов: 488 редакций: 5664
А хэши для шифрования (пока не объявлен победитель конкурса на новый хэш-стандарт) вообще никак не используются.
Удалось определить, что в данной шифрованной части есть счетчик, который инкрементируется в каждой последующей комбинации. Он там есть на 100%. Размерность пока определить не удалось, но 10 бит – это минимум.
Еще одна особенность – XOR между тетрадами всегда равен одному значению – какая-то сумасшедшая корреляция. Соответственно можно сделать вывод, что шифрование вполне может быть потетрадным... но это лишь предположения конечно же...
Вопрос в следующем – каким алгоритмом можно "шифровать" счетчик так, чтобы результат всегда оставался таким коррелированным??? Толкните хотя бы в нужную сторону. На ум ничего толкового не приходит. Спасибо.
комментариев: 6 документов: 1 редакций: 0
открытого текста у меня нет – зачем мне нужен был бы тогда весь этот "криптоанализ"??
Еще – почти в каждом бите присутствует составляющая счетчика – т.е., если разложить побитно, то все "битовые столбики" меняются с кратностью от 2 до 512, может и больше.
Мне вот одно интересно: если шифровать XORами счетчик разложив его побитно, причем биты еще и перемешивать между собой (как в данном примере), то как его потом восстановить?
Короче говоря я не силен в криптоанализе, но математику знаю и даже умею мыслить абстрактно. А тут я в реальном ступоре – что-то крутиться в голове, а как применить к данной ситуации не пойму...
Вы тут люди разумные – хоть пните в нужную сторону – может к какому-нибудь методу кого-нить известного человека это относиться – дальше я уж сам...
Чтобы восстановить выход XOR, надо наложить гамму, т.е. ещё раз поксорить с ключевой последовательностью, вы это спрашивали? Если все ваши преобразования обратимы, то выполнением их в обратном порядке вы восстановите открытый текст.
комментариев: 6 документов: 1 редакций: 0
Возможно я неправильно выразился.
Поскольку счетчик инкрементируется на 1, то соответственно в тексте меняется только один бит, а после шифрования не меньше половины – это хорошо прослеживается после разложения всех байтов на биты. Причем биты счетчика "перемешаны" в шифротексте во всех тетрадах. НО!!! Почему и, главное, как сохраняется корреляция? – т.е. XOR между всеми тетрадами ВСЕГДА равен одному значению. Что ж это за метод такой?
комментариев: 6 документов: 1 редакций: 0
ну например: (^ – 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, то получится какой-то хэш, который нельзя будет расшифровать. Но он-то расшифровывается......
комментариев: 6 документов: 1 редакций: 0