Open container arch hangs

[qinohe]

Since the tc-play package was updated on ArchLinux it's not possible to open a container, the process hangs forever after: tcplay -m container -d /dev/loop0 -k key The password should be asked for but it never comes this far.

Using the former package, from before the updates works fine.

Bug-report on Arch: https://bugs.archlinux.org/task/65678?project=5&order=dateopened&sort=desc

If you need more info let me know Thanks for looking into it;)

[anthraxx]

A side note: it depends on device-mapper package (version 2.02.186), that provides dmsetup stuff and upstream udev/rules.d/ rules

[bwalex]

I'll try and reproduce, but interestingly enough I've tested all of it quite specifically on Arch, since that's what I use nowadays.

Depending on how my attempts go, I might need to ask you to build from source with additional debug enabled to see if that provides some more insight - or, alternatively, running it under strace to give some hint or where it's hanging.

[bwalex]

Maybe a sillly question, but for how long did you wait after running the command for the prompt to appear?

If you pass in -k <keyfile> to -m or -i, tcplay will first attempt to unlock the volume using just the keyfile, and only if it fails, reprompt for a passphrase, too (and then proceed to combining the keyfile with the passphrase). A side effect of adding VeraCrypt support means that failed unlocking attempts (such as tcplay transparently does when it tries with just a keyfile when it needs both keyfile and passphrase) take a fair bit longer than before, as it works through all of the potential PRFs for the key derivation function, and some of those PRFs have a large number of iterations.

For example, here's the timing of one such attempt, which I ctrl-c'ed just after getting the password prompt:

❯ time sudo tcplay -m container -d /dev/nvme0n1p7 -k empty 
Passphrase: 
^C
23.41s=21.36s+0.01s

And here's an attempt with just a passphrase, but using the wrong passphrase (and then ctrl-c'ing immediately after the second passphrase attempt):

❯ time sudo tcplay -m container -d /dev/nvme0n1p7         
Passphrase: 
Incorrect password or not a TrueCrypt volume
Passphrase: 23.26s=21.15s+0.01s

And this is on a reasonably beefy mobile CPU, an i7-1065G7, so I can only imagine that on an older machine it could take up to a minute.

[bwalex]

To improve a bit on the situation, I'll see if I can add a behaviour so you can specify some new -p option that tells tcplay that a passphrase is needed even if a keyfile was supplied, so you can avoid the initial attempt.

[qinohe]

Yes, your right but one could say it's more than a fair amount of time longer.

A mount of the container, with one faulty and one correct password, I can eat a sandwich in between ;)

tcplay -m container -d /dev/loop0 -k key Passphrase: Incorrect password or not a TrueCrypt volume Passphrase: All ok! 210.60s user 0.22s system 87% cpu 3:59.71 total

My CPU is z8350 (UP Board)

[qinohe]

To improve a bit on the situation, I'll see if I can add a behaviour so you can specify some new -p option that tells tcplay that a passphrase is needed even if a keyfile was supplied, so you can avoid the initial attempt.

I would be very happy with that approach would safe a lot of time. Even with a CPU like I have running a script to mount a container normally takes 15 seconds...

[qinohe]

Here is a timing with the former package on Arch downgrading package tcplay (3.1-1 => 2.0-2)

tcplay -m container -d /dev/loop0 -k key Passphrase: All ok! 0.48s user 0.18s system 3% cpu 17.804 total

CPU usage also seems a lot lower...

[bwalex]

I've added the new option -p/--prompt-passphrase to help with this. It's now tagged as version 3.3. Hopefully that'll get you back to your original unlock time (unless it is a hidden volume, in which case it might still take longer than before, because it'll first attempt to unlock it as a normal volume).

[qinohe]

Thank you so much. It's not a hidden volume so that'll work out;) Already flagged the package on Arch so it may be there quickly, again thanks.

[qinohe]

Yes, after installing 3.3 everything is back to normal, just as fast as it was before ;)