Микроконтроллеры

2) в указанном чипе для пакетов встроено Automatic CRC. 1) тут надо разбираться с хотелками. кому-то достаточно того, что чтение(сохранение из эфира) и расшифровка могут занять достаточно много времени, кому-то хочется, чтобы третья сторона, записавшая сообщение, не могла, передав этот дамп, положить обмен или чего ещё. кому-то кажется, что его устройства хотят поломать (изменить настройки, прошивку), разобрав протокол, и использовать в корыстных целях:) скомпрометированные сети нод... Что касается расписания смены ключа, то попробуем разобрать простой вариант без ретрансляторов и прочей пурги. Допустим AP (Access point - концентратор) спит и не в приёме. AP периодически передаёт пакет типа Join - для "зацепки" желающими связаться. AP после передачи Join сразу переключается в приём. EP (End point - ведомая нода) вдруг решила чегой-то передать - она переходит в приём и "ловит"(ждёт) Join-пакет от AP. После приёма Join-пакета EP переключается в передачу и передаёт пакет типа Link, содержащий токен (некое число), который можно просто использовать как код ключа (словари в AP и EP одинаковы) - пусть это число, взятое по модулю, например, 77, а далее по модулю размера словаря, будет номером ключа для данных из AP. В ответ AP также передаёт пакет типа Link, содержащий другой аналогичный токен для ключа сообщений EP, время аренды и/или количество сообщений в сеансе, номер частотного канала в таблице номеров частот. Далее можно, например, не добавляя соль, просто обменяться шифованными сообщениями. Сеанс заканчивается либо по времени, либо по количеству сообщений, либо по команде закрытия сеанса, либо пакетами начала сеанса (типа Join) ИМХО, там, где сильно нужно углубляться в криптоустойчивость, найдутся т.н. "офицеры безопасности", которые определят требования по этой устойчивости.