Hacker News new | past | comments | ask | show | jobs | submit login

> If its for what Intel claims

If it's for what Intel claims, then they would trivially offer an option for the customer to disable it. Hell, they could even make it a selling point for higher-margin chips like Xeon.

Does ME have business purposes? Sure. But their staunch refusal to allow disabling by nongovernmental customers does not pass the sniff test. There is clearly some other, non-business reason for it.

> then you may as well just be worried about NSA spyware in your NIC

If you own my NIC but not my CPU, I can encrypt my traffic and blind you.

If you own my CPU (especially my AES-NI ISA), my options are more limited. Much higher-value target.




>If you own my CPU (especially my AES-NI ISA), my options are more limited. Much higher-value target.

>especially my AES-NI ISA

why aes cpus specifically? you're free to not use aes instructions. besides, if you own the cpu, you load whatever shellcode you want, no need to backdoor the aes instruction.


> you're free to not use aes instructions.

good luck getting a system compiled that does not use them at all. Might be possible with gentoo and the right configuration as it compiles everything, but with a dominantly binary distro like Ubuntu or Debian you're SOL.


Especially, not specifically.

I was just saying my options are more limited, and the options for someone unwilling to recompile their own software is very severely limited.

But even if I'm running, say, software-only Salsa20 with all compiler optimizations off, if my CPU is still owned, my keys are still at risk of silent compromise.

The only real defense is to ascertain the processing limitations of IME and then choose your crypto primitives/implementation for both processing and memory hardness that exceeds the ability of the IME's lower transistor count and/or clock speed to keep up with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: