From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 14 Aug 2009 09:36:28 +0200 (CEST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MbrKr-0003Ae-Qg for dm-crypt@saout.de; Fri, 14 Aug 2009 07:36:25 +0000 Received: from port-87-193-186-180.static.qsc.de ([87.193.186.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Aug 2009 07:36:25 +0000 Received: from thomas by port-87-193-186-180.static.qsc.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Aug 2009 07:36:25 +0000 From: =?ISO-8859-15?Q?Thomas_B=E4chler?= Date: Fri, 14 Aug 2009 09:36:09 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: news Subject: [dm-crypt] [Feature request] Support for "raw" key slots List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de The iterated hashing process used in LUKS' key slots is useful for (potentially weak) passphrases. However, it is useless if the key slot is locked with a cryptographically strong key file (like a file created from /dev/random). Therefore I propose the addition of a "raw key slot" feature to LUKS, where a key that has the exact length of the master key is simply XOR'ed to the master key and saved in the key slot (after the usual striping of course). I don't see any obvious security implications with this feature. If there are any, I'd be interested. Please consider this for a future LUKS specification.