Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FEE4C433F5 for ; Thu, 6 Jan 2022 05:07:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229628AbiAFFHr (ORCPT ); Thu, 6 Jan 2022 00:07:47 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:42490 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229585AbiAFFHr (ORCPT ); Thu, 6 Jan 2022 00:07:47 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 207EEB819BC; Thu, 6 Jan 2022 05:07:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E16EC36AE5; Thu, 6 Jan 2022 05:07:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641445664; bh=D7iMPaQNW7tDdQiXC0UqtchlPiGk1xwtrROv6L/y5+A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZVIVTkIogNCJmdRqyC16r7sV+7EmNPiy06RMjCkcTMetZohSe7UVGz5An/w/kXMOh YGqy9ZBx/wOYNC8dGgEJzBN9LnCD8yCx/IhjoTvCGFAsAVRZn10cy4/vOeiUNB7z2T /n7vcg2xiFFG3FYN4/kxk6gf3AJmZp3fmxoT8QJZW/XzQvLbNUrma8PUy+ViuT3uWF Env82KZExxiKU+TYSdeRQeKyu3vdAigu+aGkz425jyTCAy4Gepzf0SaoRWLy8jKwzW 9tEUA3RlxVx2wv/LP265jkNimJOtoKlItGxAGaz2El4kIqFwVobCqLDQrni4uQHzDl QY+5Pj19EEh2Q== Date: Wed, 5 Jan 2022 21:07:42 -0800 From: Eric Biggers To: "Bae, Chang Seok" Cc: "dm-devel@redhat.com" , Thomas Gleixner , Borislav Petkov , Dave Hansen , Ingo Molnar , "Lutomirski, Andy" , the arch/x86 maintainers , Herbert Xu , Linux Kernel Mailing List , Linux Crypto Mailing List , "Williams, Dan J" , "Gairuboyina, Charishma1" , "Dwarakanath, Kumar N" , "Krishnakumar, Lalithambika" , "Shankar, Ravi V" Subject: Re: [PATCH v4 00/13] x86: Support Key Locker Message-ID: References: <20211214005212.20588-1-chang.seok.bae@intel.com> <4101B942-6327-49A9-BE8B-9E51F0427F50@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4101B942-6327-49A9-BE8B-9E51F0427F50@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, Jan 05, 2022 at 09:55:17PM +0000, Bae, Chang Seok wrote: > >> +-----------+---------------+---------------+ > >> | Cipher | Encryption | Decryption | > >> | (AES-KL) | (MiB/s) | (MiB/s) | > >> +-----------+---------------+---------------+ > >> | AES-CBC | 505.3 | 2097.8 | > >> | AES-XTS | 1130 | 696.4 | > >> +-----------+-------------------------------+ > > > > Why is AES-XTS decryption so much slower than AES-XTS encryption? They should > > be about the same. > > Analyzing and understanding this with specific hardware implementation takes > time for us. Will come back and update you when we have anything to share here. Note that for disk encryption, decryption performance is usually more important than encryption performance. So your performance results are strange. > > Also, is the AES-CBC support really useful, given that for disk encryption, > > AES-XTS is recommended over AES-CBC these days? > > Yes, we understand that AES-XTS is the primary option for disk encryption. > > But it seems that AES-CBC had been used for disk encryption, [1]: > > Comparing XTS to CBC for hard disk encryption > If a storage device vendor is seeking FIPS 140-2 certification today, > they will typically use CBC encryption, or even ECB. CBC is a good > mode, ... That document is very old. XTS has been NIST-approved for over a decade now. > > As long as it is factual that the mode was once popular, it can help somebody > who wants to use Key Locker for an old disk image I think. AES-CBC is/was usually used with ESSIV, in which case the key cannot be fully protected by Key Locker. I'm not sure you should bother to support legacy use cases, especially since it might mislead users into choosing a worse algorithm. - Eric