From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1kkoI6-00015v-K2 for mharc-grub-devel@gnu.org; Thu, 03 Dec 2020 08:04:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkoI4-00014q-CB for grub-devel@gnu.org; Thu, 03 Dec 2020 08:04:56 -0500 Received: from dibed.net-space.pl ([84.10.22.86]:37290) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_3DES_EDE_CBC_SHA1:192) (Exim 4.90_1) (envelope-from ) id 1kkoHx-0003rj-Hq for grub-devel@gnu.org; Thu, 03 Dec 2020 08:04:54 -0500 Received: from router-fw.i.net-space.pl ([192.168.52.1]:42246 "EHLO tomti.i.net-space.pl") by router-fw-old.i.net-space.pl with ESMTP id S2085984AbgLCNEp (ORCPT ); Thu, 3 Dec 2020 14:04:45 +0100 X-Comment: RFC 2476 MSA function at dibed.net-space.pl logged sender identity as: dkiper Date: Thu, 3 Dec 2020 14:04:43 +0100 From: Daniel Kiper To: Glenn Washburn Cc: grub-devel@gnu.org, Patrick Steinhardt Subject: Re: [PATCH v6 06/12] cryptodisk: Properly handle non-512 byte sized sectors Message-ID: <20201203130443.eiduu6w2zkirvi7q@tomti.i.net-space.pl> References: <6e01cafb1eb4847d10855b799f42141164614958.1606467382.git.development@efficientek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e01cafb1eb4847d10855b799f42141164614958.1606467382.git.development@efficientek.com> User-Agent: NeoMutt/20170113 (1.7.2) Received-SPF: pass client-ip=84.10.22.86; envelope-from=dkiper@net-space.pl; helo=dibed.net-space.pl X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 13:04:56 -0000 On Fri, Nov 27, 2020 at 03:03:38AM -0600, Glenn Washburn wrote: > By default, dm-crypt internally uses an IV that corresponds to 512-byte > sectors, even when a larger sector size is specified. What this means is > that when using a larger sector size, the IV is incremented every sector. > However, the amount the IV is incremented is the number of 512 byte blocks > in a sector (ie 8 for 4K sectors). Confusingly the IV does not corespond to > the number of, for example, 4K sectors. So each 512 byte cipher block in a > sector will be encrypted with the same IV and the IV will be incremented > afterwards by the number of 512 byte cipher blocks in the sector. > > There are some encryption utilities which do it the intuitive way and have > the IV equal to the sector number regardless of sector size (ie. the fifth > sector would have an IV of 4 for each cipher block). And this is supported > by dm-crypt with the iv_large_sectors option and also cryptsetup as of 2.3.3 > with the --iv-large-sectors, though not with LUKS headers (only with --type > plain). However, support for this has not been included as grub does not > support plain devices right now. > > One gotcha here is that the encrypted split keys are encrypted with a hard- > coded 512-byte sector size. So even if your data is encrypted with 4K sector > sizes, the split key encrypted area must be decrypted with a block size of > 512 (ie the IV increments every 512 bytes). This made these changes less > aestetically pleasing than desired. > > Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper Daniel