2021.05.02 19:07:11 (1388902902832369665) from Daniel J. Bernstein, replying to "Luca De Feo (@luca_defeo)" (1388815575468724228):
The SIKE implementation CCA disaster, from trying to stop FO timing attacks, is a perfect example of why protecting SIKE (1) isn't easy and (2) isn't like ECC. People also keep publishing papers on ECC side-channel attacks. "Not many SIKE papers ergo secure" is a flimsy argument.
2021.05.02 08:47:12 (1388746881723817993) from Daniel J. Bernstein, replying to "Luca De Feo (@luca_defeo)" (1388408596703109122):
The official SIKE code screwed up constant-time comparisons, allowing a CCA attack in December. Defending against more invasive side channels is harder. The necessary security analysis has barely started. The broader literature is full of breaks of overconfident security claims.
2021.05.02 13:09:43 (1388812944734048257) from "Luca De Feo (@luca_defeo)":
I don't see how the constant-time screw-up is relevant: Craig is claiming the algorithm, not a specific implementation, is sufficiently protected using well known techniques.
2021.05.02 13:11:35 (1388813415796428801) from "Luca De Feo (@luca_defeo)", replying to "Luca De Feo (@luca_defeo)" (1388812944734048257):
For having worked on this, I concur: it's not easy to imagine attacks on SIKE which are not already known ECC attacks. Indeed, with few exceptions, the side-channel literature on SIKE has so far stuck to reproducing well known attacks.
2021.05.02 13:20:10 (1388815575468724228) from "Luca De Feo (@luca_defeo)", replying to "Luca De Feo (@luca_defeo)" (1388813415796428801):
This leads to a paradoxical situation: working on side-channel security of SIKE is unrewarding, so researchers stand clear of it. How do you make a case for side-channel security of an algorithm that already may be side-channel secure?