4 ms·

I hear so much about "side channel attacks", and I get why they are important if you don't know what software is running on your computer. But are they importan

I hear so much about "side channel attacks", and I get why they are important if you don't know what software is running on your computer. But are they important if you don't run any outside code (not on the cloud, not running JavaScript in a "container", etc?) Are there other major reasons not to roll your own crypto besides "you might do it wrong"? Wouldn't a fuzz tester (comparing your implementation to a known good one) be well adapted to making sure you didn't do it wrong?

klabb3 3y ago
> […] and I get why they are important if you don't know what software is running on your computer. Side channel attacks are not limited to attackers on the same device. Timing attacks can be remote for instance, and with RSA some operations are slow enough to be noticeable over networks. > Wouldn't a fuzz tester (comparing your implementation to a known good one) be well adapted to making sure you didn't do it wrong? Not really. Cryptography is inherently not very conducive to tests, because they can only prove the outcome of specific inputs. You need to be a lot more defensive than that, and use reason, proofs etc to prove properties like “an adversary cannot gain any knowledge about X or Y given that they control Z”. Of course reimplementing a vetted spec like RSA is better than rolling your own primitives which is beyond doomed. OTOH an opportunistic attacker will probably not bother with a custom crypto - it’s still a lot of work to find the flaws. But once found, game over..
- vitiral 3y ago
  > Timing attacks can be remote for instance, and with RSA some operations are slow enough to be noticeable over networks. Huh, I'd be pretty curious about that. > Not really. Cryptography is inherently not very conducive to tests, because they can only prove the outcome of specific inputs I'm pretty confused by this. It's a completely deterministic operation on a series of bytes. If you have identical results to 2 billion randomized inputs how can that not be pretty high confidence that the underlying algorithm is sound? Obviously it's good to do the math and reasoning as well, but... I just don't get it. It's not magic, it's math and bit munging.
  - klabb3 3y ago
    You are right that it increases the confidence. If you’re following a known algorithm conformance- and edge case tests can be a blessing. Of course in the case of RSA you need arbitrary precision bigint math which is another issue with adversarial inputs. (What I meant is that you can’t test whether the algorithm is secure, because you can’t enumerate the weaknesses that a cryptanalyst would attempt.)
    - vitiral 3y ago
      Ah, you can test the implementation but not the algorithm itself. Got it. I see now I said "roll your own crypto" and I should have said something like "reimplement a crypto" To prevent side channel, can't you do something as stupid as add a randomized [0-0.1) second sleep to your crytpographic operations? That would make any difference in your algorithms performance negligible.
      - Kalium 3y ago
        Bottom line: Yes and no. Yes, you can do that. No, it won't really do what you want. The best way I've found to imagine a timing attack is as a set of graphs produced from thousands to millions of data points, each of which is a time measurement. Any given high-level input takes a certain amount of time to process (example: trying a login). Curves - and thus timing side channels - are distinguishable from one another when the curves have different peaks. The width of the (probably bell-shaped) curves are going to be determined by the amount of variance. What happens if you add a little predictable random variance to each operation that's the same in each operation? Each curve probably gets a little wider, but you don't move their peaks relative to one another. At most, it might mean the person carrying out a timing attack needs to gather more data. Timing attacks already work with network noise implicitly doing what you've suggested doing explicitly. You can simulate this yourself. Graph a thousand points of [0-1] and another thousand points of [0-1]+0.1. Superimpose the curves on one another. You may have to use some bucketing to make the curves visible.
        vitiral 3y ago

klabb3 3y ago

> […] and I get why they are important if you don't know what software is running on your computer. Side channel attacks are not limited to attackers on the same device. Timing attacks can be remote for instance, and with RSA some operations are slow enough to be noticeable over networks. > Wouldn't a fuzz tester (comparing your implementation to a known good one) be well adapted to making sure you didn't do it wrong? Not really. Cryptography is inherently not very conducive to tests, because they can only prove the outcome of specific inputs. You need to be a lot more defensive than that, and use reason, proofs etc to prove properties like “an adversary cannot gain any knowledge about X or Y given that they control Z”. Of course reimplementing a vetted spec like RSA is better than rolling your own primitives which is beyond doomed. OTOH an opportunistic attacker will probably not bother with a custom crypto - it’s still a lot of work to find the flaws. But once found, game over..

vitiral 3y ago
> Timing attacks can be remote for instance, and with RSA some operations are slow enough to be noticeable over networks. Huh, I'd be pretty curious about that. > Not really. Cryptography is inherently not very conducive to tests, because they can only prove the outcome of specific inputs I'm pretty confused by this. It's a completely deterministic operation on a series of bytes. If you have identical results to 2 billion randomized inputs how can that not be pretty high confidence that the underlying algorithm is sound? Obviously it's good to do the math and reasoning as well, but... I just don't get it. It's not magic, it's math and bit munging.
- klabb3 3y ago
  You are right that it increases the confidence. If you’re following a known algorithm conformance- and edge case tests can be a blessing. Of course in the case of RSA you need arbitrary precision bigint math which is another issue with adversarial inputs. (What I meant is that you can’t test whether the algorithm is secure, because you can’t enumerate the weaknesses that a cryptanalyst would attempt.)
  - vitiral 3y ago
    Ah, you can test the implementation but not the algorithm itself. Got it. I see now I said "roll your own crypto" and I should have said something like "reimplement a crypto" To prevent side channel, can't you do something as stupid as add a randomized [0-0.1) second sleep to your crytpographic operations? That would make any difference in your algorithms performance negligible.
    - Kalium 3y ago
      Bottom line: Yes and no. Yes, you can do that. No, it won't really do what you want. The best way I've found to imagine a timing attack is as a set of graphs produced from thousands to millions of data points, each of which is a time measurement. Any given high-level input takes a certain amount of time to process (example: trying a login). Curves - and thus timing side channels - are distinguishable from one another when the curves have different peaks. The width of the (probably bell-shaped) curves are going to be determined by the amount of variance. What happens if you add a little predictable random variance to each operation that's the same in each operation? Each curve probably gets a little wider, but you don't move their peaks relative to one another. At most, it might mean the person carrying out a timing attack needs to gather more data. Timing attacks already work with network noise implicitly doing what you've suggested doing explicitly. You can simulate this yourself. Graph a thousand points of [0-1] and another thousand points of [0-1]+0.1. Superimpose the curves on one another. You may have to use some bucketing to make the curves visible.
      - vitiral 3y ago