From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 OKbYWN0IGznh for ; Wed, 1 Feb 2012 10:23:49 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 1 Feb 2012 10:23:47 +0100 (CET) Message-ID: <4F29049C.3050205@redhat.com> Date: Wed, 01 Feb 2012 10:23:40 +0100 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] New Luks Format Specification (1.3) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philipp Deppenwiese Cc: Liste Cryptsetup On 02/01/2012 08:59 AM, Philipp Deppenwiese wrote: > Up to now we still use SHA-1 as default algorithm for PBKDF2 > in luks. Firstly, thank you for sending to the list where it can be properly discussed. For others, I guess this originates in http://code.google.com/p/cryptsetup/issues/detail?id=119 As you know, SHA1 is not hardcoded anymore, you can use whatever has algorithm you want and is supported in crypto library. Arno and others will surely comment here issue of PBKDF2 use. > The next problem is the excessive use of parallel > bruteforcing systems like ASIC, FPGA or GPUGPU technology. A new key > derivation function is needed in order to raise the complexity of > bruteforce attacks against the luks key derivation function. This is just your statement, please provide facts supporting it. > If someone sends me the *.tex file of the luks specification, i will > update and post it for review. tex file is in svn. But changing LUKS header definitely doesn't work this random way. Please discuss your ideas, provide theoretical background, send a patch and if there is real problem to solve, I am sure it will become part of code. Thanks, Milan