3 ms·
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 y
by cortesoft 6y ago
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.
- iainmerrick 6y agoI 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.
- hansvm 6y agoRelated 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.