From: Tadeusz Struk <tadeusz.struk@intel.com>
To: Cristian Stoica <cristian.stoica@nxp.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH 1/3] crypto: authenc - add TLS type encryption
Date: Tue, 8 Mar 2016 08:49:55 -0800 [thread overview]
Message-ID: <56DF02B3.1070006@intel.com> (raw)
In-Reply-To: <AM4PR0401MB1876F5088D4EC6BE577BC97CE7B10@AM4PR0401MB1876.eurprd04.prod.outlook.com>
Hi Cristian,
On 03/08/2016 12:20 AM, Cristian Stoica wrote:
> There is also a follow-up in the next paragraph:
>
> "That pretty much sums up the new attack: the side-channel defenses that were hoped to be sufficient were found not to be (again). So the answer, this time I believe, is to make the processing rigorously constant-time."
>
> The author makes new changes and continues instrumenting the code and still finds 20 CPU cycles (out of 18000) difference between medians for different paddings. This small difference was detected also on a timing side-channel - which is the point I'm making.
>
> SSL/TLS is prone to this implementation issue and many user-space libraries got this wrong. It would be good to see some numbers to back-up the claim of timing differences as not being an issue for this one.
It is hard to get the implementation right when the protocol design is error prone.
Later we should run some tests on it and see how relevant will this be for a remote timing attack.
Thanks,
--
TS
next prev parent reply other threads:[~2016-03-08 16:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-06 1:20 [PATCH 0/3] crypto: af_alg - add TLS type encryption Tadeusz Struk
2016-03-06 1:20 ` [PATCH 1/3] crypto: authenc " Tadeusz Struk
2016-03-07 9:05 ` Cristian Stoica
2016-03-07 14:31 ` Tadeusz Struk
2016-03-08 8:20 ` Cristian Stoica
2016-03-08 16:49 ` Tadeusz Struk [this message]
2016-03-06 1:20 ` [PATCH 2/3] crypto: af_alg - add AEAD operation type Tadeusz Struk
2016-03-06 1:21 ` [PATCH 3/3] crypto: algif_aead - modify algif aead interface to work with encauth Tadeusz Struk
2016-04-05 11:29 ` [PATCH 0/3] crypto: af_alg - add TLS type encryption Herbert Xu
2016-04-06 17:56 ` Tadeusz Struk
2016-04-08 2:52 ` Herbert Xu
2016-04-08 2:58 ` Tom Herbert
2016-04-12 11:13 ` Fridolin Pokorny
2016-04-13 22:46 ` Tadeusz Struk
2016-04-14 6:47 ` Nikos Mavrogiannopoulos
2016-03-09 8:18 [PATCH 1/3] crypto: authenc " Cristian Stoica
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=56DF02B3.1070006@intel.com \
--to=tadeusz.struk@intel.com \
--cc=cristian.stoica@nxp.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).