[Cryptech Tech] RSA blinding (was: Re: Fun RSA implementation vulnerability: left-to-right sliding window modexp)

Russ Housley housley at vigilsec.com
Sat Jul 1 21:00:04 UTC 2017

> On Jul 1, 2017, at 4:55 PM, Rob Austein <sra at hactrn.net> wrote:
> At Sat, 1 Jul 2017 09:02:07 +0000, Peter Gutmann wrote:
>> Rob Austein <sra at 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.


More information about the Tech mailing list