All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Mike Brooks <m@ib.tc>, Ard Biesheuvel <ardb@kernel.org>,
	Kestrel seventyfour <kestrelseventyfour@gmail.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: or should block size for xts.c set to 1 instead of AES block size?
Date: Fri, 14 May 2021 16:05:53 +0800	[thread overview]
Message-ID: <20210514080553.bogfwvq6vs6wvdch@gondor.apana.org.au> (raw)
In-Reply-To: <YJrbhR/EruMOMHd9@gmail.com>

On Tue, May 11, 2021 at 12:31:17PM -0700, Eric Biggers wrote:
>
> Well, the problem is that it isn't well defined what the cra_blocksize property
> actually means.  Depending on the algorithm, it can mean either the minimum
> input size, the required alignment of the input size, the exact input size that
> is required (in the case of block ciphers), or the input size that is required
> by the algorithm's internal compression function (in the case of hashes).
> 
> "xts" follows the convention of cra_blocksize meaning the "minimum input size",
> as do "cts" and "adiantum" which have the same constraints on input sizes as
> "xts".
> 
> So I'm not sure that changing cra_blocksize for xts to 1 would accomplish
> anything useful, other than confuse things further.

At this point we can't change the blocksize of cts/xts to 1 without
breaking af_alg because it needs to treat them differently than it
would for a stream cipher like ctr.

But to properly support af_alg on cts/xts we do need to do this.
I have a patch-set that adds the final chunk size to do exactly
that but I haven't had the time to finish it.

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

      reply	other threads:[~2021-05-14  8:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-07  6:12 or should block size for xts.c set to 1 instead of AES block size? Kestrel seventyfour
2021-05-11 15:48 ` Ard Biesheuvel
2021-05-11 18:01   ` Mike Brooks
2021-05-11 19:31     ` Eric Biggers
2021-05-14  8:05       ` Herbert Xu [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=20210514080553.bogfwvq6vs6wvdch@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=kestrelseventyfour@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=m@ib.tc \
    /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.