5 ms·
This is quite obviously an attempt to cut out the flood of cheap embedded PCs which are ideal for pfSense and steer more sales to their own hardware. Systems su
by mrenouf2 9y ago
This is quite obviously an attempt to cut out the flood of cheap embedded PCs which are ideal for pfSense and steer more sales to their own hardware. Systems such as "The vault" sold by protectli.com are completely adequate for the home network (I am capable of pushing > 100Mbit/s over OpenVPN at ~35% CPU). These run older celeron processors and are dirt cheap.
Hints:
1) The post implies this restriction will only be for the community (free) edition.
"pfSense Community Edition version 2.5 will include a requirement that the CPU supports AES-NI"
2) There is zero reason to require AES-NI, as running with a software fallback will simply yield lower performance. Taking this option away makes no sense unless you want to encourage those who don't pay for software support to buy your hardware, while those already paying for support are free to use their existing gear.
- feld 9y agoWell, if you care about security AES-NI allegedly prevents a side channel attack.
- wtallis 9y agoAre you referring to timing attacks or something even more subtle?
- tptacek 9y agoTiming, 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.
- dom0 9y agoMost/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.
- cesarb 9y agoWouldn't a bit-sliced implementation of AES be guaranteed constant time, at the cost of some speed?
- tptacek 9y agoIn 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.
- pinpeliponni 9y agoAs long as you keep the keys not in HSM, that'll be true. Should also require the use of TPM for storing keys..
- tptacek 9y agoNo, this isn't valid reasoning.