jenya7 0 5 декабря, 2021 Опубликовано 5 декабря, 2021 · Жалоба On 12/4/2021 at 4:03 AM, artemkad said: При шифровании в сообщение максимум что требуется так это добавить сеансовый ключ - по сути пару байт случайного числа которое используется как часть ключа в текущем сеансе шифрования. Основные ключи хранятся внутри МК и снаружи, естественно, не светятся. В TinyCrypt при AES шифровании требуется добавить дополнительный блок в посылку (TC_AES_BLOCK_SIZE). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 5 декабря, 2021 Опубликовано 5 декабря, 2021 · Жалоба On 12/3/2021 at 12:14 PM, =AK= said: Очень экономный (в смысле используемых ресурсов ресурсов) шифратор/дешифратор находится здесь https://github.com/akouz/HBus/tree/master/HBnodeMiniPro в файлах HBcipher.h и HBcipher.cpp Заточен на пакетные сообщения. Длина сообщения не меняется. Заголовок шифруется блочным шифром XTEA, все остальное - потоковым шифром на базе LFSR. Промежуточный результат шифрования заголовка используется для инициализации LFSR. как то непонятно #define EE_KEY1 0x4C25DC00 #define EE_KEY2 0xBCB2E7DC #define EE_KEY3 0x89EB06AB #define EE_KEY4 0x15227CB7 typedef union __attribute__((aligned(4))) { ulong ulo[4]; uchar uch[16]; } c_union16_t; c_union16_t key; void HBC_get_EE_key(void) { key.uch[0] = EE_KEY1; key.uch[1] = EE_KEY2; key.uch[2] = EE_KEY3; key.uch[3] = EE_KEY4; ////////////////// } ну и конечно Warning[Pe069]: integer conversion resulted in truncation Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 5 декабря, 2021 Опубликовано 5 декабря, 2021 · Жалоба 49 minutes ago, jenya7 said: как то непонятно Спасибо за найденную ошибку. По смыслу должно быть void HBC_get_EE_key(void) { key.ulo[0] = EE_KEY1; key.ulo[1] = EE_KEY2; key.ulo[2] = EE_KEY3; key.ulo[3] = EE_KEY4; // и т.д. } Похоже, что при проверке значения по умолчанию (#ifdef USE_DEFAULT_EE_KEY) я не обратил внимания на предупреждение компилятора. Завтра еще раз проверю и отпишусь. Насколько помню, я в основном тестировал с ключами из EEPROM, полагая, что значения по умолчанию вряд ли будут использоваться на практике. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 5 декабря, 2021 Опубликовано 5 декабря, 2021 · Жалоба 2 hours ago, =AK= said: Насколько помню, я в основном тестировал с ключами из EEPROM, полагая, что значения по умолчанию вряд ли будут использоваться на практике. понял. спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 6 декабря, 2021 Опубликовано 6 декабря, 2021 · Жалоба Исправил файл на Гитхабе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 7 декабря, 2021 Опубликовано 7 декабря, 2021 · Жалоба On 12/6/2021 at 8:45 AM, =AK= said: Исправил файл на Гитхабе. спасибо. а вот интересно насколько сложно крякнуть ключ? я полагаю сегодня хакеры достигли очень высокого уровня. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rkit 4 7 декабря, 2021 Опубликовано 7 декабря, 2021 · Жалоба 5 hours ago, jenya7 said: спасибо. а вот интересно насколько сложно крякнуть ключ? я полагаю сегодня хакеры достигли очень высокого уровня. Невозможно, если нормальный шифр и понимание того, что делаешь. Сегодня шифрование достигло очень высокого уровня, как следовало бы полагать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 8 декабря, 2021 Опубликовано 8 декабря, 2021 · Жалоба 11 hours ago, jenya7 said: спасибо. а вот интересно насколько сложно крякнуть ключ? я полагаю сегодня хакеры достигли очень высокого уровня. Насколько я знаю, шифр XTEA довольно добротный, поэтому крякнуть заголовок непросто. Шифрование тела сообщения потоковым шифром на базе LFSR используется, как я помню, в Блютус. Так что от хакеров, наверное, защита будет более-менее нормальная, хотя бы потому что никому неохота будет связываться если нет известных уязвимостей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 8 декабря, 2021 Опубликовано 8 декабря, 2021 · Жалоба 5 hours ago, =AK= said: Шифрование тела сообщения потоковым шифром на базе LFSR используется, как я помню, в Блютус. А какое отношение LFSR в блютусе имеет к вашему LFSR ? 5 hours ago, =AK= said: защита будет более-менее нормальная, хотя бы потому что никому неохота будет связываться если нет известных уязвимостей. А-а-а, ну тогда да, нормальная защита. По факту ваше "шифрование" взламывается тупым брутфорсом, если знать 32 бита исходного сообщения. 4-байтный ключ перебирается за считанные секунды. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 8 декабря, 2021 Опубликовано 8 декабря, 2021 · Жалоба 3 hours ago, esaulenka said: если знать 32 бита исходного сообщения. 4-байтный ключ перебирается за считанные секунды. Вы о каком 4-байтном ключе? XTEA использует 128-битные ключи. А начальное значение LFSR формируется заново в каждом пакете. То есть, надо заранее знать 32 бита в теле каждого пакета, зашифрованного LFSR, чтобы расшифровать остаток пакета, вы это хотели сказать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 8 декабря, 2021 Опубликовано 8 декабря, 2021 · Жалоба 1 hour ago, =AK= said: То есть, надо заранее знать 32 бита в теле каждого пакета, зашифрованного LFSR, чтобы расшифровать остаток пакета, вы это хотели сказать? Да. И это не такая редкая ситуация, когда кусок плэйн-текста известен. Например, в каждом сообщении передаётся какой-то статус, который злоумышленник знает. Зачем в "типа универсальный" алгоритм закладывать такие грабли, я не понимаю. А, да, у вас LFSR вообще 2 байта (я отвык от 16-битного "uint"). Т.е. для его брутфорса нужны 16..18 бит плэйн-текста и что-то быстрее атмеги. Что там у Jenya, он и сам не знает - то ли вайфай с TCP и JSON-ами, то ли 8-байтовый кан-пакет. В первом случае найти несколько известных байт - задача не особо хитрая... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sorok-odin 5 8 декабря, 2021 Опубликовано 8 декабря, 2021 · Жалоба 20 часов назад, rkit сказал: Невозможно, если нормальный шифр и понимание того, что делаешь. Сегодня шифрование достигло очень высокого уровня, как следовало бы полагать. Уровень может и высокий, а невозможным до сих пор является только одноразовый шифроблокнот длиной не менее длины сообщения. Остальные "нормальные шифры" зависят от степени интереса других к взлому канала, причем не самого алгоритма шифра, а его конкретной косячной реализации. Для неуловимого Джо подойдет любой алгоритм. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 8 декабря, 2021 Опубликовано 8 декабря, 2021 · Жалоба 11 hours ago, esaulenka said: Да. И это не такая редкая ситуация, когда кусок плэйн-текста известен. Конечно, есть пример шифрования DVD (CSS) при помощи двух LFSR, 25 бит и 17 бит, где заранее известно 20 байт в заголовке DVD. В результате чего все Линукс компы это шифрование крякают по умолчанию. Мне как-то очень сомнительно, что такого же резyльтата можно достичь всего по 4 байтам. Это вы сами придумали? Однако шифрование тремя LFSR в GSM и четырьмя LFSR в Блютус крякнуть не так просто, в том числе потому что ничего о содержимом пакетов заранее неизвестно. 11 hours ago, esaulenka said: А, да, у вас LFSR вообще 2 байта (я отвык от 16-битного "uint"). Т.е. для его брутфорса нужны 16..18 бит плэйн-текста и что-то быстрее атмеги. Вы невнимательно смотрели. У меня два LFSR, 32-битный и 16-битный. Гамму создает их комбинация: 16-битный LFSR определяет, как и какие значения 32-битного LFSR используются для гаммы (gamma fetch schedule). Кроме того, в 32-битном LFSR используются два полинома, их на ходу меняет 16-битный LFSR. Все LFSR полиномы выбираются для каждого проекта, их тоже надо как-то угадать при взломе. Так что даже при частично известном сообщении придется использовать что-то гораздо шустрее Атмеги, чтобы расшифровать остаток. Еще вы не учитываете разницу между полностью описанным шифрованием, таким как CSS или Блютус, и "частично описанным", как в моем случае. Того, кто пользуется моим кодом, никто не заставляет использовать его "дословно", ибо никакой совместимости с другими пользователями не требуется. Ничто не мешает изменить хотя бы gamma fetch schedule, после чего кряк опять усложняется на порядки даже для хакера, по какой-то неведомой причине заранее точно знающего, что шифрование основано на моем коде. Ибо нюансы конкретной реализации могут рассматриваться как составная часть шифрования, увеличивающая длину ключа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 9 декабря, 2021 Опубликовано 9 декабря, 2021 · Жалоба 9 hours ago, =AK= said: Вы невнимательно смотрели. У меня два LFSR, 32-битный и 16-битный. Да, вы правы. Претензию снимаю. Пока нвидия не снизила цены на видеокарточки на порядок-другой, можно считать 6-байтовый ключ надёжным - для его взлома в течении минут нужно железо ценой в десятки килобаксов. Правда, можно арендовать это железо - на 5 минут это будет недорого. 9 hours ago, =AK= said: Мне как-то очень сомнительно, что такого же резyльтата можно достичь всего по 4 байтам. Это вы сами придумали? Так проверьте. Берём рандомный ключ, берём кусочек "выхлопа" вашей gamma() и брутфорсим. Про 4 байта я писал, когда (по ошибке) решил, что у вас ключ 4-байтовый. В этом случае с очень высокой долей вероятности (зависит от алгоритма и от расположения звёзд) у вас на выходе брутфорса будет 1-2 ключа. Добавлением буквально одного-двух бит известных данных лишние ключи выкидываются. Для простоты эксперимента можете кусок ключа зафиксировать (с соответствующим уменьшением известного текста). 9 hours ago, =AK= said: Ничто не мешает изменить хотя бы gamma fetch schedule Да ничто не мешает взять ИЗВЕСТНЫЙ алгоритм, которым занимались ИЗВЕСТНЫЕ криптоаналитики. Много занимались, и нарыли уязвимости вроде "если собрать миллион пар plain-cipher, можно уменьшить количество вариантов в 2^5 раз" (т.е., на мой дилетантский взгляд, на практике бесполезные). Нет, вы будете использовать свой велосипед, главное преимущество которого - степень квадратности колёс секретна, и хакеру придётся целый день изучать дизассемблер, чтобы её узнать. Вон, в той же XTEA, что вы используете, алгоритм прописан в википедии. И почему-то никто не предлагает там менять дельту "для увеличения длины ключа". Микро-пример из жизни: достался по наследству проект. Там надо генерировать случайное число. Всё по-настоящему, 32 случайных бита. Только самодельный супер-алгоритм, который это делает, почему-то выдаёт только 256 разных случайных чисел... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 9 декабря, 2021 Опубликовано 9 декабря, 2021 · Жалоба 1 hour ago, esaulenka said: Да, вы правы. Претензию снимаю. Пока нвидия не снизила цены на видеокарточки на порядок-другой, можно считать 6-байтовый ключ надёжным - для его взлома в течении минут нужно железо ценой в десятки килобаксов. Правда, можно арендовать это железо - на 5 минут это будет недорого. За 5 минут, может, и получится, если точно знать как устроен шифр и используемые полиномы LFSR. А без этого - хрен знает сколько раз по 5 минут. Quote с очень высокой долей вероятности (зависит от алгоритма и от расположения звёзд) у вас на выходе брутфорса будет 1-2 ключа. Мне это неочевидно. Их может быть и 100, и 1000. Quote Да ничто не мешает взять ИЗВЕСТНЫЙ алгоритм, которым занимались ИЗВЕСТНЫЕ криптоаналитики. Много занимались, и нарыли уязвимости вроде "если собрать миллион пар plain-cipher, можно уменьшить количество вариантов в 2^5 раз" Можно было и внешний шифратор добавить, можно было и более мощный проц поставить, который бы шифровал чем-то более увесистым. Только зачем из пушки по ворбьям? Я решал конкретную задачу и выбрал для нее оптимальное, на мой взгляд, решение. Quote Нет, вы будете использовать свой велосипед, главное преимущество которого - степень квадратности колёс секретна, и хакеру придётся целый день изучать дизассемблер, чтобы её узнать. Главное преимущество - очень простая реализация. Все в конечном счете определяется деньгами. Нет смысла тратиться на избыточную защиту, если затраты на взлом даже простой защиты не оправдываются. Достаточно иметь "средненькую" защиту, чтобы отбить желание у праздношатающихся кульхацкеров с ней возиться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться