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.