Jump to content

    

=AK=

Свой
  • Content Count

    3137
  • Joined

  • Last visited

Community Reputation

0 Обычный

2 Followers

About =AK=

  • Rank
    pontificator
  • Birthday 01/01/2009

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

6045 profile views
  1. В устройстве по приведенной ссылке расстояние от контроллера до ленты может достигать 100м. Это определяется характеристиками RS-485. Ардуино к климатике относится фиолетово. Не нравятся дешевые китайские модули - делайте свои, схемы в открытом доступе. У самих процев диапазон -40+85С.
  2. Пользователь моего кода. Странно, что надо растолковывать такое. Охотно верю. Однако в озвученную мною сумму входит и "уворовать". Возможно, что в забытых богом мухосрансках это тоже почти ничего не стоит. Я же дал свою личную оценку для мало-мальски цивилизованных стран.
  3. Надуманная проблема. Подавляющему большинству более чем достаточно сменить ключ. Если же у пользователя действительно серьезная задача, он или выберет другое решение, или полезет читать. Еще одна выковырянная из носа "проблема". Пользователь лезет в Википедию, читает про LFSR, находит полиномы, меняет. Минут на пять работы. Кому не хватает квалификации даже на это - довольствуются сменой ключа ХТЕА или идут пользоваться другими решениями. Даже одна только смена ключа не позволит взломать код никакому рядовому "плохому Зет". Что же касается "нерядовых" взломщиков, то так или иначе ломается любая защита. Достаточно уворовать экземпляр устройства, считать EEPROM, взломать штатную защиту проца и прочитать все ключи и полиномы. Цена вопроса - порядка десятка килобаксов, наверное. При изменениях алгоритма взломщику еще придется дизассемблировать и анализировать прогу, что примерно удвоит затраты, но они все равно останутся не стоящими внимания для "нерядового" взломщика. Пока что в этом топике наиболее конструктивным высказыванием, которое довелось от вас услышать, было "пора сворачивать дискуссию" (с)
  4. Как было сказано ранее, "тот, кто пользуется моим кодом". Подразумевается, что каждый вменяемый пользователь, взявший за основу мой код с Гитхаба, изменит содержимое файла cipher.h: задаст свой ключ шифрования XTEA и полиномы. Для большинства случаев этого достаточно. Если требуется, можно менять шифр в каждом приложении. Для этого ключ XTEA комбинируется из двух ключей. Oдин задается в файле cipher.h, другой сохраняется в EEPROM и задается при помощи хэш-генератора SHA1 при инициализации устройства - генерируется по паролю, или по имени клиента, или по имени проекта, и т.п., дело вкуса, см. https://github.com/akouz/HBus/tree/master/NodeTest Можно и полиномы хранить в EEPROM и задавать при инициализации, выбирая из списка. На мой взгляд, это уже паранойя, но если хочется, то сделать нетрудно. Зачем это надо, я из вашего описания так не понял. Не все полиномы годятся, только примитивные полиномы дают LFSR с максимальным числом состояний. Выбрать из всех возможных примитивный полином - это нетривиальная счетная задача. Выше была ссылка на страницу Купмана, там выложены примитивные полиномы вплоть до 32-битных.
  5. Попробуйте убедить в этом военных. Где вы там углядели столь категоричное утверждение - ума не приложу. Самое близкое что я нашел: "Существует общий консенсус, даже среди тех, кто выступает в пользу безопасности через неясность, что принцип «безопасность через неясность» никогда не должен использоваться в качестве основной меры безопасности." Что совсем не то же самое, что "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 шифром по принципу «безопасность через неясность». Который якобы "не работает" или "работает плохо", если вас слушать. Моя бабуля про такие ситуации говорила так: "пошли по шерсть - вернулись бритыми". Судя по всему, у нее с чувством юмора было все в порядке.
  6. Вот именно что кажется. Приведите теоретическое обоснование. Ваш личный пример меня не убеждает, ибо бог весть что и как вы ковыряли. И мой личный пример меня тоже не убедит. Такого рода "доказательство" - явный моветон.
  7. За 5 минут, может, и получится, если точно знать как устроен шифр и используемые полиномы LFSR. А без этого - хрен знает сколько раз по 5 минут. Мне это неочевидно. Их может быть и 100, и 1000. Можно было и внешний шифратор добавить, можно было и более мощный проц поставить, который бы шифровал чем-то более увесистым. Только зачем из пушки по ворбьям? Я решал конкретную задачу и выбрал для нее оптимальное, на мой взгляд, решение. Главное преимущество - очень простая реализация. Все в конечном счете определяется деньгами. Нет смысла тратиться на избыточную защиту, если затраты на взлом даже простой защиты не оправдываются. Достаточно иметь "средненькую" защиту, чтобы отбить желание у праздношатающихся кульхацкеров с ней возиться.
  8. Конечно, есть пример шифрования 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, после чего кряк опять усложняется на порядки даже для хакера, по какой-то неведомой причине заранее точно знающего, что шифрование основано на моем коде. Ибо нюансы конкретной реализации могут рассматриваться как составная часть шифрования, увеличивающая длину ключа.
  9. Вы о каком 4-байтном ключе? XTEA использует 128-битные ключи. А начальное значение LFSR формируется заново в каждом пакете. То есть, надо заранее знать 32 бита в теле каждого пакета, зашифрованного LFSR, чтобы расшифровать остаток пакета, вы это хотели сказать?
  10. Насколько я знаю, шифр XTEA довольно добротный, поэтому крякнуть заголовок непросто. Шифрование тела сообщения потоковым шифром на базе LFSR используется, как я помню, в Блютус. Так что от хакеров, наверное, защита будет более-менее нормальная, хотя бы потому что никому неохота будет связываться если нет известных уязвимостей.
  11. Спасибо за найденную ошибку. По смыслу должно быть 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, полагая, что значения по умолчанию вряд ли будут использоваться на практике.
  12. Подозреваю, что тот же результат достигается при помощи nonce, т.е поля в заголовке (в моем случае одного байта) со случайным значением. В результате повторяющиеся сообщения будут выглядеть совершенно разными.
  13. Потребление было "на уровне", никаких чудес ни в ту ни в другую сторону. В основном все определялось свойствами SOSC генератора, как всегда. Отдельный вход для батареи, при желании, можно было организовать при помощи диодов Шоттки и монтажного ИЛИ. Мне это не требовалось, поскольку все питалось от батареи и ни от чего более.