On Mon, 6 Aug 2018 15:52:11 -0500
> I imagine the answer is this is not implemented or going to be but > saw this article and figured I would ask. > > Seems suspect to not release all details, and have it rejected by ISO > but yet still being put in both the kernel and Android OS. > > https://itsfoss.com/nsas-encryption-algorithm-in-linux-kernel-is-creating-unease-in-the-community/ I wouldn't be too concerned in any case. It is not like OpenBSD devs are likely to switch out AES-NI support from the filesystem encryption. Rarely is well implemented encryption the weak spot. Considering the Nistp allegations have been largely discredited and AES and SHA256 hw even is abound on modern hardware, I doubt they focus on encryption itself! If you want to talk conspiracies then Google Chromes blunder of calling sites SECURE becoming a repeated blunder of NOT SECURE, when they already had a better implementation of flashing the bar red during data entry? https sites that provide http unsigned downloads are quite frequent too! It is interesting that Google apparently say AES is expensive here yet where an attacker may saturate your website, https is apparently faster than http. (RTT potential, ignoring the negative sides in literature and youtube completely). I guess it is possible that https deployment may mean Google cloud makes money in CPU cycles from CHACHA or competitors energy costs go up (older non AES-NI). Or VPN usage declines, so Google can target ads to IP location. It may be more likely that some zealous chrome devs decided https everywhere was utterly important and so misleading messages were the order of the day.
