From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F757C76191 for ; Thu, 18 Jul 2019 07:22:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E261820880 for ; Thu, 18 Jul 2019 07:22:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726572AbfGRHWC (ORCPT ); Thu, 18 Jul 2019 03:22:02 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:36384 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726386AbfGRHWC (ORCPT ); Thu, 18 Jul 2019 03:22:02 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1ho0jm-00009d-Nz; Thu, 18 Jul 2019 15:21:58 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1ho0jj-0005oQ-0g; Thu, 18 Jul 2019 15:21:55 +0800 Date: Thu, 18 Jul 2019 15:21:55 +0800 From: Herbert Xu To: Ard Biesheuvel Cc: Horia Geanta , "linux-crypto@vger.kernel.org" , "dm-devel@redhat.com" Subject: Re: xts fuzz testing and lack of ciphertext stealing support Message-ID: <20190718072154.m2umem24x4grbf6w@gondor.apana.org.au> References: <20190716221639.GA44406@gmail.com> <20190717172823.GA205944@gmail.com> <20190718065223.4xaefcwjoxvujntw@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Jul 18, 2019 at 09:15:39AM +0200, Ard Biesheuvel wrote: > > Not just the generic implementation: there are numerous synchronous > and asynchronous implementations of xts(aes) in the kernel that would > have to be fixed, while there are no in-kernel users that actually > rely on CTS. Also, in the cbc case, we support CTS by wrapping it into > another template, i.e., cts(cbc(aes)). > > So retroactively redefining what xts(...) means seems like a bad idea > to me. If we want to support XTS ciphertext stealing for the benefit > of userland, let's do so via the existing cts template, and add > support for wrapping XTS to it. XTS without stealing should be renamed as XEX. Sure you can then wrap it inside cts to form xts but the end result needs to be called xts. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt