From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7MX7R2NMklkV for <dm-crypt@saout.de>;
 Sun,  9 Sep 2012 10:45:22 +0200 (CEST)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com
 [74.125.82.178])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Sun,  9 Sep 2012 10:45:22 +0200 (CEST)
Received: by weyu7 with SMTP id u7so741113wey.37
 for <dm-crypt@saout.de>; Sun, 09 Sep 2012 01:45:21 -0700 (PDT)
Message-ID: <504C571E.3080805@gmail.com>
Date: Sun, 09 Sep 2012 10:45:18 +0200
From: Milan Broz <gmazyland@gmail.com>
MIME-Version: 1.0
References: <0970e8b6f714123c66b14c5bb1b79810@tenak.net>
 <20120908133525.GC23589@tansi.org>
 <b44e2b523db780283dcff4ffb579a464@tenak.net>
 <20120908200221.GB31299@tansi.org> <20120908224519.GA9926@citd.de>
In-Reply-To: <20120908224519.GA9926@citd.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] No key available for this passphrase
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 09/09/2012 12:45 AM, Matthias Schniedermeyer wrote:
> On 08.09.2012 22:02, Arno Wagner wrote:
>>
>> You can have up to 8 with LUKS. Each gets it own key-slot.
>> Unfortunately, the key-slot with the highest risk to get
>> damaged is the first one and that is where a single passphrase
>> ends up in if you do not override the placement default.

If most of installation it uses only the first slot, you can hardly
notice that other (unused) were corrupted as well :)

Most of programs formatting data today (mkfs, mkswap, lvm, mdadm...)
wipes more data, usually at least the first 4KB.

(mkswap should warn if it detects other signature, it is already
using libblkid. In fact I thought it was fixed years ago...)

> If that happens so often, why not change the default and place the first 
> key in slot 8?
> (Assuming that can be done without significant compatibility issues)

No, this is just hiding problem.
So it will be corrupted after first swap use (in this case)...

Milan