=AK=

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

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

Попробуйте убедить в этом военных. Где вы там углядели столь категоричное утверждение - ума не приложу. Самое близкое что я нашел: "Существует общий консенсус, даже среди тех, кто выступает в пользу безопасности через неясность, что принцип «безопасность через неясность» никогда не должен использоваться в качестве основной меры безопасности." Что совсем не то же самое, что "security through obscurity не работает". Очень расплывчатое объяснение, даже трудно понять, чему там надо верить. А ведь речь идет не о чем-то расплывчато-абстрактном, а о вполне конкретном LFSR. У 32-битного LFSR с примитивным полиномом есть 2^32 - 1 состояний. Преобразовав потоковый шифр из привычного 8-битного потока в 32-битный, мы, очевидно, не изменим его свойств. А 32-битный LFSR правильно декодирует XOR-ом 32-битное число в одном-единственном состоянии. Поэтому для заданного полинома по заранее известному 32-битному содержимому его состояние определяется однозначно. Однако остается вопрос - а сколько полиномов-то надо перебрать? Для 32-разрядного LFSR Купман рассчитал более 67 миллионов примитивных полиномов, и каждый даст правильную расшифровку 32-битного слова в одном из своих состояний. Так сколько еще бит надо знать, чтобы правильно расшифровать остаток текста? Думаете, "ещё несколько бит" хватит? Эти 67 с лишним миллионов примитивных полиномов, которые, как минимум, все придется перепробовать, это и есть наглядная разница между "открытым и полностью описанным" 32-битным LFSR шифром и 32-битным LFSR шифром по принципу «безопасность через неясность». Который якобы "не работает" или "работает плохо", если вас слушать. Моя бабуля про такие ситуации говорила так: "пошли по шерсть - вернулись бритыми". Судя по всему, у нее с чувством юмора было все в порядке.

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

За 5 минут, может, и получится, если точно знать как устроен шифр и используемые полиномы LFSR. А без этого - хрен знает сколько раз по 5 минут. Мне это неочевидно. Их может быть и 100, и 1000. Можно было и внешний шифратор добавить, можно было и более мощный проц поставить, который бы шифровал чем-то более увесистым. Только зачем из пушки по ворбьям? Я решал конкретную задачу и выбрал для нее оптимальное, на мой взгляд, решение. Главное преимущество - очень простая реализация. Все в конечном счете определяется деньгами. Нет смысла тратиться на избыточную защиту, если затраты на взлом даже простой защиты не оправдываются. Достаточно иметь "средненькую" защиту, чтобы отбить желание у праздношатающихся кульхацкеров с ней возиться.

Конечно, есть пример шифрования DVD (CSS) при помощи двух LFSR, 25 бит и 17 бит, где заранее известно 20 байт в заголовке DVD. В результате чего все Линукс компы это шифрование крякают по умолчанию. Мне как-то очень сомнительно, что такого же резyльтата можно достичь всего по 4 байтам. Это вы сами придумали? Однако шифрование тремя LFSR в GSM и четырьмя LFSR в Блютус крякнуть не так просто, в том числе потому что ничего о содержимом пакетов заранее неизвестно. Вы невнимательно смотрели. У меня два LFSR, 32-битный и 16-битный. Гамму создает их комбинация: 16-битный LFSR определяет, как и какие значения 32-битного LFSR используются для гаммы (gamma fetch schedule). Кроме того, в 32-битном LFSR используются два полинома, их на ходу меняет 16-битный LFSR. Все LFSR полиномы выбираются для каждого проекта, их тоже надо как-то угадать при взломе. Так что даже при частично известном сообщении придется использовать что-то гораздо шустрее Атмеги, чтобы расшифровать остаток. Еще вы не учитываете разницу между полностью описанным шифрованием, таким как CSS или Блютус, и "частично описанным", как в моем случае. Того, кто пользуется моим кодом, никто не заставляет использовать его "дословно", ибо никакой совместимости с другими пользователями не требуется. Ничто не мешает изменить хотя бы gamma fetch schedule, после чего кряк опять усложняется на порядки даже для хакера, по какой-то неведомой причине заранее точно знающего, что шифрование основано на моем коде. Ибо нюансы конкретной реализации могут рассматриваться как составная часть шифрования, увеличивающая длину ключа.

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

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

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

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

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

Потребление было "на уровне", никаких чудес ни в ту ни в другую сторону. В основном все определялось свойствами SOSC генератора, как всегда. Отдельный вход для батареи, при желании, можно было организовать при помощи диодов Шоттки и монтажного ИЛИ. Мне это не требовалось, поскольку все питалось от батареи и ни от чего более.

Генератор SOSC и счетчик имелись во всех (или почти во всех) PIC-ах спокон веков. Но громогласные маркетинговые заявления о "встроенных RTCC" и куча ненужного сгенерированного кода появились сравнительно недавно.

Да, ключи фиксированные, должны быть заранее известны обеим сторонам.

Насколько я понимаю, под "встроенным RTCC" пордразумевается говнокод, сгенерированный МСС (т.е сонфигуратором кода). В железе это просто счетчик и генератор с часовым кварцем.

После десятилетий разного рода боданий и мытарств с RTCC и часовыми кварцами, я стал использовать RTCC со встроенным кристаллом. "Там если щупаешь, то знаешь - маешь вещь" (с)

Очень экономный (в смысле используемых ресурсов ресурсов) шифратор/дешифратор находится здесь https://github.com/akouz/HBus/tree/master/HBnodeMiniPro в файлах HBcipher.h и HBcipher.cpp Заточен на пакетные сообщения. Длина сообщения не меняется. Заголовок шифруется блочным шифром XTEA, все остальное - потоковым шифром на базе LFSR. Промежуточный результат шифрования заголовка используется для инициализации LFSR.

Любой модуль Ардуино, лента на чипах WS2811 и т.п., библиотека управления FastLED. Лента подключается к пину MOSI (т.е. к выходу данных SPI) через резистор порядка 22 Ом. Ардуина Уно или Про в голом виде готова к общению по UART, а Ардуина Леонардо или Нано - по USB через виртуальный СОМ порт. Для подключения через Эзернет придется добавить к Ардуине Эзернет шилд. Как вариант, все то же самое можно сделать на чипе ESP8266, например, модулем NodeMCU. Тогда можно будет общаться с модулем по WiFi. Если взять модуль на базе ESP32, то можно через Блютус. Среда Ардуина имеется и для этих чипов. Пример реализации https://github.com/akouz/HBus/tree/master/Devices/07_Power_Meter

При малом напряжении на выходе ОУ диоды закрыты, они не проводят ток, их динамическое сопротивление стремится к бесконечности. Идеальный ОУ имеет бесконечный коэффициент усиления, при бесконечном сопротивлении в цепи ООС он любой шум будет усиливать до бесконечности. Как только напряжение на выходе ОУ увеличится до порогового напряжения одного из диодов (порядка 0.6 В для обычного кремниевого диода), он начнет открываться, через него начнет течь ток, а его динамическое сопротивление уменьшится до k*T/I*q, что равно примерно равно 25[мВ]/I при комнатной температуре. То есть, при токе через диод 1 мкА его динамическое сопротивление равно примерно 25 кОм, а при токе 1 мА - всего 25 Ом. Величину тока в зависимости от напряжения можно найти по ВАХ диода. Никакого такого "исходного значения" нет. При некотором напряжении на выходе, чуть более 0.6 В, динамическое сопротивление диода станет достаточно низким. При напряжениях существенно больших, чем 0.6В, диод будет открыт настолько хорошо, сопротивление в цепи ООС будет определяться в основном сопротивлением R3, а динамическое сопротивление диода можно уже не учитывать, оно на фоне R3 будет мало. Например при R3=36k и напряжении на выходе 5В, дифф. сопротивление диода составит порядка 200 Ом. Отношение R3/R2 должно быть достаточно маленьким, чтобы полуволна на выходе генератора затухла до того, как выйдет за пределы напряжения питания ОУ. Если R3 слишком увеличить, то ОУ начнет "подрезать" вершинки синусоиды на выходе, ибо он не может выдать напряжение более чем напряжение его собственного питания. Если R3 уменьшать, то амплитуда напряжения на выходе будет стремиться к +- 0.6 В, а форма сигнала все более будет похожа на прямоугольник. Так и не ходите сюда, этот форум не для вас.

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

Вот что выдает гугл на запрос "схема ару". Похоже что врет здесь кто-то другой...

Извините, не понял вопроса. Что за 4 мА, откуда они взялись? При сетевом напряжении 220 V rms амплитуда равна 311 V. При сопротивлении резисторов R21 и R22 по 100 кОм ток через них не может быть больше чем 311V/200к = 1.55 мА. Рассеиваемая мощность примерно равна 220V^2 / 200к = 242 мВт. Если для вас это слишком много, ничто не мешает увеличить R21 и R22 в несколько раз, одновременно во столько же раз уменьшив емкость С8. Например, при R21=R22=330к и C8=0.33uF пиковый ток через резисторы уменьшится до 311V/660к = 0.47 мА. При этом, соответственно, рассеиваемая мощность уменьшится на порядок, а также станет втрое короче выходной импульс.

Прошло 6 лет. Ардуино до сих пор живет и здравствует, а Micro Bit почему-то не видно и не слышно...

Вполне очевидно, что это технически осуществимо. Как и все прочее. Вопрос только в средствах, потраченных на обучение AI.

Недавно мелькала инфа про систему, которая надежно обнаруживает и "ведет" людей по вибрациям пола. Помнится, на основе AI...