From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Fri, 21 Nov 2014 08:32:14 +0100 (CET) Received: by mail-wi0-f172.google.com with SMTP id n3so11058855wiv.17 for ; Thu, 20 Nov 2014 23:32:14 -0800 (PST) Message-ID: <546EEA7B.5010109@gmail.com> Date: Fri, 21 Nov 2014 08:32:11 +0100 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Documentation inconsistency -- On-Disk Format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Nichols , dm-crypt@saout.de On 11/21/2014 03:51 AM, Robert Nichols wrote: > I just noticed that in the LUKS On-Disk Format Specification document 1.2.1 > http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf > the LUKS key slots are numbered 1-8, whereas all the tools number them 0-7. It is just for "historic" reasons. I can fix it in documentation but old documentation is still in place (it is installed e.g. as docs in various distros). It could make the problem even worse. (And changing tools means breaking user scripts which is even worse.) It is not the first standard which uses pseudo-code description while real implementation differs in details. > That makes communication difficult. I do not think so. When dealing with users problem always the tool output is important. The slot offsets depends on key size so you must have always proper luksDump output for the device. Milan