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

[jenya7 0]

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

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

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

[jenya7 0]

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= 0]

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]

2 hours ago, =AK= said:

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

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

[=AK= 0]

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

[jenya7 0]

On 12/6/2021 at 8:45 AM, =AK= said:

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

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

[rkit 0]

5 hours ago, jenya7 said:

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

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

[=AK= 0]

11 hours ago, jenya7 said:

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

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

[esaulenka 0]

5 hours ago, =AK= said:

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

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

 

5 hours ago, =AK= said:

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

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

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

[=AK= 0]

3 hours ago, esaulenka said:

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

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

[esaulenka 0]

1 hour ago, =AK= said:

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

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

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

 

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

[sorok-odin 0]

20 часов назад, rkit сказал:

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

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

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

[=AK= 0]

 

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 0]

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= 0]

1 hour ago, esaulenka said:

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

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

 

Quote

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

 

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

 

Quote

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

 

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

 

Quote

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

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

 

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