From: Steffen Klassert <steffen.klassert@secunet.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Miller <davem@davemloft.net>, linux-crypto@vger.kernel.org
Subject: Re: [RFC] [PATCH 2/4] cpu_chainiv: add percpu IV chain genarator
Date: Mon, 30 Mar 2009 13:54:15 +0200 [thread overview]
Message-ID: <20090330115415.GC6791@secunet.com> (raw)
In-Reply-To: <20090327083615.GB27903@gondor.apana.org.au>
On Fri, Mar 27, 2009 at 04:36:15PM +0800, Herbert Xu wrote:
> On Mon, Mar 16, 2009 at 12:52:51PM +0100, Steffen Klassert wrote:
> > If the crypro requests of a crypto transformation are processed in
> > parallel, the usual chain IV generator would serialize the crypto
> > requests again. The percpu IV chain genarator allocates the IV as
> > percpu data and generates percpu IV chains, so a crypro request
> > does not need to wait for the completition of the IV generation
> > from a previous request that runs on a different cpu.
> >
> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
>
> I actually thought about this one when I first wrote chainiv,
> I chose to avoid this because it has some security consequences.
> In particular, an attacker would now be able to infer whether two
> packets belong to two differnt flows from the fact that they came
> from two different IV streams.
>
> In any case, I don't think this is central to your work, right?
>
Well, to do efficient parallel processing we need a percpu IV chain
genarator. pcrypt sends the crypto requests round robin to the cpus
independent of the flow they are belong to, so the flows and the IV
streams are mixing. As long as we use the percpu IV chain genarator just
for parallel algorithms we don't have this security issues.
next prev parent reply other threads:[~2009-03-30 11:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-16 11:49 [RFC] [PATCH 0/4] Parallel IPsec Steffen Klassert
2009-03-16 11:51 ` [RFC] [PATCH 1/4] padata: generic interface for parallel processing Steffen Klassert
2009-03-16 11:52 ` [RFC] [PATCH 2/4] cpu_chainiv: add percpu IV chain genarator Steffen Klassert
2009-03-27 8:36 ` Herbert Xu
2009-03-30 11:54 ` Steffen Klassert [this message]
2009-03-30 13:19 ` Herbert Xu
2009-03-30 14:49 ` Steffen Klassert
2009-04-08 11:40 ` Steffen Klassert
2009-04-09 3:20 ` Herbert Xu
2009-04-14 13:05 ` Steffen Klassert
2009-03-16 11:54 ` [RFC] [PATCH 3/4] pcrypt: Add pcrypt crypto parallelization engine Steffen Klassert
2009-03-16 11:55 ` [RFC] [PATCH 4/4] esp: add the pcrypt hooks to esp Steffen Klassert
2009-03-27 8:44 ` Herbert Xu
2009-03-30 12:22 ` Steffen Klassert
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=20090330115415.GC6791@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.