4 ms·

This is true for every piece of software, isn't it!? You can have 2 identical websites, one checks your username+password for real, the other always logs you in

This is true for every piece of software, isn't it!? You can have 2 identical websites, one checks your username+password for real, the other always logs you in. Or even better, one stores bcrypted passwords, then other cleartext ones... Use battle tested frameworks. For crypto, for sites, for everything.

cortesoft 6y ago
This goes beyond that, though... in your example, the two programs DON’T give identical output with identical input; one will log you in with a bad password, one won’t. That is different behavior. Likewise, with your second example, the storing clear text and bcrypted passwords are different outputs. When I say the two pieces of code have identical outputs for identical inputs, I mean everything, not just what an end user sees. Here is a toy example to show what I mean: say you have a function that takes a username and password, and compares it against a stored username and password (lets ignore the insecurity of storing a plain text password for this example). Now, you have two implementations of the function, and we know that both work as desired; they both will accept all correct username/password combos, and will reject all incorrect username/password combos. We have exhaustive tests proving that both return the same result when given the same input. Normally, this is good enough - both functions are interchangeable, because they are guaranteed to always output the same data with the same input. You would probably choose the implementation that is faster, or used less memory, or whatever. However, for crypto, this isn’t enough. Lets say in our exmaple, one implementation starts checking each bit of the password. If the first bit of the submitted password matches the first bit of the stored password, it moves to the next bit. If they don't match, it returns false because it knows that the passwords don't match. What a great optimization! You don't have to keep checking once you hit the first wrong bit. The second implementation checks every bit, even after it finds an incorrect match. So inefficient! However, even though they both work perfectly in the sense that they will always return the correct result, the one that returns false on the first mismatched bit is vulnerable to a timing attack. An attacker can keep submitting passwords, and wait for the response to get a little bit slower... now they know they have the first bit correct. Repeat this for a while, and you can figure out all the bits. This is obviously a toy example, but this technique has been used over and over again to break crypto implementations. You have to care about more than just the output when you deal with crypto! Here is a paper about using this technique to break an earlier version of OpenSSL: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
- nbadg 6y ago
  > 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.
  - drewcoo 6y ago
    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.
    - nbadg 6y ago
      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.
  - cortesoft 6y ago
meowface 6y ago
That's a little different, because those websites are network services that are essentially black boxes to you. With cryptography, you can not only have two local programs, but you can have the source code for two programs and compile them yourself [1] but still have no clue if one is horribly flawed or not. At least without hiring seasoned cryptography experts to perform a rigorous analysis; and even then, who knows. The same could be said when using a native application with an undiscovered use-after-free vulnerability or something, but in that case there are some theoretical inputs that'll cause the program to behave in a way you don't expect, like crashing or corrupting data, whereas with flawed cryptography the flaw may never give the slightest hint of its presence no matter how much or what kind of input you throw at it. [1] For the sake of argument, let's say there's no risk of any kind of backdoors or "Reflections on Trusting Trust"-style hijinks
loup-vaillant 6y ago
> Use battle tested frameworks. For crypto, for sites, for everything. In other words, don't roll your own… anything? Just, no. Down that path is lost knowledge and the decline of our civilization. Enough of us must know the fundamentals. https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk

cortesoft 6y ago

This goes beyond that, though... in your example, the two programs DON’T give identical output with identical input; one will log you in with a bad password, one won’t. That is different behavior. Likewise, with your second example, the storing clear text and bcrypted passwords are different outputs. When I say the two pieces of code have identical outputs for identical inputs, I mean everything, not just what an end user sees. Here is a toy example to show what I mean: say you have a function that takes a username and password, and compares it against a stored username and password (lets ignore the insecurity of storing a plain text password for this example). Now, you have two implementations of the function, and we know that both work as desired; they both will accept all correct username/password combos, and will reject all incorrect username/password combos. We have exhaustive tests proving that both return the same result when given the same input. Normally, this is good enough - both functions are interchangeable, because they are guaranteed to always output the same data with the same input. You would probably choose the implementation that is faster, or used less memory, or whatever. However, for crypto, this isn’t enough. Lets say in our exmaple, one implementation starts checking each bit of the password. If the first bit of the submitted password matches the first bit of the stored password, it moves to the next bit. If they don't match, it returns false because it knows that the passwords don't match. What a great optimization! You don't have to keep checking once you hit the first wrong bit. The second implementation checks every bit, even after it finds an incorrect match. So inefficient! However, even though they both work perfectly in the sense that they will always return the correct result, the one that returns false on the first mismatched bit is vulnerable to a timing attack. An attacker can keep submitting passwords, and wait for the response to get a little bit slower... now they know they have the first bit correct. Repeat this for a while, and you can figure out all the bits. This is obviously a toy example, but this technique has been used over and over again to break crypto implementations. You have to care about more than just the output when you deal with crypto! Here is a paper about using this technique to break an earlier version of OpenSSL: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

nbadg 6y ago
> 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.
- drewcoo 6y ago
  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.
  - nbadg 6y ago
    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.
- cortesoft 6y ago

meowface 6y ago

That's a little different, because those websites are network services that are essentially black boxes to you. With cryptography, you can not only have two local programs, but you can have the source code for two programs and compile them yourself [1] but still have no clue if one is horribly flawed or not. At least without hiring seasoned cryptography experts to perform a rigorous analysis; and even then, who knows. The same could be said when using a native application with an undiscovered use-after-free vulnerability or something, but in that case there are some theoretical inputs that'll cause the program to behave in a way you don't expect, like crashing or corrupting data, whereas with flawed cryptography the flaw may never give the slightest hint of its presence no matter how much or what kind of input you throw at it. [1] For the sake of argument, let's say there's no risk of any kind of backdoors or "Reflections on Trusting Trust"-style hijinks

loup-vaillant 6y ago

> Use battle tested frameworks. For crypto, for sites, for everything. In other words, don't roll your own… anything? Just, no. Down that path is lost knowledge and the decline of our civilization. Enough of us must know the fundamentals. https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk