Bug 554119
Summary: | RFE: have the LUKS header on separate file | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Piergiorgio Sartor <piergiorgio.sartor> |
Component: | cryptsetup-luks | Assignee: | Milan Broz <mbroz> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | agk, dwysocha, lvm-team, mbroz, opensource, pjones, prockai, pvrabec, whulbert |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-10-25 19:16:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Piergiorgio Sartor
2010-01-10 15:28:37 UTC
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. |