> When I say the two pieces of code have identical outputs for identical inputs, I mean everything, not just what an end user sees.
But that's exactly the trouble with side channels: you've just defined "outputs" and "inputs" in a way that excludes them. If you widen your lens a bit to include, say, the timing of the code as an output, or even further to the physical changes of bits in hardware, then the outputs and inputs are no longer identical.
You can even extend that to the lock metaphor: when you pick a lock, you're using the tumbler itself as an "extra" input, and the feel of the pins as an "extra" output, instead of just the position of the pins. The tumbler and the feeling were there all along; it's not that they're really extra inputs or outputs, we just don't normally pay attention to them. Unless you take up lockpicking.
You're missing the point: in and out data via intended usage. Trying to move the goalposts afterward doesn't actually change what was intended. Consider ecesena's examples:
> 2 identical websites, one checks your username+password for real, the other always logs you in.
In that case, it's not a side channel. Presumably the intended use of authentication includes turning away bad credentials.
> one stores bcrypted passwords, then other cleartext ones...
That is an implementation detail. In itself, it's not a side channel because there's no way in the scenario to get the passwords. That cleartext implementation would appear at least as tough against timing attacks as bcrypt, in fact, because it would always decrypt all cleartext passwords in the same time - no info leak there.
I'm not. I get the distinction. The point I'm trying to make is that only considering the intended usage is an incorrect approach to design. The consequences of this constrained thinking can be particularly extreme in infosec, but it's just as true of software in general, or even, say, consumer products -- hence seeing all sorts of weird disclaimers on them these days.
Right, I understand that once you understand how side channels work that you can effectively program to avoid them.
My only point is that it is not something you normally have to deal with when you program. Normally, you are only worried about the inputs and outputs that you are intentionally interacting with. Side channels involve ones that you might not have even known existed.
I don’t think this is completely unique to crypto, there are plenty of cases in “normal” programming where you care about more things beyond inputs and outputs.
For example, two search algorithms give identical results, but one is O(n) and the other is O(n^2). They’ll both appear to work fine but one will catastrophically break down on certain inputs.
A similar one is where you have an O(1) hash table, but the hash function is vulnerable to collisions and sometimes explodes. That one starts to overlap with crypto in that it could be the basis of a DoS attack.
Besides running time, you might also care about memory usage, or designing an API that’s easy to use and robust against user error.
Related examples that come up in the web domain include:
(1) Zip bombs -- Do you accept compressed user content by first unzipping it and then examining the data? Good luck with the OOM.
(2) Catastrophic backtracking -- Are you still using regex to parse urls/emails? You're almost certainly using a library with worst-case exponential run-time rather than linear.
And so on. If the natural way to solve a problem is self-referencing you're almost certainly going to expose yourself to exponential memory/time consumption for malicious inputs.
But that's exactly the trouble with side channels: you've just defined "outputs" and "inputs" in a way that excludes them. If you widen your lens a bit to include, say, the timing of the code as an output, or even further to the physical changes of bits in hardware, then the outputs and inputs are no longer identical.
You can even extend that to the lock metaphor: when you pick a lock, you're using the tumbler itself as an "extra" input, and the feel of the pins as an "extra" output, instead of just the position of the pins. The tumbler and the feeling were there all along; it's not that they're really extra inputs or outputs, we just don't normally pay attention to them. Unless you take up lockpicking.