Hi,

I would like to request AES-NI support for AES hardware acceleration instruction set for x86 devices. I've tested on Cisco CSR and it's awesome. Thanks.

Chris

but dat "accelerations" severely compromise security.
its improve things bout 5x-12x times on most modern (AES-NI aware) x86 chips
but at that cost ...
想一想:没有“免费奶酪/啤酒”n real world and "improvements" that let CPU do things 10x faster(we're talking bout 95W-178W CPU's there)than fully-saturated CPU's can do (over 1.5k transistors budget or less) isn't really convincing. even ASIC offoading(there was plentiful of such "accelerators") to less bang or FPGA things.
if thats not "mission-critical"(which interfere with whole purpose of using it in 90% cases)then okay.

but dat "accelerations" severely compromise security.
its improve things bout 5x-12x times on most modern (AES-NI aware) x86 chips
but at that cost ...
想一想:没有“免费奶酪/啤酒”n real world and "improvements" that let CPU do things 10x faster(we're talking bout 95W-178W CPU's there)than fully-saturated CPU's can do (over 1.5k transistors budget or less) isn't really convincing. even ASIC offoading(there was plentiful of such "accelerators") to less bang or FPGA things.
if thats not "mission-critical"(which interfere with whole purpose of using it in 90% cases)then okay.

/tinfoil hat

What the AES-NI set do is provide assembly instructions for AES encryption instead of having a bunch more instructions to do things. So if you want to encrypt a byte of data all you do is provide the AES instruction with data rather than a whole bunch of instructions representing the AES math in x86 assembly form. You save cycles so i dont see how it is less secure.

In a multi threaded or vector CPU these extra instructions can run while the CPU is executing other instructions.

Essentially AES-NI is an additional ASIC or bunch of transistors as a unit added to the CPU. Look at the AMD bulldozer architecture, it splits up these additional x86 units from the CPU so each 2 CPU shares 1 unit of these extra things.

Your assumption that there isnt some sacrifice is misplaced, AES-NI adds cost to the CPU requiring more transistors, it needs additional registers, it is basically a hardware representation of some math which the unit is designed for doing it with far less cycles so instead of having to list all the steps in software and run the steps one at a time it runs the whole math faster because the steps have been designed into the CPU so it doesnt have to keep going through instructions.

Same with hardware float, theres multiple ways to do float and some hardware floats will do it accurately while some want speed and smaller size/power so they do float but less accurate. Think GPUs, they are basically hardware float processors and if you compare a GPU to CPU GPU graphics is much better than CPU graphics, much faster and looks better.

no. its not. despite NSA PR about.
its not works this way and ASIC can't do that. not That "size" of logic behind AES-NI in x86 chips(would be 1/3 of whole CPU ~ or around
its achieved by purposely compromising/crippling math behind cipher in several "hot spots of code", tremendously boosting throughput, yes, but at dreadfush/terrific price, measured in lives, sometimes.

/tinfoil hat

tinfoli hat linux - one of funniest and most interesting linux distros i ever used, among qubes and other stuff(ITSec-wize and "in general")https://en.wikipedia.org/wiki/Tinfoil_Hat_Linux
but beware sneaky reptiloids and let the be tinfoli hat with you, my friend !! *waves lightsaber*

but dat "accelerations" severely compromise security.
its improve things bout 5x-12x times on most modern (AES-NI aware) x86 chips
but at that cost ...

Can you be more specific, please? What cost? Why exactly using AES-NI instructions is less secure than doing the same math using "traditional" instruction set exclusively? Please explain.

but dat "accelerations" severely compromise security.
its improve things bout 5x-12x times on most modern (AES-NI aware) x86 chips
but at that cost ...

Can you be more specific, please? What cost? Why exactly using AES-NI instructions is less secure than doing the same math using "traditional" instruction set exclusively? Please explain.

depend what kind of business you company do.
then you can calculate/estimate impact/cost of flawed "security" i guess.
there is no free cheese over fence or silver bullets. just wolves in sheep clothes(among feds and their "friends" in telco and science).
for specific details about AES-NI impact on crypto implementations - you can check relevant message boards, news feeds and podcasts. if you short on time - start from last one. personally i prefer lectures done by Chaos Con folks/guests, but several other interesting events had speakers that share same conclusions and concern among that biz.
if you not really motivated to really had answers or asked "out of couriousity", or just think you time is cost more(to waste it atleast googling on-topic), then i think you should find someone else to help/teach.

for specific details about AES-NI impact on crypto implementations - you can check relevant message boards, news feeds and podcasts. if you short on time - start from last one. personally i prefer lectures done by Chaos Con folks/guests, but several other interesting events had speakers that share same conclusions and concern among that biz.
if you not really motivated to really had answers or asked "out of couriousity", or just think you time is cost more(to waste it atleast googling on-topic), then i think you should find someone else to help/teach.

So, you don't have any real arguments to prove your point of view.

I suggest you think about the following. AES is a deterministic algorithm. That is for any particular block of cleartext on input there's only ONE correct block of ciphertext on output possible while encrypting. Similarly, for any particular block of ciphertext on input there's only ONE correct block of cleartext on output possible while decrypting. It does not really matter if some particular implementation uses AES-NI or does everything using traditional instruction set, for any given block of data on input they should give you correct result on output, and there's always exactly ONE correct result possible.

It seems likely AES-NI instruction support will be available when Mikrotik do a 64-bit x86 build. AES-NI aside, we'd see a 15% performance increase (due to correspondingly higher IPC), which is important on low-end Atom boxes.

Maybe he is worried about something like what happened with Juniper?

It seems likely AES-NI instruction support will be available when Mikrotik do a 64-bit x86 build. AES-NI aside, we'd see a 15% performance increase (due to correspondingly higher IPC), which is important on low-end Atom boxes.

performance-wise properly implemented AES-NI - had Bigger boost than 15%.from 120% to 400%, up to ~180% average.
on Atom its almost 1/3-1/2(depend "generation" of) lower than "mainstream" CPU's, both because AES-NI implementation and tiny/weak CPU but still hard to not notice.
sadly both intel(eariler in beta) and AMD(in last versions of releasd of SDK/tools)withderw anything non-rinjael/AES in support. originally there was things like (partially-implemented, but still "Faster than without AES-NI")TwoFish, Serpent and incomplete CAST and BlowFish and other things alike(including DES and 3DES. no GOST and Stribog/Grasshopper)
since AMD FX and Cabini - AMD had better support of AES-NI, but in Broadwell and Skylake that gap was somewhat reduced between vendors.
so far most AES-Ni implementations rely on asm fine-tuning and Through profiling, making it Very platform-specific thing in each arch, which add another potential exploitation thus and speculations about.
但到目前为止没有任何“免费啤酒”芯片so AES-NI "works" only when something Essential sacrificed ptimistically engineering and coding stuff. i cannot deny Real improvements in that and Potential of offoding/boosting it, but its remain Very computation-intentsive even with help of ASIC offloaders(FPGA-alike, GPU-alike, FPU-alike and SIMD-merger - much slower despite bigger flexibiity. and bigger "silicon-wise"(but that depends on strategy).
for particular details - its may be reasonably to study Particular Fab/company elements library and SDK to estimate numbers for decision making SoC/chips.
在MIPS,手臂,PPC -小于x86没有好处cause stronger silicon limitations, but on "generally-weaker" chips tided to AES-NI, cause "non-offloaded"(and which cannot be(efficiently)offloaded)portion of - still remain bottleneck in crypto. so old tiny 32-bit chips suffer more than 64-bit with fat l1, l2 catche, wide FPU/SIMD and other offloaders/accelerators.

Are there any updates for this topic? Did Mikrotik implement AES-NI support in latest x64 chr releases?
How to check it out on running VM?

Doesn't look like there is any interest in adding this feature, too bad b/c it's the only significant reason that Mikrotik gets knocked out of consideration. If you need this feature the performance improvements are very significant.

AES-NI support added
viewtopic.php?f=21&t=116357&p=591766#p591751

AES-NI support added
viewtopic.php?f=21&t=116357&p=591766#p591751

awesome !!!

good news to improve crypto performance !!!

cheap 65us pentium g4560 comes with AES-NI enabled and in flavors of 35watt and 51watt, 2 cores 4 threads cpu, very good option to build a powerfull and cheap CHR ROUTEROS box

We have x86 and CHR virtual instances with CPU where hardware offloading does not enable.

Is there a guide smewhere?

AES-NI support added
viewtopic.php?f=21&t=116357&p=591766#p591751