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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 0BE20C433E0 for ; Fri, 29 May 2020 12:00:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D258120776 for ; Fri, 29 May 2020 12:00:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Yyllo15e"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="eJ+NZH20" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D258120776 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=n9kIHXReWpmHs0C93rO2B1x5b4TmMEtZ0rIStri8Hu8=; b=Yyllo15em2sutw jyhMfuCoD3pvnLr+wvlqy45mlo37aH+Jp0A1WSH2SCGzLlPvajIm+vnjuQzZgKhF5sl3ZMd1DePoe bhHD1/RhPJeAnybRn+hSd9Phc/IyXo61BZQZasFuud+FdIQINqeyDZcyry5Ratq7DuJjvsskqSrCh rdW12TOXn18O2KPQTFiVgetx8VfXPo13GLnrAL9oQC8MAMyjeR2RT30YMd09obWwVLYwtDBzo1ibD X7HXr/j63Z60/ccJ+cqb6IVzQ18x8nCLJDP9R7RoZ2GUobcnjDHNJD+1G+jpy6DLvk8Tk53KLG7yY mVsDE4mmj9eYJxzSrRdQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jedgc-00027d-TE; Fri, 29 May 2020 12:00:30 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jedgZ-00026F-DI for linux-arm-kernel@lists.infradead.org; Fri, 29 May 2020 12:00:28 +0000 Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A5EDA20DD4 for ; Fri, 29 May 2020 12:00:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590753626; bh=bx/0rENky0xYxtckxv/+DIl6VrrnMCAkBaTV2a5azo4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eJ+NZH20I3Rkp0wHzZL22t35STNLvsmOaQFINjFbXP3gaxH3whA6+G4R/W2jbjdBz f68apPn6ou5GxsVPDYoBKE88jIZO3/GBQ78Rh0F09wUYO4T6MUKkkdc4siPnskM5/2 XIQkwgneXPkDV5/3b63NrKvWWAbzhD29u6nuIJQ4= Received: by mail-io1-f52.google.com with SMTP id d7so2010410ioq.5 for ; Fri, 29 May 2020 05:00:26 -0700 (PDT) X-Gm-Message-State: AOAM533p05v2bnEMnsvUOHJe+Gl0kxukDEMv7+bAOYZbj+Hh/+SADsYD osAVheBJVhgzu4XtB0TGFZzw2sskWPO5pDo/IRg= X-Google-Smtp-Source: ABdhPJzpX4auNPdZ+cI8NDL1W30V/wsHV1VShKXDqxvwqwVlVUjFyyiZ5t7YFglBVNDADKmcy1z3+W+eAuV2iewsTfQ= X-Received: by 2002:a05:6602:2dcd:: with SMTP id l13mr6215873iow.203.1590753625984; Fri, 29 May 2020 05:00:25 -0700 (PDT) MIME-Version: 1.0 References: <20200519190211.76855-1-ardb@kernel.org> <20200528073349.GA32566@gondor.apana.org.au> <20200529080508.GA2880@gondor.apana.org.au> <20200529115126.GA3573@gondor.apana.org.au> In-Reply-To: <20200529115126.GA3573@gondor.apana.org.au> From: Ard Biesheuvel Date: Fri, 29 May 2020 14:00:14 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr To: Herbert Xu X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200529_050027_472695_D0BC306A X-CRM114-Status: GOOD ( 17.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eric Biggers , Stephan Mueller , Linux Crypto Mailing List , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 29 May 2020 at 13:51, Herbert Xu 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