Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: linux-crypto@vger.kernel.org,
	Sebastian Siewior <linux-crypto@ml.breakpoint.cc>
Subject: Re: IV copy strategy
Date: Fri, 16 Nov 2007 19:25:30 +0800	[thread overview]
Message-ID: <20071116112530.GA9399@gondor.apana.org.au> (raw)
In-Reply-To: <20071116111110.GB31765@2ka.mipt.ru>

On Fri, Nov 16, 2007 at 02:11:10PM +0300, Evgeniy Polyakov wrote:
>
> That's a question - should it copy IV back or not?
> Currently it is not required by crypto users.

Well currently we have exactly one crypto user of ablkcipher
in the tree, and that's tcrypt :)

However, looking at the sync crypto users it would seem that
chaining while not popular is used by at least RXKAD.  So I'd
like to preserve this functionality.  Although in light of the
fact that on DMA devices touching the encrypted result to copy
the IV may be expensive, we could make it conditional on a flag
inside the request, i.e., something like

	CRYPTO_TFM_REQ_COPY_IV

But the point is that this is something that has to be done by
the algorithm since only it knows in general what/where the IV
is.  So if the algorithm doesn't do that then the user can't
easily work around this.

Actually on second thought why don't we change the interface
for ablkcipher so that we allow the IV to be returned by either
copying it to req->info or replacing the req->info pointer?

That way if the destination is linear and lowmem at the end we
can just return a pointer to it without touching the data at all.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2007-11-16 11:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-13 23:11 IV copy strategy Sebastian Siewior
2007-11-14 14:22 ` Herbert Xu
2007-11-15 21:10   ` Sebastian Siewior
2007-11-16  2:08     ` Herbert Xu
2007-11-16  8:19       ` Sebastian Siewior
2007-11-16  9:30         ` Herbert Xu
2007-11-16 11:11       ` Evgeniy Polyakov
2007-11-16 11:25         ` Herbert Xu [this message]
2007-11-16 11:42           ` Evgeniy Polyakov
2007-11-16 13:47             ` Herbert Xu
2007-11-18  6:52         ` Herbert Xu
2007-11-18  6:53           ` Herbert Xu
2007-11-19 10:38           ` Evgeniy Polyakov
2007-11-19 11:56             ` Herbert Xu
2007-11-20 14:23               ` Evgeniy Polyakov
2007-11-26  9:10       ` Sebastian Siewior
2007-11-15 21:23   ` [PATCH] [crypto] geode: do not copy the IV too often Sebastian Siewior
2007-11-18 13:41     ` Herbert Xu
2007-11-26  9:25     ` Sebastian Siewior
2007-11-26  9:28       ` Herbert Xu
2007-11-26  9:42         ` Sebastian Siewior
2007-11-27 19:33           ` Sebastian Siewior
2007-11-30  5:37             ` Herbert Xu

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=20071116112530.GA9399@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-crypto@ml.breakpoint.cc \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox