[kabdib]

I don't think this can be a language feature. It's more a platform thing: Why is keeping key material around on a stack or in extra CPU registers a security risk? It's because someone has access to the hardware you're running on. (Note that the plain-text is just as leaky as the key material. Yike!)

So stop doing that. Have a low-level system service (e.g., a hypervisor with well-defined isolation) do your crypto operations. Physically isolate the machines that need to do this, and carefully control their communication to other machines (PCI requires this for credit card processing, btw). Do end-to-end encryption of things like card numbers, at the point of entry by the user, and use short lifetime keys in environments you don't control very well.

The problem is much, much wider than a compiler extension.

[clarry]

Sensitive information doesn't exist in a vacuum. What we need to protect is more than some keys that can be carefully loaded onto a crypto processor hiding in a secure bunker. Yes, users should have security too. The point of entry matters too.

So how do you get that isolated box onto everyone's computer and phone? How do you move these users' sensitive information onto that isolated box without leaving a trace on their non-isolated computer? How do you move their keys around?

When you use two systems to process sensitive information, you have at least two problems to solve...

[userbinator]

This is also why dedicated cryptoprocessors exist, with special features for attack resistance; I'm not completely certain about this, but I'd think the software running on those does not have to zero memory containing keys, because the whole environment that said software runs in has been secured from the outside already, and if it's possible to read any memory or run untrusted code from outside on those without being detected, then there are far bigger problems to worry about...

[AlyssaRowan]

Having seen a few existing designs of those, up-close and personal - actually they do have to worry about zeroisation, quite an awful lot.

And sometimes they don't worry enough either. They ought to fail a FIPS-style audit for that. But, well... they ought not to contain proprietary LFSR "crypto" algorithms, either. They are not as well audited, or as publicly designed, as they ought to be: many are as black-box closed-source as they could possibly be.

They tend to be based on extraordinarily old architectures with new bits glued on - think Intel 8051, that kind of era. If you're really lucky you might get an ARM, or at least a Thumb. People making them are notoriously hyper-conservative (most don't support ECC yet, and many don't even go above RSA-2048 or SHA-1 without going to firmware), and minimise any changes, perhaps for cost reasons, the effects of which are not always positive (actually, CFRG are discussing that general area right now in the context of side-channnel defences for elliptic-curve crypto).

So, how would you think that environment translates to writing secure firmware, or designing secure, state-of-the-art hardware? ;-)

[lazyjones]

Are current GPUs suitable subsystems for running properly isolated cryptographic algorithms? If not, why not? If yes, perhaps a well-audited open source library would be possible.

[AlyssaRowan]

In the presence of closed-source drivers that manage them and compile the shaders? I'd say probably not. Something open-source with actual direct access to the opcodes (would Mantle work? Intel's embedded GPUs?)… maybe. I don't know if I'd consider them secure. Some running hot and loud and by the seat of their pants? The presence of DMA? Hm. I have my doubts they'd be better than the CPU safety-wise.

What I do know is they can usually run them very fast if asynchronous low-communication parallelisation is not undesirable - GPUs overtook PlayStation 3 Cell processors for the "throw watts at it, but we don't have enough money to burn FPGAs or ASICs" class of crypto attacks quite a few years ago now. (As anyone who runs a Bitcoin mine knows!)

Might be effective on, say, the Raspberry Pi, where the "GPU"'s the ringmaster and the ARM's the clown. That vector processor looks tempting, and if I could figure out how to get it to do diagonals, it's a poster child for ChaCha.