Цитата(Kabdim @ Nov 24 2017, 12:06)

Если же с бытовой точки зрения, при упаковывании больших потоков информации нужно добавить key meshing. Но в целом ваш подход без определения модели противника, стоимости информации, объемов инфы, процедуры смены ключей при их компрометации - глубоко неправильный. На таком уровне любой современный алгоритм - достаточно хороший. Если есть возможность лучше возьмите openssl и сделайте не нём, это будет лучше чем писать самому.
openssl в stm32, вы пошутили?

Кстати именно openssl, даже не в embedded я бы не особо доверял(особенно высокоуровневым фунцкиям, где могут быть сюрпризы типа heartbleed), кроме недостатка в виде безумного API, судя по новостям у него очень плохо в последнее время с верификацией нового кода, я предпочту его форки.
Уточню, это брелок для хранения ssh ключей на stm32f103, проект опенсорс. Буду использовать и для своих целей, первую версию - для некритических задач.
Основа крипто в брелке у меня на аналоге, mbedtls, который более дружен с embedded.
Причем тут key meshing - не совсем понял, у меня создается ключ для AES256 с помощью SHA512, смешивая рандомную строку с паролем, по сути рандомная строка работает как salt, затем этим AES256 дешифруем ключ RSA(до 4096 байт включительно) размером в ~527 байт, хранящийся на внутренней флеше. Насколько я знаю, в данном случае допустим банальный CBC, т.к. ни ciphertext, ни plaintext атакующий ни модифицировать не может, как и перехватить данные и проанализировать, все происходит внутри чипа. А вот украсть брелок и сдернуть прошивку - вполне.
Против всяких подслушек по питанию я пока защищаться не буду, т.к. во первых маловероятно, что кто-то воткнет мне такое в комп, чтоб я этого не заметил, и поначалу задачи будет выполнять распространенная платка за $2, а для защиты от атак по питанию и EMI надо разрабатывать плату с нуля.
Модель противника - написана выше, уточню - это посторонний человек который может украсть брелок, без огромного финансирования(т.е. кластеры и железки типа 8x1080, электронный микроскоп и т.п. ему наврядли доступны), и задача сохранить ciphertext нерасшифрованным до момента когда доступ на сервера отзовут (обычно сутки-двое).
Стоимость информации обычно мала, сама информация существенной стоимости не имеет, а вот возможные деструктивные действия с помощью ключей - уже хуже.