> On Jul 1, 2017, at 4:55 PM, Rob Austein <s...@hactrn.net> wrote: > > At Sat, 1 Jul 2017 09:02:07 +0000, Peter Gutmann wrote: >> >> Rob Austein <s...@hactrn.net> writes: >> >>> https://eprint.iacr.org/2017/627.pdf >> >> Before anyone panics too much, it's just another side-channel attack. In >> this >> case it uses on a cache side-channel (which shouldn't be a problem in an HSM, >> but then it can use other side-channels), and since it requires multiple >> traces should be defeated by standard blinding countermeasures. > > This raises a related question that Pavel and I had already been > discussing off-list. > > At the moment, our RSA code unconditionally blinds when signing. This > is intended primarily as a defense against side channel attacks (I > suppose it might also add some marginal protection against other kinds > of implementation bugs, but side-channel is why we did this). I'm > reasonably certain that we should be doing this when using libtfm's > software modexp; the question is whether this should still be the > default when using one of our (theoretically constant-time) Verilog > modexp implementations. All of this is of course configurable at > compile time, the question is what the default configuration should > be. > > We've left RSA blinding enabled unconditionally in all cases for now, > out of paranoia, but would be interested in opinions from wider heads > about how necessary this really is.
If the Verilog is constant-time and constant-power-consumption, then the major side channels are protected. I doubt that you can do anything about the power consumption from your code. Russ _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
