AES NI acceleration for AES-CBC with SHA-1 SHA-xx
-
IPsec does profit from AES-NI, it's AES-CBC + HMAC-SHA1 that suffers. We're not done, either. For now, using AES-GCM with AES-NI will provide the largest gains. Again, we're not done here, but the current project is QAT.
At my last place, they used a patch from a consulting company that implemented AES-CBC with HMAC-SHA-xx via AES-NI acceleration. I have since moved on. If I can get more info / link on that, I will share.
VhPham
-
There is nothing in AES-NI that's capable of accelerating SHA. The AES-CBC part is accelerated. But that doesn't help much because of the lack of SHA acceleration.
-
@cmb:
There is nothing in AES-NI that's capable of accelerating SHA. The AES-CBC part is accelerated. But that doesn't help much because of the lack of SHA acceleration.
I still don't have all the details. So can't comment in depth. I have sent a query to my ex-colleagues. SHA-xx is not supported by AES-NI. Whereas CBC is indeed accelerated. But the combo AES-CBC with SHA-xx is the problem. So if this combo is offered during negotiations, it is rejected…until 'net.inet.ipsec.crypto_support' is disabled. I see this all the time in ipsec vpn, And also specially when L2TP / IPSec from Windows 7 and 10 clients.
-
The combo isn't a problem, it just can't be accelerated to the extent that AES-GCM can be. Refusing AES-CBC with SHA isn't a solution to that.