Dear all, I have succeed in encrypting hard disk with cryptsetup. Now, I want to modify mkinitrd with automatically passphrase. I found this line in /sbin/mkinitrd: echo Setting up disk encryption: /dev/sda4 plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda4 luks-sda4" the second line ask me to type the passphrase, is there anybody know how to make it automatically ? like: echo "passphrase" | cryptsetup luksOpen /dev/sda4 root ? I have tried this command and make new initrd but it did not work. It sound weird but, that is what I am asked to do. Thank you for your help. Regards, Hans -----Original Message----- From: dm-crypt-bounces@xxxxxxxx [mailto:dm-crypt-bounces@xxxxxxxx] On Behalf Of dm-crypt-request@xxxxxxxx Sent: Thursday, November 05, 2009 6:00 PM To: dm-crypt@xxxxxxxx Subject: dm-crypt Digest, Vol 5, Issue 5 Send dm-crypt mailing list submissions to dm-crypt@xxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://www.saout.de/mailman/listinfo/dm-crypt or, via email, send a message with subject or body 'help' to dm-crypt-request@xxxxxxxx You can reach the person managing the list at dm-crypt-owner@xxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of dm-crypt digest..." Today's Topics: 1. Re: [PATCH] print warning when adding a key that contains non-ASCII characters (Heinz Diehl) 2. Crack a dm-LUKS partition or harddisk (Si St) 3. Re: Crack a dm-LUKS partition or harddisk (Sven Eschenberg) 4. Re: Crack a dm-LUKS partition or harddisk (Heinz Diehl) 5. Re: Crack a dm-LUKS partition or harddisk (Arno Wagner) ---------------------------------------------------------------------- Message: 1 Date: Wed, 4 Nov 2009 16:46:42 +0100 From: Heinz Diehl <htd@xxxxxxxxxxxxxxxxx> To: dm-crypt@xxxxxxxx Subject: Re: [PATCH] print warning when adding a key that contains non-ASCII characters Message-ID: <20091104154642.GB7788@xxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=us-ascii On 04.11.2009, Uwe Menges wrote: > Your patch uses the isascii() call, but the problem "different keymap at > different password entering times" is IMHO not really related to the > question "is the character ascii or not". It's all too easy to run into > exact the same situation you want to prevent, with just plain ascii > chars in the password. Yes, of course, it can be quite a little bit of a problem if the charset of a let's say Norwegian keyboard (in my case) is turned into an US mapped one at booting time. ------------------------------ Message: 2 Date: Wed, 4 Nov 2009 17:51:59 +0100 From: "Si St" <sigbj-st@xxxxxxxxxxxxx> To: dm-crypt@xxxxxxxx Subject: Crack a dm-LUKS partition or harddisk Message-ID: <20091104165200.66F5A7BD6E@xxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="iso-8859-1" Question: Say we have a dm/LUKS encrypted partition or harddisk. - Do we have a crack-password-delay-mechanism as a part of the encryption, or is this a feature of the software of the OS? I I have understood that with the very rapid crackingspeed (brute-force) we have nowadays, the new approach to this is to force in a delay for each password enter, as a tool of increased security. Is this feature a block independent software, or is it only a software program of the booted OS? If so, attacking the harddisk directly independent of the booted OS will pass this feature. (Have I made myself clear?) -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ------------------------------ Message: 3 Date: Wed, 04 Nov 2009 18:01:57 +0100 From: Sven Eschenberg <sven@xxxxxxxxxxxxxxxxxxxxx> To: dm-crypt@xxxxxxxx Subject: Re: Crack a dm-LUKS partition or harddisk Message-ID: <4AF1B385.9030908@xxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed The passphrase is iterated (with some sort of key derivation algorithm) as far as I understand it. Usually you can modify the amount of time in ms during keyslot creation which is spent in doing iterations. If you assume you can do n Iterations in 1 second, and some other machine can do 10 times n iterations, then machine two would spend (approx) 1/10 second per passphrase (password) test. But this is only of relevance, where the passphrase universe << key universe - Meaning, when the entropy of your passphrase is bigger than the keyspace, it doesn't matter, since you'd try cracking the actualy key within the keyspace. Regards -Sven Si St schrieb: > Question: > Say we have a dm/LUKS encrypted partition or harddisk. - Do we have a crack-password-delay-mechanism as a part of the encryption, or is this a feature of the software of the OS? > > I I have understood that with the very rapid crackingspeed (brute-force) we have nowadays, the new approach to this is to force in a delay for each password enter, as a tool of increased security. Is this feature a block independent software, or is it only a software program of the booted OS? > > If so, attacking the harddisk directly independent of the booted OS will pass this feature. > > (Have I made myself clear?) > ------------------------------ Message: 4 Date: Wed, 4 Nov 2009 18:30:51 +0100 From: Heinz Diehl <htd@xxxxxxxxxxxxxxxxx> To: dm-crypt@xxxxxxxx Subject: Re: Crack a dm-LUKS partition or harddisk Message-ID: <20091104173051.GA4660@xxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=us-ascii On 04.11.2009, Si St wrote: > Do we have a crack-password-delay-mechanism as a part of the encryption See the option "--iter-time" in the cryptsetup manual, and look for "iteration count" related to PBKDF2. ------------------------------ Message: 5 Date: Wed, 4 Nov 2009 23:29:53 +0100 From: Arno Wagner <arno@xxxxxxxxxxx> To: dm-crypt@xxxxxxxx Subject: Re: Crack a dm-LUKS partition or harddisk Message-ID: <20091104222953.GA3789@xxxxxxxxx> Content-Type: text/plain; charset=us-ascii On Wed, Nov 04, 2009 at 05:51:59PM +0100, Si St wrote: > Question: > > Say we have a dm/LUKS encrypted partition or harddisk. - Do we have a > crack-password-delay-mechanism as a part of the encryption, or is this a > feature of the software of the OS? > > I have understood that with the very rapid crackingspeed (brute-force) > we have nowadays, the new approach to this is to force in a delay for each > password enter, as a tool of increased security. Is this feature a block > independent software, or is it only a software program of the booted OS? > > If so, attacking the harddisk directly independent of the booted OS will > pass this feature. > I guess this is in response to a recent slashdot article pointing to some people that have cracked a PGP encrupted zip file using Amazon EC2. Forst, this is only relevant if you have low entropy in your passphrase. An exapmple would ba an [a-z] 8 char passphrase, which has (if it is random) about 37.6 bits of entropy. This is of course far less than a 128 bit or 256 bit key and in a brute force attack it may be beneficial to run though all possible passphrases instead of through all possible keys. LUKS uses PBKDF2, which is specifically designed to be resilient in case such low-entropy passwords are used. The hash is SHA-1 (the recent discoverd weaknesses do not matter for this application) and it determined by a benchmark system, which basically benchmarks PBKDF2 and then uses the number of iterations that give a specific checking time. As fas as I can tell, the LUKS spec does not give a default. cryptsetup 1.0.6 (the version in Debian Stable) seems to use a default value of 1 sec (line 28 in src/cryptsetup.c: static int opt_iteration_time = 1000;). Incidentially this gives a cost > 10 Billion USD for Amazon EC2 if the key setup was done on reasonably fast hardware. If you do it on a linux running in a bochs emulator, e.g., the security may be a bit worse ;-) The passphrase and the iterations are needed to derive the key that unlocks the master key. This means the delay feature is a cryptographic feature of the key-derivation mechanism and cannot be bypassed by anyone. It is not just a static delay, it is a computation that has to be done since its result is needed. What the OS can do, if it is corrupt, is to just store the key somewhere when you unlock your crypto-container. This requires an attacker to have access to your OS two times and yoy to open the container in between. It has recently gotten some limited fame as an "Evil Maid Attack". However an easier attack installs a keyboard sniffer or a physical bug into your computer. Arno ---- Reference for LUKS: http://cryptsetup.googlecode.com/svn-history/r42/wiki/LUKS-standard/on-disk- format.pdf -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier ------------------------------ _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt End of dm-crypt Digest, Vol 5, Issue 5 ************************************** _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
