Jump to content

    
jenya7

Шифрование данных

Recommended Posts

On 12/4/2021 at 4:03 AM, artemkad said:

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

В TinyCrypt при AES шифровании требуется добавить дополнительный блок в посылку (TC_AES_BLOCK_SIZE).

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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, полагая, что значения по умолчанию вряд ли будут использоваться на практике.

Share this post


Link to post
Share on other sites
2 hours ago, =AK= said:

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

понял. спасибо.

Share this post


Link to post
Share on other sites
On 12/6/2021 at 8:45 AM, =AK= said:

Исправил файл на Гитхабе.

спасибо. а вот интересно насколько сложно крякнуть ключ?  я полагаю сегодня хакеры достигли очень высокого уровня.

Share this post


Link to post
Share on other sites
5 hours ago, jenya7 said:

спасибо. а вот интересно насколько сложно крякнуть ключ?  я полагаю сегодня хакеры достигли очень высокого уровня.

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

Share this post


Link to post
Share on other sites
11 hours ago, jenya7 said:

спасибо. а вот интересно насколько сложно крякнуть ключ?  я полагаю сегодня хакеры достигли очень высокого уровня.

Насколько я знаю, шифр XTEA довольно добротный, поэтому крякнуть заголовок непросто. Шифрование тела сообщения потоковым шифром на базе LFSR используется, как я помню, в Блютус. Так что от хакеров, наверное, защита будет более-менее нормальная, хотя бы потому что никому неохота будет связываться если нет известных уязвимостей.

Share this post


Link to post
Share on other sites
5 hours ago, =AK= said:

Шифрование тела сообщения потоковым шифром на базе LFSR используется, как я помню, в Блютус.

А какое отношение LFSR в блютусе имеет к вашему LFSR ?

 

5 hours ago, =AK= said:

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

А-а-а, ну тогда да, нормальная защита.

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

Share this post


Link to post
Share on other sites
3 hours ago, esaulenka said:

 если знать 32 бита исходного сообщения. 4-байтный ключ перебирается за считанные секунды.

Вы о каком 4-байтном ключе? XTEA использует 128-битные ключи.  А начальное значение LFSR формируется заново в каждом пакете. То есть, надо заранее знать 32 бита в теле каждого пакета, зашифрованного LFSR, чтобы расшифровать остаток пакета, вы это хотели сказать?

Share this post


Link to post
Share on other sites
1 hour ago, =AK= said:

То есть, надо заранее знать 32 бита в теле каждого пакета, зашифрованного LFSR, чтобы расшифровать остаток пакета, вы это хотели сказать?

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

А, да, у вас LFSR вообще 2 байта (я отвык от 16-битного "uint"). Т.е. для его брутфорса нужны 16..18 бит плэйн-текста и что-то быстрее атмеги.

 

Что там у Jenya, он и сам не знает - то ли вайфай с TCP и JSON-ами, то ли 8-байтовый кан-пакет. В первом случае найти несколько известных байт - задача не особо хитрая...

Share this post


Link to post
Share on other sites
20 часов назад, rkit сказал:

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

Уровень может и высокий, а невозможным до сих пор является только одноразовый шифроблокнот длиной не менее длины сообщения. Остальные "нормальные шифры" зависят от степени интереса других к взлому канала, причем не самого алгоритма шифра, а его конкретной косячной реализации.

Для неуловимого Джо подойдет любой алгоритм.

Share this post


Link to post
Share on other sites

 

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, после чего кряк опять усложняется на порядки даже для хакера, по какой-то неведомой причине заранее точно знающего, что шифрование основано на моем коде. Ибо нюансы конкретной реализации могут рассматриваться как составная часть шифрования, увеличивающая длину ключа.

Share this post


Link to post
Share on other sites
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 разных случайных чисел...

Share this post


Link to post
Share on other sites
1 hour ago, esaulenka said:

Да, вы правы. Претензию снимаю. Пока нвидия не снизила цены на видеокарточки на порядок-другой, можно считать 6-байтовый ключ надёжным - для его взлома в течении минут нужно железо ценой в десятки килобаксов. Правда, можно арендовать это железо - на 5 минут это будет недорого.

За 5 минут, может, и получится, если точно знать как устроен шифр и используемые полиномы LFSR. А без этого - хрен знает сколько раз по 5 минут.

 

Quote

с очень высокой долей вероятности (зависит от алгоритма и от расположения звёзд) у вас на выходе брутфорса будет 1-2 ключа.

 

Мне это неочевидно. Их может быть и 100, и 1000.

 

Quote

Да ничто не мешает взять ИЗВЕСТНЫЙ алгоритм, которым занимались ИЗВЕСТНЫЕ криптоаналитики. Много занимались, и нарыли уязвимости вроде "если собрать миллион пар plain-cipher, можно уменьшить количество вариантов в 2^5 раз"

 

Можно было и внешний шифратор добавить, можно было и более мощный проц поставить, который бы шифровал чем-то более увесистым. Только зачем из пушки по ворбьям? Я решал конкретную задачу и выбрал для нее оптимальное, на мой взгляд, решение.

 

Quote

Нет, вы будете использовать свой велосипед, главное преимущество которого - степень квадратности колёс секретна, и хакеру придётся целый день изучать дизассемблер, чтобы её узнать.

Главное преимущество - очень простая реализация.

 

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.