News for hackers. Stuff that matters.
Re:PfSense 2.5 and AES-NI by feld on Monday May 01, 2017 @02:49PM (#14240326)
Well, if you care about security AES-NI allegedly prevents a side channel attack.
Re:PfSense 2.5 and AES-NI by wtallis on Monday May 01, 2017 @02:53PM (#14240363)
Are you referring to timing attacks or something even more subtle?
Re:PfSense 2.5 and AES-NI by tptacek on Monday May 01, 2017 @02:55PM (#14240388)
Timing, data cache, BTB, you name it: doing software AES exposes you to All The Side Channels, and AES is somewhat notoriously hard to implement safely in software compared to other software-profile ciphers. This is the big selling point for ChaPoly.
Re:PfSense 2.5 and AES-NI by dom0 on Monday May 01, 2017 @03:03PM (#14240457)
Most/all software implementations of AES had various side channels in the past. Considering AES-GCM, as far as I'm aware no software implementation is considered "safe". Some libraries do not support AES-GCM without hardware instructions that make it safe (e.g. libsodium choose that way).

This is mainly due to AES relying heavily on substitution boxes, i.e. small arrays that are indexed with secrets, which is easy to implement safely in hardware, but difficult in software that runs on a processor with caches and such.

Re:PfSense 2.5 and AES-NI by tptacek on Monday May 01, 2017 @03:23PM (#14240622)
In the GCM case, it's also because the polynomial hash in GHASH wants fast polynomial multiplication, which PCLMULQDQ provides, and which you want (unsafe) lookup tables for otherwise.
Re:PfSense 2.5 and AES-NI by cesarb on Monday May 01, 2017 @03:22PM (#14240615)
Wouldn't a bit-sliced implementation of AES be guaranteed constant time, at the cost of some speed?
Re:PfSense 2.5 and AES-NI by pinpeliponni on Monday May 01, 2017 @03:22PM (#14240618)
As long as you keep the keys not in HSM, that'll be true. Should also require the use of TPM for storing keys..
Re:PfSense 2.5 and AES-NI by tptacek on Monday May 01, 2017 @03:47PM (#14240837)
No, this isn't valid reasoning.