Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1422673

Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

From Herbert Xu <herbert@gondor.apana.org.au>
Newsgroups linux.kernel
Subject Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
Date 2016-06-15 09:00 +0200
Message-ID <rKcXT-7xD-1@gated-at.bofh.it> (permalink)
References <rHo9b-2Ai-5@gated-at.bofh.it> <rHo9b-2Ai-3@gated-at.bofh.it> <rHq1j-3KB-17@gated-at.bofh.it> <rHB6q-2jK-3@gated-at.bofh.it> <rKcuR-7lr-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote:
> 
> After some investigation, I still think we should divide the bulk
> request from dm-crypt into small request (each one is 512bytes) if
> this algorithm is not support bulk mode (like CBC). We have talked
> with dm-crypt
> maintainers why dm-crypt always use 512 bytes as one request size in
> below thread, could you please check it?
> http://www.kernelhub.org/?p=2&msg=907022

That link only points to an email about an oops.

Diggin through that thread, the only objection I have seen is about
the fact that you have to generate a fresh IV for each sector, which
is precisely what I'm suggesting that you do.

IOW, implement the IV generators in the crypto API, and then you can
easily generate a new IV (if necessary) for each sector.

> That means if we move the IV handling into crypto API, we still can
> not use bulk interface for all algorithm, for example we still need to
> read/write with 512 bytes for CBC, you can't use 4k or more block on
> CBC (and most other encryption modes). If only a part of 4k block is
> written (and then system crash happens), CBC would corrupt the block
> completely. It means if we map one whole bio with bulk interface in
> dm-crypt, we need to divide into every 512 bytes requests in crypto
> layer. So I don't think we can handle every algorithm with bulk
> interface just moving the IV handling into crypto API. Thanks.

Of course you would do CBC in 512-byte blocks, but my point is that
you should do this in a crypto API algorithm, rather than dm-crypt
as we do now.  Once you implement that then dm-crypt can treat
every algorithm as if they supported bulk processing.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Baolin Wang <baolin.wang@linaro.org> - 2016-06-15 08:30 +0200
  Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Herbert Xu <herbert@gondor.apana.org.au> - 2016-06-15 09:00 +0200
    Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Baolin Wang <baolin.wang@linaro.org> - 2016-06-15 09:40 +0200
      Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Herbert Xu <herbert@gondor.apana.org.au> - 2016-06-15 09:50 +0200
        Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Baolin Wang <baolin.wang@linaro.org> - 2016-06-15 10:50 +0200

csiph-web