[esaulenka 5]

2 hours ago, =AK= said:

точно знать как устроен шифр

Кажется, в любом месте, где обсуждается криптография, написано большими буквами "security through obscurity не работает". Все алгоритмы, которыми пользуются большие дяди, 100 раз описаны и 1000 раз исследованы.

 

2 hours ago, =AK= said:

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

Так я и предлагаю вам самостоятельно поэкспериментировать. На тех шифрах, что мне было интересно поковырять, это прекрасно работает (но мне нельзя верить, разумеется).

 

2 hours ago, =AK= said:

Достаточно иметь "средненькую" защиту,

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

 

Впрочем, если Jenya собирался в каждое сообщение добавлять ключ шифрования, ЛЮБОЙ другой вариант поднимает криптостойкость в миллионы раз :-))

[=AK= 10]

21 minutes ago, esaulenka said:

Кажется, в любом месте, где обсуждается криптография, написано большими буквами "security through obscurity не работает".

Вот именно что кажется.

 

Quote

Так я и предлагаю вам самостоятельно поэкспериментировать. На тех шифрах, что мне было интересно поковырять, это прекрасно работает (но мне нельзя верить, разумеется).

Приведите теоретическое обоснование. Ваш личный пример меня не убеждает, ибо бог весть что и как вы ковыряли. И мой личный пример меня тоже не убедит. Такого рода  "доказательство" - явный моветон.

 

[esaulenka 5]

20 minutes ago, =AK= said:

Вот именно что кажется.

Пора сворачивать дискуссию. По этой ссылке именно так и написано - этот принцип работает плохо. С примерами.

 

22 minutes ago, =AK= said:

Приведите теоретическое обоснование.

Точно, пора сворачивать. Дальше выяснится, что у меня нет степени доктора физ-мат наук (действительно нет. Диплом с надписью "инженер" - есть, какой-либо бумаги с надписью "математик" или "криптоаналитик" - нету).

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

[haker_fox 60]

Помнится, год назад Вы обвинили меня в том, что я "влезаю" в любую тему и даю банальные советы. Вот наблюдаю сейчас за Вами и тоже вижу лишь какие-то объяснения на уровне отсебятины. Может быть потрудитесь дать небанальный совет, раз уж начали, подкреплённый техническими знаниями? Мне тема интересна, буду рад посмотреть, как надо давать советы. Ибо пока Вы проигрываете в весе против заслуживающего уважения оппонента в этой теме.

11 minutes ago, esaulenka said:

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

Может быть это и есть "небанальный", а?

[esaulenka 5]

8 minutes ago, haker_fox said:

я "влезаю" в любую тему и даю банальные советы

Последнее время вместо ежедневных "куб авно, я его даже не видел, но так все говорят" вы начали общаться не по теме в "общении". Это можно только приветствовать.

 

10 minutes ago, haker_fox said:

вижу лишь какие-то объяснения на уровне отсебятины

Уж не переход ли это на личности?

 

12 minutes ago, haker_fox said:

Мне тема интересна

Может, вы тогда конкретный вопрос зададите?

[haker_fox 60]

24 minutes ago, esaulenka said:

Уж не переход ли это на личности?

Да. Вы правильно догадались.

24 minutes ago, esaulenka said:

Может, вы тогда конкретный вопрос зададите?

Мне хочется поглядеть на Вас.

[=AK= 10]

On 12/9/2021 at 11:17 PM, esaulenka said:

По этой ссылке именно так и написано - этот принцип работает плохо. С примерами.

Попробуйте убедить в этом военных.   Где вы там углядели столь категоричное утверждение - ума не приложу. Самое близкое что я нашел: "Существует общий консенсус, даже среди тех, кто выступает в пользу безопасности через неясность, что принцип «безопасность через неясность» никогда не должен использоваться в качестве основной меры безопасности." Что совсем не то же самое, что "security through obscurity не работает".

 

Quote

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

Очень расплывчатое объяснение, даже трудно понять, чему там надо верить. А ведь речь идет не о чем-то расплывчато-абстрактном, а о вполне конкретном  LFSR.

 

У 32-битного LFSR с примитивным полиномом есть 2^32 - 1 состояний. Преобразовав потоковый шифр из привычного 8-битного потока в 32-битный, мы, очевидно, не изменим его свойств. А 32-битный LFSR правильно декодирует XOR-ом 32-битное число в одном-единственном состоянии. Поэтому для заданного полинома по заранее известному 32-битному содержимому его состояние определяется однозначно.

 

Однако остается вопрос - а сколько полиномов-то надо перебрать? Для 32-разрядного LFSR Купман рассчитал более 67 миллионов примитивных полиномов, и каждый даст правильную расшифровку 32-битного слова в одном из своих состояний. Так сколько еще бит надо знать, чтобы правильно расшифровать остаток текста? Думаете, "ещё несколько бит" хватит?

 

Эти 67 с лишним миллионов примитивных полиномов, которые, как минимум, все придется перепробовать, это и есть наглядная разница между "открытым и полностью описанным" 32-битным LFSR шифром и 32-битным LFSR шифром по принципу «безопасность через неясность». Который якобы "не работает" или "работает плохо", если вас слушать.

 

Моя бабуля про такие ситуации говорила так: "пошли по шерсть - вернулись бритыми". Судя по всему, у нее с чувством юмора было все в порядке.

[xvr 12]

Конструкция из пары LFSR называется сверточным генератором (shrinking generator) и достаточно проработана в криптографическом плане (первая попавшаяся ссылка - https://www2.seas.gwu.edu/~poorvi/Classes/CS284_2007/ShrinkingGenerator.pdf)

Классический свёрточный генератор попроще, чем у АК - там нет динамической подмены полиномов.

 

Вывод в статье по криптостойкости - достаточно криптостойкий.

 

[artemkad 55]

09.12.2021 в 13:50, esaulenka сказал:

Кажется, в любом месте, где обсуждается криптография, написано большими буквами "security through obscurity не работает".

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

Да, иногда, когда алгоритм криптографии лежит в свободном доступе на множестве ПК, это утверждение верно, но это далеко не всегда так.

[esaulenka 5]

On 12/10/2021 at 3:56 AM, =AK= said:

У 32-битного LFSR с примитивным полиномом есть 2^32 - 1 состояний. Преобразовав потоковый шифр из привычного 8-битного потока в 32-битный, мы, очевидно, не изменим его свойств. А 32-битный LFSR правильно декодирует XOR-ом 32-битное число в одном-единственном состоянии. Поэтому для заданного полинома по заранее известному 32-битному содержимому его состояние определяется однозначно.

Это та же мысль, что я хотел донести, только описанная более "прямым" языком. Спасибо за это.

 

Остались мелочи - разобраться, кто и как будет менять алгоритм шифрования (в частном случае - ваш полином) в устройствах. Вариант 1. Вы лично знаете всех трёх покупателей вашего устройства, и готовы делать для них персональные прошивки, не накосячить при их обновлении, не забыть, что тот же полином должен быть в остальных устройствах, которые взаимодействуют с этим? Отлично, подбираем нужный алгоритм (это отдельные затраты мозговых усилий - подобрать полином, чтобы алгоритм шифрования не выродился во что-то примитивное, но вы явно в теме), получаем плюс N-цать бит для брутфорсера.

Вариант 2. У вас проданы сотня-тысяча-миллион устройств, и следить за всеми в блокноте несколько затруднительно. Делаем какой-то сервис, чтобы клиент мог автоматически это как-то делать. Придумываем процедуру замены, отправку полинома по какому-то более-менее защищённому каналу. Ой, кажется, у нас появился второй secret key. Прямо точно такой же (только с некоторыми ограничениями), надо его объединить с, собственно, ключом. Непонятно, чего мы добились...

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

[jenya7 0]

а если привязатся к МАКу или UNIQUE CPU ID? каждый сможет получить свой уникальный полином, не?

Изменено 14 декабря, 2021 пользователем Herz
Избыточность цитирования

[=AK= 10]

19 hours ago, esaulenka said:

Остались мелочи - разобраться, кто и как будет менять алгоритм шифрования (в частном случае - ваш полином) в устройствах.

Как было сказано ранее, "тот, кто пользуется моим кодом". Подразумевается, что каждый вменяемый пользователь, взявший за основу мой код с Гитхаба, изменит содержимое файла cipher.h: задаст свой ключ шифрования XTEA и полиномы. Для большинства случаев этого достаточно.

 

Если требуется, можно менять шифр в каждом приложении. Для этого ключ XTEA комбинируется из двух ключей. Oдин задается в файле cipher.h, другой сохраняется в EEPROM и задается при помощи хэш-генератора SHA1 при инициализации устройства - генерируется по паролю,  или по имени клиента, или по имени проекта, и т.п.,  дело вкуса, см. https://github.com/akouz/HBus/tree/master/NodeTest

 

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

 

19 hours ago, esaulenka said:

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

Зачем это надо, я из вашего описания так не понял. 

 

 

14 hours ago, jenya7 said:

а если привязатся к МАКу или UNIQUE CPU ID? каждый сможет получить свой уникальный полином, не?

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

[blackfin 22]

On 12/10/2021 at 3:56 AM, =AK= said:

Для 32-разрядного LFSR Купман рассчитал более 67 миллионов примитивных полиномов

Что-то не похоже, что в таблицах koopman'а приведены именно "примитивные полиномы".

 

Примитивный многочлен:

Quote

Because all minimal polynomials are irreducible, all primitive polynomials are also irreducible.

Неприводимый многочлен:

Quote

In mathematics, an irreducible polynomial is, roughly speaking, a polynomial that cannot be factored into the product of two non-constant polynomials.

Меж тем, в таблицах koopman'а полно чётных чисел.

Например, в таблице 32.txt из первых четырех чисел, три являются четными:

Quote

80000057
80000062 <- Чётное
8000007A <- Чётное
80000092 <- Чётное

То есть, полиномы соответствующие этим числам делятся нацело на полином: P(X) = X+0.

 

Кроме того, в последовательности A132447 указано, что первый примитивный полином 31-й степени равен: 2147483657 == 0x80000009.

В то время как в таблице 32.txt koopman'а первое число равно: 0x80000057.

 

Далее, в последовательности A132448 указано, что первый примитивный полином 32-й степени равен: 0x100000000 + 175 = 0x1000000AF.

В то время как в таблице 33.txt koopman'а первое число равно: 0x100000029.

 

И тд.

 

PS. Хм.. Похоже, этот koopman записал свои "примитивные полиномы" шиворот-на-выворот: P(x) = 1+X+X^2+... X^32. 

[esaulenka 5]

On 12/15/2021 at 1:28 AM, =AK= said:

Подразумевается, что каждый вменяемый пользователь, взявший за основу мой код с Гитхаба, изменит содержимое файла cipher.h: задаст свой ключ шифрования XTEA и полиномы

У нас разные "подразумевается". Я подразумеваю, что вменяемый программист без должной подготовки в области криптографии не полезет менять известный и проверенный алгоритм. Замена ключа - ок, это можно и нужно доверить конечному пользователю (правильный алгоритм работает одинаково с любым ключом, главное - чтоб он был достаточно случайным), но в случае изменений алгоритма очень легко накосячить.

 

On 12/15/2021 at 1:28 AM, =AK= said:

Зачем это надо

Попробую другими словами. Вы продаёте одинаковые устройства хорошим пользователям А, Б, Це и плохому Зет. Алгоритм в этих устройствах одинаковый, полином шифрования - тоже (делать по-другому - изрядный геморрой для вас, производителя).

Зет берёт IDA и потрошит весь ваш алгоритм. Данные хороших пользователей теперь защищает только ключ (они же вменяемые пользователи, и установили свой собственный ключ шифрования).

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

[=AK= 10]

2 hours ago, esaulenka said:

У нас разные "подразумевается". Я подразумеваю, что вменяемый программист без должной подготовки в области криптографии не полезет менять известный и проверенный алгоритм. Замена ключа - ок, это можно и нужно доверить конечному пользователю (правильный алгоритм работает одинаково с любым ключом, главное - чтоб он был достаточно случайным), но в случае изменений алгоритма очень легко накосячить.

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

Quote

Попробую другими словами. Вы продаёте одинаковые устройства хорошим пользователям А, Б, Це и плохому Зет. Алгоритм в этих устройствах одинаковый, полином шифрования - тоже (делать по-другому - изрядный геморрой для вас, производителя).

Зет берёт IDA и потрошит весь ваш алгоритм. Данные хороших пользователей теперь защищает только ключ (они же вменяемые пользователи, и установили свой собственный ключ шифрования).

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

Еще одна выковырянная из носа "проблема". Пользователь лезет в Википедию, читает про LFSR, находит полиномы, меняет. Минут на пять работы. Кому не хватает квалификации даже на это - довольствуются сменой ключа ХТЕА или идут пользоваться другими решениями. Даже одна только смена ключа не позволит взломать код никакому рядовому "плохому Зет".

 

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

 

Пока что в этом топике наиболее конструктивным высказыванием, которое довелось от вас услышать, было "пора сворачивать дискуссию" (с)