Запрос на функцию: поддержка набора инструкций AES-NI для x86 RouterOS

/фольговая шляпа

Нет, это не так. Несмотря на пиар НСА, всё работает иначе, и ASIC не может этого делать. Логика AES-NI в x86-чипах не настолько огромна (примерно треть всего CPU) — такого просто нет. Эффективность достигается за счёт сознательного упрощения и "срезания" вычислений шифра в нескольких "горячих" участках кода, что резко повышает пропускную способность, но цена за это порой страшная и измеряется жизнями.

Tinfoil Hat Linux — один из самых забавных и интересных дистрибутивов Linux, что я когда-либо использовал, рядом с qubes и другими штуками (в плане IT-безопасности и вообще). https://en.wikipedia.org/wiki/Tinfoil_Hat_Linux

Но берегитесь коварных рептилоидов и пусть с вами будет Tinfoil Hat, друг мой!! Машу световым мечом.

Отлично!!! Прекрасная новость для повышения производительности в крипте!!! Дешёвый Pentium G4560 за 65 долларов с поддержкой AES-NI, доступный в вариантах с энергопотреблением 35 и 51 ватт, двухъядерный процессор с четырьмя потоками — отличный вариант для сборки мощного и недорогого роутера на CHR ROUTEROS.

Зависит от того, каким бизнесом занимается ваша компания. Тогда можно посчитать или примерно оценить последствия и стоимость неправильной «безопасности». Бесплатного сыра не бывает, как и универсальных решений. Везде одни волки в овечьей шкуре (особенно среди федов и их «друзей» в телекомах и науке). Для конкретных деталей о влиянии AES-NI на криптоимплементации можно посмотреть соответствующие форумы, новостные ленты и подкасты. Если времени мало — начните с подкастов. Лично я предпочитаю лекции от команды Chaos Con и их гостей, но и на других интересных мероприятиях выступали люди, которые делают такие же выводы и выражают похожие опасения в этой сфере. Если вас не особо волнует поиск настоящих ответов или вы просто интересуетесь «из любопытства», или считаете, что ваше время дороже (даже чтобы потратить его на гугление по теме), тогда, думаю, вам лучше найти кого-то другого, кто поможет или научит.

Похоже, что поддержка инструкций AES-NI появится, когда Mikrotik выпустит 64-битную сборку для x86. Если не считать AES-NI, мы увидим прирост производительности примерно на 15% (за счёт соответствующего увеличения IPC), что очень важно для бюджетных устройств на базе Atom.

С точки зрения производительности правильно реализованный AES-NI дал гораздо больший прирост — не просто 15%, а от 120% до 400%, в среднем примерно около 180%. На Atom же он примерно в 1,5–3 раза слабее, чем на «основных» процессорах, что зависит от «поколения» CPU, — из-за реализации AES-NI и слабенького процессора, но всё же это сложно не заметить. К сожалению, и Intel (раньше в бетах), и AMD (в последних версиях SDK/инструментов) убрали поддержку всего, что не связано с rinjael/AES. Изначально были решения вроде (частично реализованных, но всё ещё быстрее, чем без AES-NI) TwoFish, Serpent, как и неполные версии CAST, BlowFish и других схожих алгоритмов (включая DES и 3DES, но без ГОСТ и Stribog/Grasshopper).

С выходом AMD FX и Cabini у AMD стала лучше поддержка AES-NI, но в Broadwell и Skylake разрыв между производителями уменьшился. До сих пор большинство реализаций AES-NI завязано на тонкой настройке ассемблера и профилировании, что делает этот инструмент очень специфичным для каждой архитектуры. Это добавляет ещё один вектор для возможных уязвимостей и спекуляций. Но бесплатного «чуда» в шифровании нет — AES-NI «работает» только тогда, когда ради оптимистичной инженерии и программирования что-то существенное жертвуют.

Я не могу отрицать реальные улучшения и потенциал ускорения, но это всё равно остаётся очень ресурсоёмким процессом даже при помощи ASIC-ускорителей (по типу FPGA, GPU, FPU и объединения SIMD) — которые, хоть и более универсальны, работают медленнее и занимают больше площади на кристалле (но это уже зависит от стратегии).

Для более точных данных разумно изучать конкретные библиотеки и SDK от производителя, чтобы делать выводы при выборе SoC или чипов.

На MIPS, ARM, PPC выгода от AES-NI меньше, чем на x86, не из-за аппаратных ограничений, а потому что на «обычно слабых» процессорах без собственного аппаратного ускорения (или невозможностью эффективного аппаратного ускорения) нагрузка остаётся узким местом в криптографии. Поэтому старые маленькие 32-битные чипы страдают больше, чем 64-битные с большими кэшами L1, L2, широкими FPU/SIMD и прочими ускорителями.

Похоже, что интереса к добавлению этой функции нет, жаль, ведь это единственная серьезная причина, по которой Mikrotik не рассматривают. Если вам нужна эта функция, улучшение производительности будет очень заметным.