esaulenka

Вы невнимательно читаете. До указателя на uint16_t разговор ещё не дошёл. Компилятор не видит объявление указателя P8DataMas (вторую строчку из приведённого кода). Зато видит третью строчку, но из-за устаревшей 50 лет назад магии считает, что эта переменная имеет тип по умолчанию - int (см. варнинг). А присвоить int'у указатель без явного приведения не может (это уже ошибка, на которой компиляция останавливается). А как он хранится в памяти в том или ином МК ? Одинаково они хранятся, и в том МК, и в ином CPU.

Вот объяснение, почему так нельзя делать в C++: https://isocpp.org/wiki/faq/ctors#ctor-initializer-order Там, правда, почему-то сказано, что "компилятор может выдавать предупреждение". Проверил на gcc нескольких версий и на MSVC - все отказываются это компилировать. В случае C - да, конечно, компилятору проще сделать константный массив и в момент инициализации memcpy'ить его в нужное место.

Если быть точным, то в C++20 добавили только designated initializers (как это по-русски? назначенный?..) для структур. Для массивов, как в исходном вопросе, поддержки нет (я невнимательно слежу за развитием языка, но вроде б эту фишку и не обсуждали для добавления в последующие стандарты). Также в C++ есть ограничение, что члены структуры должны инициализироваться в том же порядке, как они расположены в самой структуре (с C можно было инициализировать как угодно).

Первый вариант - так исторически сложилось с незапамятных времён (а дальше - стандарт соблюдает обратную совместимость). Второй вариант - неявное преобразование типов сознательно запретили, из соображений, что оно противоречит общей идее С++ о строгой типизации. Подробнее можно прочитать в предложении о введении такой инициализации: https://www.stroustrup.com/N1919-initializer_lists.pdf Только не спрашивайте, как это всё работало до 2005 года ;-) (точнее, 2011, оно попало в стандарт C++11).

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

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

Вам всё ещё актуально? Не понял, что вы делаете. Насколько вижу, отправление из вашего контроллере (что за контроллер-то?) работает, в канвайзе видно 378-е сообщение. Кто тогда отправляет 379-е ? То сообщение, которое вы пытаетесь принять, кто отправляет? Как оно выглядит? (тут неочевидная штука - свои сообщения контроллер не видит). Также проблема может быть в настройках фильтра. Мне очень лень разбираться, что там навертели в кубе. Покажите значения регистров кана (хоть картинками из отладчика) И да, следите пожалуйста за форматированием кода. Кривые отступы не очень помогают пониманию...

В стародавние времена проект жил на сорсфорже, если я ничего не путаю. И в 3-й версии там есть ARM7 && IAR. В 4-ю оно уже не попало (некому перетаскивать было?..) https://sourceforge.net/projects/scmrtos/files/scmrtos/

Если вы про mifire (судя по упоминанию телефона), то там как-то сложно всё. У меня есть в закладках https://mysku.ru/blog/ebay/41849.html хотел скопировать ключ от нашего подъезда, но руки так и не дошли (особенно после выяснения кода от этого домофона).

Ну ок. Своим мнением о велосипедостроении я поделился, больше мне выковыривать из носа нечего. Поль-зо-ва-тель? Конечный? Он слова-то LFSR не знает. У нас же типа "безопасность через скрытность", как оно там внутри устроено, никому рассказывать нельзя. Тут @Vasily_ как-то упоминал, что дамп атмеги стоит несколько сотен баксов. Я не проверял. Ну, вам просто к сведению. Спор, постоянно скачущий с бузины на киевского дядьку, пошёл на очередной круг. Ещё раз напомнить, что вы зачем-то мешали сложность подбора полинома и сложность подбора ключа? Мне надоело, спасибо за беседу.

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

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

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

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

Кажется, в любом месте, где обсуждается криптография, написано большими буквами "security through obscurity не работает". Все алгоритмы, которыми пользуются большие дяди, 100 раз описаны и 1000 раз исследованы. Так я и предлагаю вам самостоятельно поэкспериментировать. На тех шифрах, что мне было интересно поковырять, это прекрасно работает (но мне нельзя верить, разумеется). Для умного дома, где вы это использовали, этой защиты даже с избытком (у вас там радио даже нет, хакеру придётся незаметно подключаться к проводу за плинтусом?). И если б все эти оговорки были в вашем изначальном сообщении - я б и слова не сказал. Но этот алгоритм был представлен как универсальный, без каких-то ограничений. Впрочем, если Jenya собирался в каждое сообщение добавлять ключ шифрования, ЛЮБОЙ другой вариант поднимает криптостойкость в миллионы раз :-))