=AK=
-
Постов
3 234 -
Зарегистрирован
-
Посещение
-
Победитель дней
5
Сообщения, опубликованные =AK=
-
-
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-битных.
-
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 шифром по принципу «безопасность через неясность». Который якобы "не работает" или "работает плохо", если вас слушать.
Моя бабуля про такие ситуации говорила так: "пошли по шерсть - вернулись бритыми". Судя по всему, у нее с чувством юмора было все в порядке.
-
21 minutes ago, esaulenka said:
Кажется, в любом месте, где обсуждается криптография, написано большими буквами "security through obscurity не работает".
Вот именно что кажется.
QuoteТак я и предлагаю вам самостоятельно поэкспериментировать. На тех шифрах, что мне было интересно поковырять, это прекрасно работает (но мне нельзя верить, разумеется).
Приведите теоретическое обоснование. Ваш личный пример меня не убеждает, ибо бог весть что и как вы ковыряли. И мой личный пример меня тоже не убедит. Такого рода "доказательство" - явный моветон.
-
1 hour ago, esaulenka said:
Да, вы правы. Претензию снимаю. Пока нвидия не снизила цены на видеокарточки на порядок-другой, можно считать 6-байтовый ключ надёжным - для его взлома в течении минут нужно железо ценой в десятки килобаксов. Правда, можно арендовать это железо - на 5 минут это будет недорого.
За 5 минут, может, и получится, если точно знать как устроен шифр и используемые полиномы LFSR. А без этого - хрен знает сколько раз по 5 минут.
Quoteс очень высокой долей вероятности (зависит от алгоритма и от расположения звёзд) у вас на выходе брутфорса будет 1-2 ключа.
Мне это неочевидно. Их может быть и 100, и 1000.
QuoteДа ничто не мешает взять ИЗВЕСТНЫЙ алгоритм, которым занимались ИЗВЕСТНЫЕ криптоаналитики. Много занимались, и нарыли уязвимости вроде "если собрать миллион пар plain-cipher, можно уменьшить количество вариантов в 2^5 раз"
Можно было и внешний шифратор добавить, можно было и более мощный проц поставить, который бы шифровал чем-то более увесистым. Только зачем из пушки по ворбьям? Я решал конкретную задачу и выбрал для нее оптимальное, на мой взгляд, решение.
QuoteНет, вы будете использовать свой велосипед, главное преимущество которого - степень квадратности колёс секретна, и хакеру придётся целый день изучать дизассемблер, чтобы её узнать.
Главное преимущество - очень простая реализация.
Все в конечном счете определяется деньгами. Нет смысла тратиться на избыточную защиту, если затраты на взлом даже простой защиты не оправдываются. Достаточно иметь "средненькую" защиту, чтобы отбить желание у праздношатающихся кульхацкеров с ней возиться.
-
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, после чего кряк опять усложняется на порядки даже для хакера, по какой-то неведомой причине заранее точно знающего, что шифрование основано на моем коде. Ибо нюансы конкретной реализации могут рассматриваться как составная часть шифрования, увеличивающая длину ключа.
-
3 hours ago, esaulenka said:
если знать 32 бита исходного сообщения. 4-байтный ключ перебирается за считанные секунды.
Вы о каком 4-байтном ключе? XTEA использует 128-битные ключи. А начальное значение LFSR формируется заново в каждом пакете. То есть, надо заранее знать 32 бита в теле каждого пакета, зашифрованного LFSR, чтобы расшифровать остаток пакета, вы это хотели сказать?
-
11 hours ago, jenya7 said:
спасибо. а вот интересно насколько сложно крякнуть ключ? я полагаю сегодня хакеры достигли очень высокого уровня.
Насколько я знаю, шифр XTEA довольно добротный, поэтому крякнуть заголовок непросто. Шифрование тела сообщения потоковым шифром на базе LFSR используется, как я помню, в Блютус. Так что от хакеров, наверное, защита будет более-менее нормальная, хотя бы потому что никому неохота будет связываться если нет известных уязвимостей.
-
Исправил файл на Гитхабе.
-
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, полагая, что значения по умолчанию вряд ли будут использоваться на практике.
-
39 minutes ago, artemkad said:
При шифровании в сообщение максимум что требуется так это добавить сеансовый ключ - по сути пару байт случайного числа которое используется как часть ключа в текущем сеансе шифрования. Основные ключи хранятся внутри МК и снаружи, естественно, не светятся.
Подозреваю, что тот же результат достигается при помощи nonce, т.е поля в заголовке (в моем случае одного байта) со случайным значением. В результате повторяющиеся сообщения будут выглядеть совершенно разными.
-
43 minutes ago, rx3apf said:
А как у них (тех, что "спокон веков") с потреблением генератор и с отдельным входом батареи подпитки ? Про такой уж сервис, как именно счетчик RTC с календарем уж и говорить не приходится...
Потребление было "на уровне", никаких чудес ни в ту ни в другую сторону. В основном все определялось свойствами SOSC генератора, как всегда. Отдельный вход для батареи, при желании, можно было организовать при помощи диодов Шоттки и монтажного ИЛИ. Мне это не требовалось, поскольку все питалось от батареи и ни от чего более.
-
3 minutes ago, Herz said:
Именно. Отменяющие необходимость во внешней микросхеме, типа той же DS3231, и коммуникации с ней. К говнокодам это не имеет отношения.
Генератор SOSC и счетчик имелись во всех (или почти во всех) PIC-ах спокон веков. Но громогласные маркетинговые заявления о "встроенных RTCC" и куча ненужного сгенерированного кода появились сравнительно недавно.
-
1 minute ago, jenya7 said:
спасибо. то есть в пакет не добавляется ключ? обе стороны имеют его уже сгенерированный?
Да, ключи фиксированные, должны быть заранее известны обеим сторонам.
-
On 12/2/2021 at 1:41 AM, Herz said:
На оффсайте упоминаются PIC-и со встроенным RTCC,
Насколько я понимаю, под "встроенным RTCC" пордразумевается говнокод, сгенерированный МСС (т.е сонфигуратором кода). В железе это просто счетчик и генератор с часовым кварцем.
-
После десятилетий разного рода боданий и мытарств с RTCC и часовыми кварцами, я стал использовать RTCC со встроенным кристаллом. "Там если щупаешь, то знаешь - маешь вещь" (с)
-
On 7/29/2021 at 3:33 PM, jenya7 said:
У меня связь <ПК - модуль> по WIFI. Нужно шифровать посылаемые сообщения. Посоветуйте проверенную библиотеку шифрования данных чтоб бежала и на компе и на микроконтролере.
Очень экономный (в смысле используемых ресурсов ресурсов) шифратор/дешифратор находится здесь https://github.com/akouz/HBus/tree/master/HBnodeMiniPro в файлах HBcipher.h и HBcipher.cpp
Заточен на пакетные сообщения. Длина сообщения не меняется. Заголовок шифруется блочным шифром XTEA, все остальное - потоковым шифром на базе LFSR. Промежуточный результат шифрования заголовка используется для инициализации LFSR.
-
On 11/23/2021 at 9:33 PM, dukvbg said:
Необходимо при помощи цветной светодиодной ленты визуализировать и выводить анимацию прогресс бара.
Предполагается использовать 12В RGB (SPI RGB) ленту IP65-IP68 (так как лента будет на улице).
Необходимо управлять этой самой лентой с промышленного ПК на котором крутится Linux (доступные интерфейсы: Ethernet, RS-232, USB (не хотелось бы,USB) ).
В сферическом вакууме, это самая лента через какой-то покупной контроллер с интерфейсом а-ля Ethernet/RS-232/USB подключается к ПК и программа крутящаяся на ПК уже управляет самой лентой.
Все варианты которые я находил (наверняка плохо искал) подразумевают использование уже готовых программ различных анимаций, либо просто управление с пульта.
не могли подсказать такие контроллеры?
Любой модуль Ардуино, лента на чипах WS2811 и т.п., библиотека управления FastLED. Лента подключается к пину MOSI (т.е. к выходу данных SPI) через резистор порядка 22 Ом.
Ардуина Уно или Про в голом виде готова к общению по UART, а Ардуина Леонардо или Нано - по USB через виртуальный СОМ порт. Для подключения через Эзернет придется добавить к Ардуине Эзернет шилд.
Как вариант, все то же самое можно сделать на чипе ESP8266, например, модулем NodeMCU. Тогда можно будет общаться с модулем по WiFi. Если взять модуль на базе ESP32, то можно через Блютус. Среда Ардуина имеется и для этих чипов.
Пример реализации https://github.com/akouz/HBus/tree/master/Devices/07_Power_Meter
-
On 12/2/2021 at 6:42 AM, Bonifacy said:
Если по каким-либо причинам амплитуда напряжения на выходе Uвых увеличилась
При малом напряжении на выходе ОУ диоды закрыты, они не проводят ток, их динамическое сопротивление стремится к бесконечности. Идеальный ОУ имеет бесконечный коэффициент усиления, при бесконечном сопротивлении в цепи ООС он любой шум будет усиливать до бесконечности.
Как только напряжение на выходе ОУ увеличится до порогового напряжения одного из диодов (порядка 0.6 В для обычного кремниевого диода), он начнет открываться, через него начнет течь ток, а его динамическое сопротивление уменьшится до k*T/I*q, что равно примерно равно 25[мВ]/I при комнатной температуре. То есть, при токе через диод 1 мкА его динамическое сопротивление равно примерно 25 кОм, а при токе 1 мА - всего 25 Ом. Величину тока в зависимости от напряжения можно найти по ВАХ диода.
On 12/2/2021 at 6:42 AM, Bonifacy said:В результате выходное напряжение уменьшится, возвратившись к исходному значению.
Никакого такого "исходного значения" нет. При некотором напряжении на выходе, чуть более 0.6 В, динамическое сопротивление диода станет достаточно низким. При напряжениях существенно больших, чем 0.6В, диод будет открыт настолько хорошо, сопротивление в цепи ООС будет определяться в основном сопротивлением R3, а динамическое сопротивление диода можно уже не учитывать, оно на фоне R3 будет мало. Например при R3=36k и напряжении на выходе 5В, дифф. сопротивление диода составит порядка 200 Ом.
Отношение R3/R2 должно быть достаточно маленьким, чтобы полуволна на выходе генератора затухла до того, как выйдет за пределы напряжения питания ОУ. Если R3 слишком увеличить, то ОУ начнет "подрезать" вершинки синусоиды на выходе, ибо он не может выдать напряжение более чем напряжение его собственного питания. Если R3 уменьшать, то амплитуда напряжения на выходе будет стремиться к +- 0.6 В, а форма сигнала все более будет похожа на прямоугольник.
17 hours ago, Bonifacy said:Веду сейчас некий ТОП форумов и пока этот форум в самом низу, тут меня и слали книги читать, и разбираться неделями, и угарали, теперь вот вы такой умный видимо, что не можете понять, что я понял а что нет
Так и не ходите сюда, этот форум не для вас.
-
23 hours ago, Bonifacy said:
По запросу можно увидеть схемы похожие на мою
Даже похожие схемы могут работать на разных принципах. Например, известная фирма Хьюлетт-Паккард "поднялась" в 40-е годы прошлого века за счет звукового генератора, представляющего собой в принципе похожую схему, но собранную на лампах. Нюанс был в том, что вместо нелинейного элемента использовалась маленькая лампочка накаливания. Как известно, сопротивление металлов увеличивается при увеличении температуры. В созданной Хьюлеттом схеме лампочка накаливания входила в цепь обратной связи в генераторе Винна. При увеличении аплитуды колебаний генератора нить накала лампочки разогревалась, ее сопротивление увеличивалось. Это снижало коэффициент усиления и приводило к стабилизации амплитуды колебаний на определенном уровне.
При схожем принципе работы, существенная разница с приведенными вами схемами состояла в том, что диоды и стабилитроны - это безинерционные элементы, а лампа накаливания - инерционный. Динамическое сопротивление диодов и стабилитронов изменяется более-менее мгновенно, что приводит к искажению генерируемой синусоиды и появлению нежелательных гармоник. А сопротивление нити накала меняется медленно и не успевает следовать за формой генерируемого сигнала, оно зависит в основном от интегральной характеристики синусоиды, ее действующего значения. Поэтому схема Хьюлетта генереруемую синусоиду почти не искажала, получался чистый синус.
Так что, при внешней схожести, схема Хьюлетта использовала линейный усилитель с АРУ, а в приведенных вами схемах используется нелинейный усилитель. Это две большие разницы, и коэффициент нелинейных искажений в этих двух генераторах будет отличаться на порядок или более. Кстати говоря, Хьюлетт придумал использовать в генераторе лампочку накаливания когда был студентом. Первый прибор фирмы Хьюлетт-Паккард, звуковой генератор с малыми искажениями, был воплощением его дипломного проекта.
-
4 hours ago, Bonifacy said:
хмм, странно, гугл и преподаватель видимо врут мне. Спасибо, что открыли мне глаза. А если серьезно, то я хоть и не разбираюсь в этом, но по запросу "схема ару" в гугле, он мне выдает идентичные схемы. Если я все таки не прав, то пожалуйста объясните почему?
Вот что выдает гугл на запрос "схема ару". Похоже что врет здесь кто-то другой...
-
Извините, не понял вопроса. Что за 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 мА. При этом, соответственно, рассеиваемая мощность уменьшится на порядок, а также станет втрое короче выходной импульс.
-
On 3/16/2015 at 12:36 AM, AlexandrY said:
Т.е. это только через лет 5-ть они начнут массово замещать ардуино.
Прошло 6 лет. Ардуино до сих пор живет и здравствует, а Micro Bit почему-то не видно и не слышно...
-
5 hours ago, jcxz said:
Даже людей, передвигающихся на костылях и в инвалидных колясках?
Вполне очевидно, что это технически осуществимо. Как и все прочее. Вопрос только в средствах, потраченных на обучение AI.
-
On 8/5/2021 at 12:36 AM, haker_fox said:
В общем, пришёл к такому же выводу, но обратился на форум лишь в надежде, а вдруг... Ну и ладно)
Недавно мелькала инфа про систему, которая надежно обнаруживает и "ведет" людей по вибрациям пола. Помнится, на основе AI...
Шифрование данных
в В помощь начинающему
Опубликовано · Пожаловаться
Надуманная проблема. Подавляющему большинству более чем достаточно сменить ключ. Если же у пользователя действительно серьезная задача, он или выберет другое решение, или полезет читать.
Еще одна выковырянная из носа "проблема". Пользователь лезет в Википедию, читает про LFSR, находит полиномы, меняет. Минут на пять работы. Кому не хватает квалификации даже на это - довольствуются сменой ключа ХТЕА или идут пользоваться другими решениями. Даже одна только смена ключа не позволит взломать код никакому рядовому "плохому Зет".
Что же касается "нерядовых" взломщиков, то так или иначе ломается любая защита. Достаточно уворовать экземпляр устройства, считать EEPROM, взломать штатную защиту проца и прочитать все ключи и полиномы. Цена вопроса - порядка десятка килобаксов, наверное. При изменениях алгоритма взломщику еще придется дизассемблировать и анализировать прогу, что примерно удвоит затраты, но они все равно останутся не стоящими внимания для "нерядового" взломщика.
Пока что в этом топике наиболее конструктивным высказыванием, которое довелось от вас услышать, было "пора сворачивать дискуссию" (с)