Description of problem: It would be nice to have an option, during the creation/access of a LUKS device, to store/read the LUKS header to/from a separate file (or device). In detail, it should be possible to specify something like "--header file" so that this "file" will contain the LUKS header. The encrypted device will have, of course, no offset, i.e. it will start from address 0 of the underlining device. It will be user responsibility to associate the proper header file to the proper encrypted device during un-lock operations. There are several reasons for this request. One is for portable devices, which will show only random data (like "truecrypt" does) without any hint on what exactly is on the disk. The second is the possibility, still like "truecrypt", to encrypt the header as well, for example using "ecryptfs" or similar. Third is this approach might help in the creation of an hidden volume. Thanks, bye, pg
Yes, I planned similar functionality - store Luks header to external file. But there is a problem, that keyslots in header have to be mapped through kernel dm-crypt to process them (they are encrypted by the same algorithm like real data). So it need map that file into block device first. I do not want to use standard loop (cryptsetup is pure device-mapper user and mixing dm and loop ioctl is real mess) but loop implemented in device-mapper (this module already exists, unfortunately is not yet in upstream kernel). When dm-loop is in upstream kernel, it can be implemented relatively easily. (plausible deniability is another problem, but you are right that using separate LUKS header user can achieve similar effect.)
Hi, what I was thinking, about hidden volume, is the following. There is a "normal" LUKS container, and a second, separate LUKS header, which has a "large" offset, let's say more or less 50% of the first LUKS container. Using the first LUKS will give access to the whole volume (with the risk, as in truecrypt, to damage the inner one). Using the first and then the second, will reveal the inner one, starting more or less at the half of the external one (position should be, of course, configurable). Of course, the difference with truecrypt is that the second LUKS header must be stored in a "safe" place, which is a weaker concept than the one used by the truecrypt folks. Maybe a further improvement for LUKS would be to have the LUKS header encrypted, so this could be stored in the external container (maybe). One more thing, you mentioned the dm-loop. Is there any foreseeable deadline for this module? I mean, is something going to happen in the next weeks, months, years? I understand perfectly your point about using dm infrastructure only, but if dm-loop will come in "years", maybe a temporary solution would be good. Thanks, bye, pg
Hi, how is it going with dm-loop? I could not find any progress. Is it still planned? Is it available? What's the backup plan, in case it will not happen? Thanks, bye, pg
Both loop support (not dm-loop, I decided to not wait for it and used in kernel loop) and LUKS header on separate device/in file is in cryptsetup devel version already implemented. So once I release 1.4 version (later this year), it will support it.
With version 1.4.x (RC1 in rawhide) you can use detached LUKS header. Also read http://code.google.com/p/cryptsetup/wiki/Cryptsetup140 Please test and let me know if there are any problems, thanks.