DES с 56-битным ключем.

Так вот, оказывется в чем Ваше призвание! Не мучте себя - работайте кассиром и в Новом Году будете счастливы и Вы и окружающие Вас. Ну а долгими зммними вечерами можете набрасывать на дельфях зарплатные ведомости .

Oй! Неуж-то Вы у Ричи кассиром устроились? Ну а если серьезно,то краснеть мне незачто и по этой причине на это

Не соглашусь.

В этом смысле тоже есть что пооптимизить. Сейчас включено:

KEY_COUNT == 3
#define KEYBITS 256 //!< Use AES256.
#define ROUNDS 14 //!< Number of rounds.
#define KEYLENGTH 32 //!< Key length in number of bytes.



Это уже весь бред ? Или еще будет ?

У AVRки всего 10K перезаписей. Поэтому 56-бит неломаемо.

Согласен .


А, так Вы это бредили ! То-то я смотрю что-то про красное в крапинку начали нести... Хорошо, что предупредили, не сразу понял .

Ещё как идея: Попробуйте вместо буржуевского AES использовать отечественный стандарт шифрования ГОСТ. Насколько я понимаю он тоже очень прост в реализации, да и стойкость у него примерно такая-же как и у AES. Он менее производителен, зато более компактный код должен получиться.

Он отнюдь не проще и насквозь 32 битный, что вообще для AVR смерть. Параноей страдать не надо и для AVR просто надо пользовать относительно "простенькие" уровня DES и прочих середины 70x-80 годов.

Я так понимаю, судя по продолжающемуся хамству, оригинальный код вы уже разместили в ~1.7k на GCC или ~1.1 на IAR, да ? Так и где же он ?



С тем же успехом можно было использовать любой другой. Но у задачи есть еще одно существенное ограничение - минимально количество телодвижений. Исходный вариант в этом смысле был очень неплох. Да в общем-то и сейчас альтернатив не вижу.



С параметрами
#if KEY_COUNT == 1
#define KEYBITS 128 //!< Use AES128.
#define ROUNDS 10 //!< Number of rounds.
#define KEYLENGTH 16 //!< Key length in number of bytes.

у меня что-то не сложилось. Да и в общем-то весь выигрышь лишь в длинне ключа - 16 байт и, кажется, размере ОЗУ, которого и так вполне хватает. Алгоритм, заточенный под конкретно 56 бит, я еще и не искал. С ним, вероятно, могло бы быть гораздо лучше.

то, что он "насквозь" 32битный не делает его большим в плане реализации. Из 32бит операций там сдвиги, XORы которые для 8битника совсем не тяжелы. А так же сложение, которое тоже не представляет проблемы. Ранее я говорил что ГОСТ не быстр, но ОЧЕНЬ прост в реализации.

Для восьмибика "тяжелы" и, что в случае загрузчика более существенно - громоздки любые не 8bit операци вне зависимости от XOR это или OR... При этом он однозначно проиграет и сильно проиграет своему одногрупнику DES по размеру. Что получаем в замен? Длинный ключ? А оно это надо? Кто будет ломать этот AVR - госслужбы USA? Клуб любителей создающих кластеры в интернете? Когда есть ресурсы (загрузчик (корее BIOS) 8K c массой наворотов среди которых дешифратор просто теряется), то можно, как и я в свое время поступил, запихнуть тот-же AES и не париться.

Очень спорно. ИМХО ГОСТ компактнее получится. Если приведёте свою оптимальную реализацию (на Си, и лучше оптимизированную для winavr) DES . То попробую сделать аналогичную процедуру ГОСТ. Можно будет сравнить. Самому любопытно.

Судя по повышению требований со 100 байт прописанных в заголовке до 900 ничего другого, кроме огульного обвиненя, теперь уже в хамстве у Вас не осталось. Напомню историю вопроса
1. Пролетели на 100 байт. С кем не бывает.
2. Вы начали пустопорожние общие разговоры об оптимизации
3. Я совершенно справедливо предположив, что ничего умнее, чем взять каой-нибудь писанный левой ногой исходник из интернета не сделано, выразился в духе, что зажать его на 100 байт без проблем.
4. С Вашей стороны начались рассказы о крутых профессионалах, от одного только имени (что-то вроде истинного имени Будды) которых лично я должен если не рассыпаться в прах, то как мимимум, покрыться красными полосками и удалиться в монастырь на покаяние.
5. Вами был выложен, как и предполагалось, писанный левой ногой исходник из интернету.
6. Естественно, он (точнее даже один из его кусков - других не касался) был соверженно спокойно сокращен на 250 байт... Что даже с учетом какого-нибудь другого генерящего менее компактный код компилятора просимые первоначально 100 байт обеспечивает наверняка.
7. Тут Вы начали совсем уж глупые разговоры о том, что это был "не тот" исходник а "тот" исходник он такооой исходник, что просто всем исходникам исходник и что-бы только приблизится к "тому" шедевру нужно зажать "этот" исходник вдвое.
8. Потом, вообще, зачем-то рассказали нам всем, как Вам нравится работать кассиром....

Короче,если-бы Вы дейсвительно, как Вам говорили несколько человек, выложили свой не влезающий на тот момент в 2K исходник, то возможно и был-бы повод для обсуждения. А так, так . Хотя нет, небольшая польза есть, если у кого были иллюзии, что в Интернете, пусть даже у "профессионалов" именитой фирмы, можно найти реально приличные исходники , то, надеюсь, они хоть слегка развеялись.


Ну сишные DES более, чем доступны, а "своими" и уж тем боле под AVR не занимался, ГОСТ реализация как-то на глаза не попадалась, но явно должна где-нибудь лежать. Для начала можете сравнить их и не в оптимизированном виде. По идее, когда-то давно использовал некий более простой, нежели DES (но его уровня) алгоритм - могу,когда вернусь домой, поискать в своих архивах.

для сравнения нужна не просто "реализация из интернета". Хотелось-бы иметь уже толковую версию DESа.

в неоптимизированном виде ГОСТ выигрывает.

Искать не надо. т.к. нужна доказательная база о "его уровня" защищённости. Либо классический DES (к классическими "ослаблениями"), либо ничего (в рамках данного исследования об размере кода).

Тогда, хотелось-бы взглянуть,что там для 8bit получилось. Ссылку на сишный исходник ГОСТ, пожалуйста. После Нового Года посмотрю.

Ну это тоже был не доморощенный - тех-же времен и с такой-же теоретической "подпоркой". Разница в основном в том, что официально принят штатами был DES.
P.S.
Вспомнил волшебные буквы TEA и XTEA. Там исходников дешифратора строк десять на C - думаю легко найдете.

ссылки нет. это моя реализация.

хотя-бы название?