[dm-crypt] Can't access a LUKS encrypted partition

jeff.esquivel at gmail.com jeff.esquivel at gmail.com
Tue Aug 12 06:15:39 CEST 2014

Hi Arno,

On Mon, Aug 11, 2014 at 3:21 PM, Arno Wagner <arno at wagner.name> wrote:

> On Mon, Aug 11, 2014 at 21:07:37 CEST, jeff.esquivel at gmail.com wrote:
> > Hi Arno,
> >
> > Ok, I get it now, sorry, I thought only extended charsets used the ISO
> > abbreviation (such as ISO-8859-1, etc.), didn't know ASCII in itself was
> an
> > ISO standard.
> The idea is that ISO-7bit is plain 7-bit ASCII.

Ok, good to know it, he he.

 > My passphrase uses only ISO-7bit characters (all of the
> > characters in my passphrase appear on the Wikipedia table I linked
> before).
> > I can also send you the password if it helps (I'm not using it for
> anything
> > important other than this).
> No need. If it is plain ASCII, then character encoding is not
> the issue at least not on the input side. Basically all encodings,
> including UTF-8 encode plain ASCII the same.


>  [...]
> > I did the formatting using cryptsetup directly on the command line, but
> all
> > of the successful unlocks where done using Ubuntu's window, something
> like
> > the one shown in this screenshot: http://www.imagebot.net/wally/1914 ,
> > after I couldn't unlock the partition with this method, I switched to
> > trying it on the command line directly (in case there was some Ubuntu/GTK
> > stuff that was getting in the way).
> Ok, so the initial setting was from commandline and you
> tried it at the end with the commandline. Good.
> > I have tried a lot of possible typos combinations (1536 to be exact, I
> > generated them with a tool that would generate all of the strings that
> > match a given regular expression and then thought about all the possible
> > typos I could make on this keyboard with this layout) using the
> crypt_dict
> > tool that came with the cryptsetup tarball.
> >
> > Other information which may be important: I'm using cryptsetup 1.6.1 (and
> That one is a bit older. Though I am using it too on some
> machines.
> > compiled both crypt_dict and chk_luks_keyslots using that version's
> > tarball), also I'm using kernel 3.16.0-031600rc6-generic (because this
> new
> > machine has some quirks that are resolved only in the latest kernel
> > version).
> That combination of ultra-new rc kernel (which also still may have
> bugs) and older cryptsetup is my next suspicion.
> Can you try with 1.6.5? Sources are linked here
>    http://code.google.com/p/cryptsetup/wiki/Cryptsetup165
> Also, can you try with something 3.10.x-ish? Even if you
> experience other issues you could try to unlock, geting
> a root-shell would be enough for that.

Sure, I can try the newest version. Would you recommend me that I do that
on the same machine (it may be a problem because it could conflict with the
already installed version of cryptsetup) or is it better if I do a clean
setup on a VM (I can attach the disk with USB passthrough)? If a clean
setup is recommended, is there any distro that would be better suited for
the job?

Same thing about trying an older kernel version (the older I can get
directly from Ubuntu in 14.04 is 3.13.x so I would need to recompile the
kernel to try on 3.10), so if a clean setup is recommended, I could do the
kernel compiling in there too.

>  > Another could-be important fact: I tried stracing cryptsetup and I don't
> > see my passphrase anywhere (on the FAQ said that it may be possible that
> > the passphrase could be seen on an strace, but I don't know if that would
> > be in ASCII or as the hex value of each character).
> That part I wrote last week ;-)

He he, I had good timing, then.

> Strace output can change a lot with cryptsetup versions.
> The example in the FAQ looks the same in 1.6.1 and 1.6.5 though.
> Here is a bit more context (passphrase "test"):
> write(6, "Enter passphrase for /root/f/luk"..., 39) = 39
> ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
> ...}) = 0
> ioctl(6, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo
> ...}) = 0
> ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo
> ...}) = 0
> read(6, "test\n", 512)                  = 5
> ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo
> ...}) = 0
> ioctl(6, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo
> ...}) = 0
> ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
> ...}) = 0
> write(6, "\n", 1)                       = 1
> If you do not find your passphrase in there, then it does
> not get to cryptsetup. The lines above are the very act of
> cryptsetup reading the passphrase chars from the terminal.
> If there is some hex in there insead, then you may have an
> encoding problem afetr all. The "Enter passphrase for..." should
> make it easy to find the place in any case. You can input any
> other passphrase for an strace recording BTW, the only thing
> different is that the unlock fails in that case.

Ok, now with more context I did find the passphrase in strace's output, the
only strange things I noticed are:

1) That my passphrase contains a backslash (\) so it is shown duplicated (I
guess it's because the backslash needs escaping so that it won't be
confused with a control character, this is confirmed by the number after
the '=' that seems to be the character count, which is correctly shown when
the newline is taken into account).

2) That the actual text before and after the passphrase is a little bit
different from your example:

{B38400 opost isig icanon -echo ...}) = 0

Also, the hex characters I saw before seem to be related to reading
/dev/urandom and then to reading something (I'm guessing it's the heading)
from the temporary crypsetup partition (it changes names, but on the last
try it was called /dev/mapper/temporary-cryptsetup-4805). One weird thing I
noticed here is that the hex characters returned from that temporary
partition are different between each passphrase try (but it could be that
the reading is being done from different places or something like that).

> > Thank you very much for all the help, I really appreciate it,
> You are welcome. This also helps improving the FAQ, as sometimes
> issues crop up that may hot others as well, but are not in
> there yet.

Ok, great, I promise that if we find the solution for this issue I'll write
a FAQ entry about it! :)


Jeffrey Esquivel S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20140811/766f2533/attachment.html>

More information about the dm-crypt mailing list