gmane.linux.kernel.device-mapper.dm-crypt

Re: cryptosetup luks info resources

Arno Wagner — 2008-12-01T21:53:41

Ah, yes. I thought of the bytes actually on disk. Arno

Re: cryptosetup luks info resources

Jan Reusch — 2008-12-01T18:50:11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arno Wagner schrieb: ok here you are probably right. (too lazy to test now ;) ) if you thought of that from the beginning it was a little missunderstanding on my side. Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJNDHjBpRI6A8tC0MRAjVrAKC16QzcG/hQdBbsDoRyQUVEjVmFsQCfd8Y3 gSd58kMrHVlHCYdqIyEsRL8= =o0kO -----END PGP SIGNATURE-----

Re: cryptosetup luks info resources

Arno Wagner — 2008-12-01T18:33:49

The size is the same, but I think the space is not cleared bevore you actually create keys. Arno

Re: cryptosetup luks info resources

Jan Reusch — 2008-12-01T18:30:13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arno Wagner schrieb: hmmm i would say the size is always the same, it only depends on the bitsize of the encryption key and doesn't change over time. (would be bad if it does so ;) ) #root< at >wintermute:~# cryptsetup luksDump /dev/mapper/raid-jan LUKS header information for /dev/mapper/raid-jan Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 1032 MK bits: 128 MK digest: xx MK salt: xx MK iterations: 10 UUID: xx Key Slot 0: DISABLED Key Slot 1: ENABLED Iterations: 76720 Salt: xx Key material offset: 136 AF stripes: 4000 Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED #root< at >wintermute:/tmp# dd if=/dev/mapper/raid-jan count=1032 of=test #root< at >wintermute:/tmp# losetup -f test #root< at >wintermute:/tmp# cryptsetup luksDump /dev/

Re: cryptosetup luks info resources

Sitaram Chamarty — 2008-12-01T11:37:49

Thanks -- looking forward to it! Regards, Sitaram

Re: cryptosetup luks info resources

Jan Engelhardt — 2008-12-01T10:57:14

On Monday 2008-12-01 02:23, Jan Reusch wrote: Quite big. But well, unless you really need multiple passwords, you can also go with the normal dm-crypt encryption (without LUKS).

Re: cryptosetup luks info resources

Arno Wagner — 2008-12-01T10:21:56

[...] I am currently looking through it. So far I like the introduction ;-) Will send more feedback directly, not over this list. Arno

Re: cryptosetup luks info resources

Arno Wagner — 2008-12-01T10:10:39

The LUKS keys span those 8MB or so at maximum. But only if you actually have keys. Without them, there is only the ~600 Bytes header AFAIK. Arno

Re: cryptosetup luks info resources

Sitaram Chamarty — 2008-12-01T09:08:47

...although I must also say I don't know why I said "8 MB". There was a recent thread right here where all this was hashed out, when someone who lost the LUKS header was trying to recreate it. Can't find it now, but I seem to recall that thread said 8 MB. Sorry for being so vague... Regards, Sitaram On Mon, Dec 1, 2008 at 9:35 AM, Sitaram Chamarty public.gmane.org> wrote:

Re: cryptosetup luks info resources

Sitaram Chamarty — 2008-12-01T04:05:49

Hello, On Mon, Dec 1, 2008 at 6:53 AM, Jan Reusch public.gmane.org> wrote: Look further down in that dump output for the phrase "AF Stripes". see section 2.4 in http://luks.endorphin.org/LUKS-on-disk-format.pdf Regards, Sitaram

Re: cryptosetup luks info resources

Jan Reusch — 2008-12-01T01:23:56

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi there Sitaram Chamarty schrieb: with 'cryptsetup luksDump device' you can see how much space your luksheader needs. most the time it is 1032 sectors (512 bytes a sector makes half a megabyte) for me. you can read this all in the initial paper [1] clemens wrote. Jan [1] http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJMzyrBpRI6A8tC0MRAl2bAJ420HpE9Cbs9IQXtqy4cPi1Gdz3TQCgqMlT yrbFluk602iD67rFeusmpKA= =1wiN -----END PGP SIGNATURE-----

Re: cryptosetup luks info resources

Sitaram Chamarty — 2008-12-01T00:53:30

Thanks! most of the recent distros do now. They'll throw up a password prompt as soon as you insert a USB stick that's LUKS formatted, for instance...

Re: cryptosetup luks info resources

Sitaram Chamarty — 2008-12-01T00:52:17

I thought the luks header spans about 4000 blocks (8MB or so) due to the anti-forensic key splitting. Perhaps it doesn't touch the first few blocks or so, and Marek's files were well below that...

luks partition missing

David Keymel — 2008-11-30T19:30:55

Hello, I was using luks to encrypt a mdadm raid5 software raid array. I recently had some trouble with the array, and luks is now reporting that the partition is missing. the md0 device shows that there is a partition on the device. Is it possible to recover this partition or have i lost all my encrypted data? The array assembles ok, but i cannot process the luksOpen command in cryptsetup. Thnx.

Re: cryptosetup luks info resources

2008-11-30T19:56:01

Thanks for info. It came out that hal didn't work for me because of some bugs in KDE. Marek Aaron Sapota On Sunday 30 November 2008 19:53:11 Jan Engelhardt wrote:

Re: cryptosetup luks info resources

Jan Engelhardt — 2008-11-30T18:53:11

On Sunday 2008-11-30 19:22, projects.gg.aaron-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org wrote: There is no reason to explicitly zero the device - it would take much too long. It simply writes the LUKS header. Since ext3's header begins some 16-32KB from the start of the device, nothing is lost unless you start making a filesystem on the crypto device (/dev/mapper/...). It already does recognize them as I gather from developers.

Re: cryptosetup luks info resources

2008-11-30T18:22:36

Trying to reproduce it I found what happened - I've made ext3 filesystem on file before I did cryptsetup luksFormat, but shouldn't it overwrite ext3 filesystem? Your article was a quite a good read it indeed showed me some answers=) One more question - can hal be made to recognize luks and automount such devices? Thanks Marek Aaron Sapota On Sunday 30 November 2008 18:24:04 Sitaram Chamarty wrote:

Re: cryptosetup luks info resources

Sitaram Chamarty — 2008-11-30T17:24:04

This sounds weird; could you post the sequence of commands you used? About a couple of months ago I wrote an entry level article on encrypted file systems for a local magazine. A PDF copy is at http://sitaramc.googlepages.com/encrypted-file-systems.pdf -- I think it should answer a lot of questions. [If anyone else takes a look at it and has comments, please let me know. But remember the target audience for that article is people who're just getting into this without using a GUI and all that -- "slow and steady" is important :-)

cryptosetup luks info resources

2008-11-30T12:59:20

Hi, I'm new to cryptosetup and luks. I've decided I'll try it out on a loop filesystem so I won't break anything and to my amazement I can properly mount encrypted file without luks and it appears empty (there was default ext3' lost+found directory), I can add files there and they don't appear when I mount it with luks. Like having two drives depending on mount method. This leads to my question - where can I find some resources about how luks works, for example why I can do the thing described above and what can break when I do it? Also most tutorials don't tell how to use some more advanced options (how to choose encryption algorithm and what is the default?) Could someone point me to a full featured tutorial? Thanks in advance=) Marek Aaron Sapota

Re: encrypted home start-up problem with keyfile

Bernd Speiser — 2008-11-23T09:39:28

wouldn't this crypttab entry ask for a password (third entry: `none')? My problem is that I do want to have all partitions (/, /home, wap) encrypted and I do want to give the password only once during boot. So, at this point we would need the name of a key-file (containing the passphrase for /home and swap), which is accessible after the root partition is decrypted by the password given, without further asking me for passwords. My crypttab man page says that an entry `none' will ask for the password interactively. The solution suggested by Heinz works excellently in my environment. Is there any argument AGAINST this solution - I mean, does this conflict with some other action during boot? As a user (rather than an expert in encryption and boot process organization ...), I think that it would be nice to have a clear description how to proceed which is also mentioned in the openSUSE HOWTO pages. Regards Bernd

Re: encrypted home start-up problem with keyfile

Ludwig Nussel — 2008-11-21T10:34:41

And not reproducible either. # cat /etc/SuSE-release openSUSE 10.3 (X86-64) VERSION = 10.3 # grep sda12 /etc/fstab /etc/crypttab /etc/fstab:/dev/mapper/sda12 /crypt ext2 noauto 0 0 /etc/crypttab:sda12 /dev/sda12 none luks works just fine. cu Ludwig