Колеги,
Малко се отклонихме от темата, но криптирането на радиокомуникациите (в частност) е също много интересна тема. Може би трябва да открием спецялна тема по въпроса, но така и така сме я подхванали - да ви опиша с 2 думи и моята идея.

Целта която си бах поставил беше да се разработи криптиращ алгоритъм, който да позволява криптиране на фреймове с променлива дължина (без допълване с DUMMI байтове за подравняване примерно до 8 байта). Също така алгоритъма трябва да може лесно да се изпълнява на 8 битов микроконтролер максимално бързо. Алгоритъма трябва да позволява използването на клчюове(в конкретният случай те са 8 байтови). Особенното при предаваните данни от мене е, че в 90% от случаите данните са еднакви. Т.е едно просто XOR с ключ не ми върши работа, тъй като криптираните фреймове ще са ми еднакви.
За да заобиколя това - трябваше да добавя нещо"променливо", което да ми позволи еднаквите криптирани данни да изглеждат "различно". Т.е. да не позволя едно просто записване на излъчен фрейм и повторното му излъчване да обърка устройствата ми.
За целта добавих брояч на трансмисиите, като той е позициониран най-отпред в криптираната част на фрейма. Увеличавам го с 1 при всяка трансмисия.
Криптирането което правя е байт по байт - започвайки от младшият байт на брояча, като вече криптираният байт служи като "променлива маска" за криптирането на следващият байт - и така до края на фрейма.
т.е. Криптиращата маска се получава грубо казано от XOR на вече криптираният байт и поредният байт от криптиращият ключ.
Декриптирането - по обратният начин, само дето фрейма се извърта "отзад на пред".

Брояча позволява и още една защита от "елементарно записване и излъчване" на фрейм с команди случай, че се проверява и се следи последователното му увеличаване. Т.е. ако предишният фрейм е бил с брояч . 10, то следващичт "валиден" фрейм трябва да е с брояч 11.
Възможно е разбира се "разсинхронизация" на броячите, но с подходящи алгоритми - и на това му се намира решение.

Подобна е идеята на Qeeloc криптирането - с брояч, само дето при него криптирането е побитово и не позволява променлива дължина на криптираните данни.

.

Защо не ползваш алгоритъма на микрочип Hopping Code, доста е надежден ?

Но ако е за някакъв пренос на данни и не е нещо супер секретно и няма съвместими подобни неща наоколо може да го направиш по най простия начин с някаква малка таблица записваш я във всички устройства, първо предаваш номер на ред в таблицата и след това правиш изключващо или на данните с този ред от таблицата, дори и да ги предаваш по случаен алгоритъм номера на реда не е проблем за декодера винаги ще си намира реда след като си му го пуснал преди това. Дори и в този прост вариант ако ползваш случайно избран ред е много трудно да се декодира защото декодера ако няма тази таблица няма да знае какво да декодира

plameniv,
Киилок криптирането на микрочип е надеждно, но много бавно. Подходящо е според мене за криптиране на битове - и то доста неефективно. В криптираната част полезните битове са само 6 (ако прибавим и брояча на трансмисиите - стават 22), а общо са 32. Като прибавим и некриптираната част на фрейма - излиза, че за да предадем 6 бита и двубайтов брояч - предаваме 56 или 64 бита (по спомени). Иначе алгоритъма наистина е надежден и е подходящ за предаване на "битови" команди - примерно бутоните на едно дистанционно управление за автомобил. (Той за това мисля че е и правен)

В моят случай данните които се предават и трябва да се криптират са 1-56 байта.

Относно идеята която описваш - да, работи, но за целта трябва да предаваш един некриптиран байт (указателя към началният елемент от криптиращата таблица).
И аз навремето се сетих за това, но реших, че така и така ще правя някакво криптиране - нека да е такова, че да няма некриптирани байтове във фрейма - които да "обслужват" декриптирането.

само да не са от вестник "Трета възраст" или журнал "За жената" тези статии

иначе по темата
Трябва да се почне от въпроса - За какво аджеба ти е криптиращ алгоритъм
1. Имаш данни, които да са поверителни - демек друг да не ти ги чете ;
2. Имаш данни, които да ги "профилираш" - демек сходни са по съдържание, но трябва да се четат само от отсрещният кореспондент(а не от всички) в едно предаване(сесия);
3. Имаш повече свободно време и искаш да го уплътниш, като изучаваш нещо ново - аферим, ашколсун, браво на теб

иначе както си го описал ако искаш да има резултат - задачата е сериозна ;
ако не искаш дъми байтове - ползвай поточен шифър - има доста. При поточните крипто алгоритми един ход на алгото е 1 бит, не 8,16 и т.н. както е при блоковите(като напр. AES -16 байта на един ход), така произвеждаш крипто последователност точно до бит колкото ти трябва... но те(поточниоте )
имат слабости, които не са предмет на темата.
защитата от повторения на записани команди и т.н можеш да си я решиш с разни начални синхропакети и досинхронизации. за да нямаш грешка е хубаво да ползваш код за откриване и корекция на грешка...
и т.н.

За проверката по CRC и корекцията на грешките (FEC) ми се грижи радиото на хадруерно ниво.
Иначе си прав за проверката след приемане на фрейма преди декриптиране. Точно такъв проблем има Кеелок-а на микрочип. Има вероятност да приемеш фрейм с 1 сгрешен бит в криптираната му част, което да доведе до "правилно декриптиране и валидиране", а всъщност това да не е така.
На времето доста си блъскахме главите с това, докъто разберем какво става ...

Не е болка за умиране ако е предаден веднъж грешно при Кеелок, това е измислено да се предава команда от дистанционно и за целта докато си натиснал се предава едно и също докато не пуснеш бутона, затова имаш правилно декриптиране.

Колеги,

Има нова интересна тема в раздела "Администрация", която мисля ще е интересна за всички нас.
"Как максимално да се възползваме от труда си "
http://mcu-bg.com/mcu_site/viewtopic.php?t=6507

Извинявам се, че по такъв начин искам да насоча вниманието Ви към нея, но мисля, че трябва да поздравим създателят и и да помислим по повдигнатите от него въпроси.
Мисля, че всички developer-и се сблъскваме с този проблем при поемането на поредната поръчка или договор ...