4 ms·

"You could have invented that Bluetooth attack" Proceeds to explain elliptic curve mechanics that would make most readers completely glaze over. Maybe they me

by joecot 8y ago

"You could have invented that Bluetooth attack" Proceeds to explain elliptic curve mechanics that would make most readers completely glaze over. Maybe they mean they just mean their normal reader base, who has an attention span for those sorts of details? Their assertion that an average reader could understand the attack might be true, but the "could have invented" is a a bit far fetched.

munin 8y ago
I think the argument is something like: you could understand what invalid curve point attacks are, and once you did, you could look for them everywhere, and if you did that, you would have found this error as well. The math behind invalid curve point attacks is pretty straightforward, it's some polynomials and points on the Cartesian plane. You saw this stuff in elementary school. Then, someone needs to point out to you "oh check out what happens if you allow for invalid points" and now you have a pattern to go hunting for. Then it's luck - do you get to Bluetooth before someone else, or do you find something else, or do you just re-discover other peoples stuff? Maybe it's elitist to say "the math is pretty straightforward" but you know what, it's a system of two variables and you can plot it. You need to know about division, multiplication, and modular variants. No monads, no tensors, no mixed Gaussians or method of moments or greek letters or 128 dimensional spheroids. Maybe that kind of math makes your eyes glaze over but I am pretty confident that if you cleared your mind and sat down with pencil and paper and gave it an hours honest effort, you would come away with an understanding.
- tptacek 8y ago
  You definitely didn't do the math for invalid curve attacks in grade school, since you also need CRT and the notion of group order. But I think your first sentence gives a great charitable interpretation of the title. A way I like to think about these things --- from the perspective of a vulnerability researcher, not a cryptographer or mathematician (I am neither of those) --- is that there is a very little bit of math you need to put some extra tools in your belt, and then the rest of it is programming; working through these kinds of exploits feels a lot like implementing heapsort or a spanning tree reduction for the first time feels like. I find that empowering, because while I can't bang out Kruskal's algorithm off the top of my head, I know if I sit down with it for 20-30 minutes I'll get it working. After a little bit of reading (an hour or two tops), same with this attack.
- barbecue_sauce 8y ago
  Where did you go to elementary school?
dguido 8y ago
For reference, here is the part of the blog where the attack is explained: > Putting this all together, if Chuck replaces one of the points Alice and Bob send each other, (x, y), with (x, 0), then Alice or Bob multiplies it by their secret key, there’s a 50% chance they get the point at infinity and a 50% chance they get (x, 0). If Chuck replaces both intermediate messages, there’s a 25% chance that Alice and Bob agree the secret key is the point at infinity, and no chance they agree on any other key. This means either ECDH fails and Alice and Bob have to retry (giving Chuck another chance), or Chuck knows the secret key and can read and insert messages. tl;dr replace a thing with 0 and watch a cluster of screwups happen. You can probably learn a very limited amount of cryptography or math and, simply knowing that this behavior exists, find invalid curve point vulnerabilities in deployed cryptographic code.
wolf550e 8y ago
Look, some attacks are just going over the RFC, finding each MUST in the text (or MUST NOT or a SHOULD that really should have been a MUST, etc.), understanding that this "MUST" means (usually) a requirement for the presence of an "if" statement in the code [1], and then looking for that if statement in the code. If it is possible to interoperate with real world endpoints (basically Apache on openssl 1.0.2 and IIS on SChannel on latest Windows for servers, Chrome and MSIE as clients) with a codebase that lacks that if statement, someone has deployed in production a codebase that lacks this if statement. So unless someone already found it (that someone is probably Hanno Böck), you're going to be the first to find it. Now you can look for protocols that use the same construction as other protocols but did not copy-paste the MUST sentence. If the spec forgot to say the MUST sentence, you're going to find many more implementations that lack the corresponding if statement. 1 - instead of an if statement, sometimes it means "fill this buffer by reading X bytes from /dev/urandom" but the code just does memset with 0.

by joecot 8y ago

munin 8y ago

I think the argument is something like: you could understand what invalid curve point attacks are, and once you did, you could look for them everywhere, and if you did that, you would have found this error as well. The math behind invalid curve point attacks is pretty straightforward, it's some polynomials and points on the Cartesian plane. You saw this stuff in elementary school. Then, someone needs to point out to you "oh check out what happens if you allow for invalid points" and now you have a pattern to go hunting for. Then it's luck - do you get to Bluetooth before someone else, or do you find something else, or do you just re-discover other peoples stuff? Maybe it's elitist to say "the math is pretty straightforward" but you know what, it's a system of two variables and you can plot it. You need to know about division, multiplication, and modular variants. No monads, no tensors, no mixed Gaussians or method of moments or greek letters or 128 dimensional spheroids. Maybe that kind of math makes your eyes glaze over but I am pretty confident that if you cleared your mind and sat down with pencil and paper and gave it an hours honest effort, you would come away with an understanding.

tptacek 8y ago
You definitely didn't do the math for invalid curve attacks in grade school, since you also need CRT and the notion of group order. But I think your first sentence gives a great charitable interpretation of the title. A way I like to think about these things --- from the perspective of a vulnerability researcher, not a cryptographer or mathematician (I am neither of those) --- is that there is a very little bit of math you need to put some extra tools in your belt, and then the rest of it is programming; working through these kinds of exploits feels a lot like implementing heapsort or a spanning tree reduction for the first time feels like. I find that empowering, because while I can't bang out Kruskal's algorithm off the top of my head, I know if I sit down with it for 20-30 minutes I'll get it working. After a little bit of reading (an hour or two tops), same with this attack.
barbecue_sauce 8y ago
Where did you go to elementary school?

dguido 8y ago

For reference, here is the part of the blog where the attack is explained: > Putting this all together, if Chuck replaces one of the points Alice and Bob send each other, (x, y), with (x, 0), then Alice or Bob multiplies it by their secret key, there’s a 50% chance they get the point at infinity and a 50% chance they get (x, 0). If Chuck replaces both intermediate messages, there’s a 25% chance that Alice and Bob agree the secret key is the point at infinity, and no chance they agree on any other key. This means either ECDH fails and Alice and Bob have to retry (giving Chuck another chance), or Chuck knows the secret key and can read and insert messages. tl;dr replace a thing with 0 and watch a cluster of screwups happen. You can probably learn a very limited amount of cryptography or math and, simply knowing that this behavior exists, find invalid curve point vulnerabilities in deployed cryptographic code.

wolf550e 8y ago

Look, some attacks are just going over the RFC, finding each MUST in the text (or MUST NOT or a SHOULD that really should have been a MUST, etc.), understanding that this "MUST" means (usually) a requirement for the presence of an "if" statement in the code [1], and then looking for that if statement in the code. If it is possible to interoperate with real world endpoints (basically Apache on openssl 1.0.2 and IIS on SChannel on latest Windows for servers, Chrome and MSIE as clients) with a codebase that lacks that if statement, someone has deployed in production a codebase that lacks this if statement. So unless someone already found it (that someone is probably Hanno Böck), you're going to be the first to find it. Now you can look for protocols that use the same construction as other protocols but did not copy-paste the MUST sentence. If the spec forgot to say the MUST sentence, you're going to find many more implementations that lack the corresponding if statement. 1 - instead of an if statement, sometimes it means "fill this buffer by reading X bytes from /dev/urandom" but the code just does memset with 0.