5 ms·
As long as we're getting efficiency cores and such, maybe we need some "crypto cores" added to modern architectures, that make promises specifically related to
by jerf 3y ago
As long as we're getting efficiency cores and such, maybe we need some "crypto cores" added to modern architectures, that make promises specifically related to constant time algorithms like this and promise not to prefetch, branch predict, etc. Sort of like the Itanium, but confined to a "crypto processor". Given how many features these things wouldn't have, they wouldn't be much silicon for the cores themselves, in principle.
This is the sort of thing that would metaphorically drive me to drink if I were implementing crypto code. It's an uphill battle at the best of times, but even if I finally get it all right, there's dozens of processor features both current and future ready to blow my code up at any time.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- bee_rider 3y agoOne option would be for people to stop downloading viruses and then running them.
- SpaghettiCthulu 3y agoExcept when these vulnerabilities are exploitable from JavaScript in your web browser.
- FiloSottile 3y agoSpeaking as a cryptography implementer, yes, these drive us up the wall. However, crypto coprocessors would be a tremendously disruptive solution: we'd need to build mountains of scaffolding to allow switching to and off these cores, and to share memory with them, etc. Even more critically, you can't just move the RSA multiplication to those cores and call it a day. The key is probably parsed from somewhere, right? Does the parser need to run on a crypto core? What if it comes over the network? And if you even manage to protect all the keys, what if a CPU side channel leaks the message you encrypted? Are you ok with it just because it's not a key? The only reason we don't see these attacks against non-crypto code is that finding targets is very application specific, while in crypto libraries everyone can agree leaking a key is bad. No, processor designers "just" need to stop violating assumptions, or at least talk to us before doing it.
- bee_rider 3y agoI don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing things down just so people can download random programs onto their computers and run them at random. That’s just a stupid thing to do, there’s no way to make it safe, and there never will be. I mean we’re talking about prefetching. If there was a way to give ram cache-like latencies why wouldn’t the hardware folks already have done it?
- FiloSottile 3y ago> download random programs onto their computers and run them at random To be clear that includes what we're all doing by downloading and running Javascript to read HN. Maybe I can say "don't run adversarial code on my same CPU" and only care about over-the-network CPU side-channels (of which there are still some), because I write Go crypto, but it doesn't sound like something my colleagues writing browser code can do.
- bee_rider 3y agoUnfortunately somebody has tricked users to leaving JavaScript on for every site, it is a really bad situation.
- anonymous-panda 3y agoSecurity and utility are in opposing balances often. The safest possible computer is one buried far underground without any cables in a faraday cage. Not very useful. > We’re not inserting the security community into that loop and slowing things down just so people can download random programs onto their computers and run them at random. That’s just a stupid thing to do, there’s no way to make it safe, and there never will be. Setting aside JavaScript, you can see this today with cloud computers which have largely displaced private clouds. These run untrusted code on shared computers. Fundamentally that’s what they’re doing because that’s what you need for economies of scale, durability, availability, etc. So figuring out a way to run untrusted code on another machine safely is fundamentally a desirable goal. That’s why people are trying to do homomorphic encryption - so that the “safely” part can go both ways and both the HW owner and the “untrusted” SW don’t need to trust each other to execute said code.
- gabrielhidasy 3y agoMany modern architectures have crypto extensions, usually to accelerate a few common algorithms, maybe it would be good to add a few crypto-primitives instructions to allow new algorithms?
- sargun 3y agoI think what's more likely is "mode switching" in which you can disable these components of the CPU for a certain section of executing code (the abstraction would probably be at the thread level).
- Joel_Mckay 3y agoEncrypted bus mmu have existed since the 1990's. However, the trend to consumer-grade hardware for cost-optimized cloud architecture ate the CPU market. Thus, the only real choice now is consumer CPUs even in scaled applications.
- Kluggy 3y agoIsn't that the entire point of the secure enclave[1]? https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web https://support.apple.com/guide/security/secure-enclave-sec5...
- john_alan 3y agoIf you look at the cryptokit API docs the Secure Enclave essentially only supports P-256. Which is maybe why they didn’t include ECC crypto in the examples.
- lxgr 3y agoThe secure enclave is not a general-purpose/user-programmable processor. It only runs Apple-signed code, and access is only exposed via the Keychain APIs, which only support a very limited set of cryptographic operations. Presumably latency for any operation is also many orders of magnitude higher than in-thread crypto, so that just doesn't work for many applications.
- a-dub 3y agosee DIT and DOIT flags referenced in the paper and in the faq question about mitigations. newer CPUs apparently provide functions to do just that.