From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sat, 28 Oct 2017 03:48:16 +0200 (CEST) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1e8Fzh-0007lj-Bs for dm-crypt@saout.de; Sat, 28 Oct 2017 03:33:01 +0200 From: Robert Nichols Date: Fri, 27 Oct 2017 20:32:50 -0500 Message-ID: References: <64b7fdd8-da25-745d-b01f-583ba3ea99b2@lrose.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <64b7fdd8-da25-745d-b01f-583ba3ea99b2@lrose.de> Content-Language: en-DK Subject: Re: [dm-crypt] Disadvantages of many temporary keys? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 10/27/2017 08:09 PM, L. Rose wrote: > Hi everyone, > > My setup runs off a dmcrypt/luks encrypted drive. I want to do daily > unattended reboots, so I don't want to have to enter the password upon > reboot. I thought of generating a random temporary key, inserting that > into a secondary slot on my container using luksAddKey and preparing a > custom initramfs containing that temporary key, so that the system can > unlock the container once after the reboot. When the system is up and > running again, I'll remove that random temporary key from both the > container and the initramfs. > > My question is: Do dmcrypt/luks containers suffer from frequent key > adding/removal? Will the container degrade because of this usage, or > maybe get errors? If so, is there a better way for unattended reboots? It won't suffer. All that happens when you add or remove a key is that the portion of the LUKS header for that keyslot gets rewritten. But, removal of that temporary key is not as secure as you might think. Anyone (or any bot) that had an opportunity to make a copy of the LUKS header while that key was installed can always use that header, together with that "temporary" key, to unlock the container. "LUKS with detached header" would be the most straightforward way, but the master key could also be constructed from that header + key and used directly with cryptsetup to access the container's contents. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.