Linux cryptographic layer development
 help / color / mirror / Atom feed
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

      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