From: Ard Biesheuvel <ardb@kernel.org> To: Herbert Xu <herbert@gondor.apana.org.au> Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Eric Biggers <ebiggers@kernel.org>, Stephan Mueller <smueller@chronox.de> Subject: Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Date: Fri, 29 May 2020 14:00:14 +0200 [thread overview] Message-ID: <CAMj1kXFFPKWwwSpLnPmNa_Up1syMb7T5STG7Tw8mRuRqSzc9vw@mail.gmail.com> (raw) In-Reply-To: <20200529115126.GA3573@gondor.apana.org.au> On Fri, 29 May 2020 at 13:51, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Fri, May 29, 2020 at 10:20:27AM +0200, Ard Biesheuvel wrote: > > > > But many implementation do not return an output IV at all. The only > > mode that requires it (for the selftests to pass) is CBC. > > Most modes can be chained, e.g., CBC, PCBC, OFB, CFB and CTR. > As it stands algif_skcipher requres all algorithms to support > chaining. > Even if this is the case, it requires that an skcipher implementation stores an output IV in the buffer that skcipher request's IV field points to. Currently, we only check whether this is the case for CBC implementations, and so it is quite likely that lots of h/w accelerators or arch code don't adhere to this today. > > For XTS, we would have to carry some metadata around that tells you > > whether the initial encryption of the IV has occurred or not. In the > > You're right, XTS in its current form cannot be chained. So we > do need a way to mark that for algif_skcipher. > > > CTS case, you need two swap the last two blocks of ciphertext at the > > very end. > > CTS can be easily chained. You just need to always keep two blocks > from being processed until you reach the end. > This might be feasible for the generic CTS driver wrapping h/w accelerated CBC. But how is this supposed to work, e.g., for the two existing h/w implementations of cts(cbc(aes)) that currently ignore this?
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org> To: Herbert Xu <herbert@gondor.apana.org.au> Cc: Eric Biggers <ebiggers@kernel.org>, Stephan Mueller <smueller@chronox.de>, Linux Crypto Mailing List <linux-crypto@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Date: Fri, 29 May 2020 14:00:14 +0200 [thread overview] Message-ID: <CAMj1kXFFPKWwwSpLnPmNa_Up1syMb7T5STG7Tw8mRuRqSzc9vw@mail.gmail.com> (raw) In-Reply-To: <20200529115126.GA3573@gondor.apana.org.au> On Fri, 29 May 2020 at 13:51, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Fri, May 29, 2020 at 10:20:27AM +0200, Ard Biesheuvel wrote: > > > > But many implementation do not return an output IV at all. The only > > mode that requires it (for the selftests to pass) is CBC. > > Most modes can be chained, e.g., CBC, PCBC, OFB, CFB and CTR. > As it stands algif_skcipher requres all algorithms to support > chaining. > Even if this is the case, it requires that an skcipher implementation stores an output IV in the buffer that skcipher request's IV field points to. Currently, we only check whether this is the case for CBC implementations, and so it is quite likely that lots of h/w accelerators or arch code don't adhere to this today. > > For XTS, we would have to carry some metadata around that tells you > > whether the initial encryption of the IV has occurred or not. In the > > You're right, XTS in its current form cannot be chained. So we > do need a way to mark that for algif_skcipher. > > > CTS case, you need two swap the last two blocks of ciphertext at the > > very end. > > CTS can be easily chained. You just need to always keep two blocks > from being processed until you reach the end. > This might be feasible for the generic CTS driver wrapping h/w accelerated CBC. But how is this supposed to work, e.g., for the two existing h/w implementations of cts(cbc(aes)) that currently ignore this? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-29 12:00 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-19 19:02 [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Ard Biesheuvel 2020-05-19 19:02 ` Ard Biesheuvel 2020-05-19 19:02 ` [RFC/RFT PATCH 1/2] crypto: arm64/aes - align output IV with generic CBC-CTS driver Ard Biesheuvel 2020-05-19 19:02 ` Ard Biesheuvel 2020-05-19 19:02 ` [RFC/RFT PATCH 2/2] crypto: testmgr - add output IVs for AES-CBC with ciphertext stealing Ard Biesheuvel 2020-05-19 19:02 ` Ard Biesheuvel 2020-05-19 19:04 ` [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr Ard Biesheuvel 2020-05-19 19:04 ` Ard Biesheuvel 2020-05-20 6:03 ` Stephan Mueller 2020-05-20 6:03 ` Stephan Mueller 2020-05-20 6:40 ` Ard Biesheuvel 2020-05-20 6:40 ` Ard Biesheuvel 2020-05-20 6:47 ` Stephan Mueller 2020-05-20 6:47 ` Stephan Mueller 2020-05-20 6:54 ` Ard Biesheuvel 2020-05-20 6:54 ` Ard Biesheuvel 2020-05-20 7:01 ` Stephan Mueller 2020-05-20 7:01 ` Stephan Mueller 2020-05-20 7:09 ` Ard Biesheuvel 2020-05-20 7:09 ` Ard Biesheuvel 2020-05-21 13:01 ` Gilad Ben-Yossef 2020-05-21 13:01 ` Gilad Ben-Yossef 2020-05-21 13:23 ` Ard Biesheuvel 2020-05-21 13:23 ` Ard Biesheuvel 2020-05-23 18:52 ` Stephan Müller 2020-05-23 18:52 ` Stephan Müller 2020-05-23 22:40 ` Ard Biesheuvel 2020-05-23 22:40 ` Ard Biesheuvel 2020-05-28 7:33 ` Herbert Xu 2020-05-28 7:33 ` Herbert Xu 2020-05-28 8:33 ` Ard Biesheuvel 2020-05-28 8:33 ` Ard Biesheuvel 2020-05-29 8:05 ` Herbert Xu 2020-05-29 8:05 ` Herbert Xu 2020-05-29 8:20 ` Ard Biesheuvel 2020-05-29 8:20 ` Ard Biesheuvel 2020-05-29 11:51 ` Herbert Xu 2020-05-29 11:51 ` Herbert Xu 2020-05-29 12:00 ` Ard Biesheuvel [this message] 2020-05-29 12:00 ` Ard Biesheuvel 2020-05-29 12:02 ` Herbert Xu 2020-05-29 12:02 ` Herbert Xu 2020-05-29 13:10 ` Ard Biesheuvel 2020-05-29 13:10 ` Ard Biesheuvel 2020-05-29 13:19 ` Herbert Xu 2020-05-29 13:19 ` Herbert Xu 2020-05-29 13:41 ` Ard Biesheuvel 2020-05-29 13:41 ` Ard Biesheuvel 2020-05-29 13:42 ` Herbert Xu 2020-05-29 13:42 ` Herbert Xu 2020-06-12 12:06 ` [PATCH 0/3] crypto: skcipher - Add support for no chaining and partial chaining Herbert Xu 2020-06-12 12:07 ` [PATCH 1/3] crypto: skcipher - Add final chunk size field for chaining Herbert Xu 2020-06-12 12:15 ` Stephan Mueller 2020-06-12 12:16 ` Herbert Xu 2020-06-12 12:21 ` [v2 PATCH 0/3] crypto: skcipher - Add support for no chaining and partial chaining Herbert Xu 2020-06-12 12:21 ` [v2 PATCH 1/3] crypto: skcipher - Add final chunk size field for chaining Herbert Xu 2020-06-12 12:21 ` [v2 PATCH 2/3] crypto: algif_skcipher - Add support for fcsize Herbert Xu 2020-06-12 12:21 ` [v2 PATCH 3/3] crypto: cts - Add support for chaining Herbert Xu 2020-06-12 16:10 ` [v2 PATCH 0/3] crypto: skcipher - Add support for no chaining and partial chaining Ard Biesheuvel 2020-06-15 7:30 ` Herbert Xu 2020-06-15 7:50 ` Ard Biesheuvel 2020-06-15 18:50 ` Eric Biggers 2020-06-15 23:18 ` Ard Biesheuvel 2020-06-16 11:04 ` Herbert Xu 2020-06-16 16:53 ` Eric Biggers 2020-06-12 12:07 ` [PATCH 2/3] crypto: algif_skcipher - Add support for fcsize Herbert Xu 2020-06-12 12:07 ` [PATCH 3/3] crypto: cts - Add support for chaining 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=CAMj1kXFFPKWwwSpLnPmNa_Up1syMb7T5STG7Tw8mRuRqSzc9vw@mail.gmail.com \ --to=ardb@kernel.org \ --cc=ebiggers@kernel.org \ --cc=herbert@gondor.apana.org.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-crypto@vger.kernel.org \ --cc=smueller@chronox.de \ /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: linkBe 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.