From: Stephan Mueller <smueller@chronox.de>
To: Tudor-Dan Ambarus <tudor-dan.ambarus@nxp.com>
Cc: "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
Horia Ioan Geanta Neag <horia.geanta@nxp.com>,
Ronald Harvey <ron.harvey@nxp.com>
Subject: Re: [PATCH v6 0/3] crypto: caam - add support for RSA algorithm
Date: Tue, 24 May 2016 18:58:03 +0200 [thread overview]
Message-ID: <2874209.GQE6GP7zM1@positron.chronox.de> (raw)
In-Reply-To: <AMSPR04MB5360B73458157BC926CB57EB84F0@AMSPR04MB536.eurprd04.prod.outlook.com>
Am Dienstag, 24. Mai 2016, 16:13:48 schrieb Tudor-Dan Ambarus:
Hi Tudor,
> Hi Stephan,
>
> > > > as I am looking into the RSA countermeasures, I am wondering how much
> >
> > of
> >
> > > > countermeasures are actually applied inside hardware implementations.
> > >
> > > Please point me to the reference RSA countermeasures so that we have
> > > a common point of start.
> >
> > As the entire MPI logic is derived from libgcrypt, I am planning to use
> > the
> > libgcrypt implementation as a basis to implement the blinding defined by
> > the
> > Handbook of Applied Cryptograpy 11.118/11.119.
>
> When using private key operation commands, our hardware provides
> 'timing equalization' to hide key information from timing attacks such that
> the modular exponentiation will take the same amount of time for a given
> byte length of N combined with a given byte length of the exponent.
Great, that is the other countermeasure option for RSA. So, your
implementation would be covered.
I guess it would make sense to implement countermeasures on an as-needed basis
then.
>
> The other part of timing equalization causes each bit of exponent to take
> the same amount of time to process. In normal exponentiation, a one bit
> takes two multiplies, while a zero bit takes just one. In timing
> equalization, a zero bit causes an extra, but 'fake' multiply.
Good, so you have two types of countermeasures it seems. Again, you should be
good then.
Ciao
Stephan
prev parent reply other threads:[~2016-05-24 16:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 12:15 [PATCH v6 0/3] crypto: caam - add support for RSA algorithm Tudor Ambarus
2016-05-19 12:15 ` [PATCH v6 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks Tudor Ambarus
2016-05-19 12:15 ` [PATCH v6 2/3] crypto: scatterwalk - export scatterwalk_pagedone Tudor Ambarus
2016-05-19 12:15 ` [PATCH v6 3/3] crypto: caam - add support for RSA algorithm Tudor Ambarus
2016-05-19 15:13 ` Horia Ioan Geanta Neag
2016-05-19 15:45 ` [PATCH v6 0/3] " Horia Ioan Geanta Neag
2016-05-19 21:51 ` Stephan Mueller
2016-05-23 12:56 ` Tudor-Dan Ambarus
2016-05-23 13:02 ` Stephan Mueller
2016-05-24 16:13 ` Tudor-Dan Ambarus
2016-05-24 16:58 ` Stephan Mueller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2874209.GQE6GP7zM1@positron.chronox.de \
--to=smueller@chronox.de \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=ron.harvey@nxp.com \
--cc=tudor-dan.ambarus@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox