Right now constant time techniques are almost exclusively reserved for code that handles secret keys (e.g. for encryption or digital signatures). But, sadly, t

Right now constant time techniques are almost exclusively reserved for code that handles secret keys (e.g. for encryption or digital signatures). But, sadly, there are applications where the secrets can't just be limited to keys: For example in an anonymous messaging system essentially all the data is secret, as they're usually constructed someone who could perform a timing/cache sidechannel attack against you could potentially determine which messages you were reading (or writing) and discover your identity. So security with those anonymity tools critically depends on the participants being protected against observation-- which would be considered a fairly reckless security assumption if we were talking about the security of your AES disk encryption or ECDSA message signing. I wouldn't go so far as to say that constant time programming is a solved problem for basic crypto-- the fact that languages and instruction sets make few guarantees remains an issue-- but the situation there isn't particularly dire. There are few enough basic primitives and the techniques needed to get protect keys from sidechannels in C are well known, so in practice things are usually pretty good (unless you get into people making crypto code in JS...). But without better tools we can't even start to thinking about extending sidechannel security more elaborate cases. Domain specific languages might help.