Re: Can't access a LUKS encrypted partition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 11, 2014 at 21:07:37 CEST, jeff.esquivel@xxxxxxxxx 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. 

> 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.
 
> As to text-editor: That has the same issues, except for the
> > keyboard layout.
> >
> 
> Ok, got it.
> 
> 
> > (If you do not use any of the original ASCII/ISO-7bit chars,
> > I would be curious how you enter them with an US keyboard.
> > Windows-key remapped to compose?)
> >
> 
> > I still suspect you switched locales at some point or there
> > is a dropped line-ending or something like that. Did you
> > use cryptsetup directly before and after it stopped working?
> > Same shell? Tried to switch y and z? Some capitalization-error?
> >
> 
> 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.

> 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 ;-)

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.

> 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.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@xxxxxxxxxxx
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux