Hi Arno,
--
Jeffrey Esquivel S.
On Mon, Aug 11, 2014 at 3:21 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
> Ok, I get it now, sorry, I thought only extended charsets used the ISOThe idea is that ISO-7bit is plain 7-bit ASCII.
> abbreviation (such as ISO-8859-1, etc.), didn't know ASCII in itself was an
> ISO standard.
Ok, good to know it, he he.
> My passphrase uses only ISO-7bit characters (all of theNo need. If it is plain ASCII, then character encoding is not
> 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).
the issue at least not on the input side. Basically all encodings,
including UTF-8 encode plain ASCII the same.
Ok.
[...]Ok, so the initial setting was from commandline and you
> 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).
tried it at the end with the commandline. Good.
That one is a bit older. Though I am using it too on some
> 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
machines.
That combination of ultra-new rc kernel (which also still may have
> 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).
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'tThat part I wrote last week ;-)
> 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).
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).
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:
ioctl(6, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0
ioctl(6, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {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).
You are welcome. This also helps improving the FAQ, as sometimes
> Thank you very much for all the help, I really appreciate it,
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! :)
Thanks,
--
Jeffrey Esquivel S.
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
