Problem with password handling refactor

[edlmo]

Using Tomb for about 4-5 months here. After pull the repository today, Tomb is no longer able to use the secret key to mount the encrypted file I have always used. I've followed the problem to the commit 5158c38, but didn't look further.

Here is the output from my command line (real paths has been changed):

$ sudo ./tomb exhume /path/image.jpg -k - | sudo ./tomb open -f -k - /path/file.tomb
tomb  .  Commanded to open tomb /path/file.tomb
tomb  .  Trying to exhume a key out of image /path/image.jpg
tomb  >  Waiting for the key to be piped from stdin... tomb (*) - succesfully decoded.
ok
tomb [W] Key data found with missing headers, attempting recovery.
tomb  .  Mountpoint not specified, using default: /media/file.tomb
tomb (*) Opening file.tomb on /media/file.tomb
tomb  .  This tomb is a valid LUKS encrypted device.
tomb  .  Cipher is "aes" mode "xts-plain64:sha256" hash "sha1"
tomb  .  A password is required to use key stdin.tmp.key
tomb  .  Valid key file found: /dev/shm/tomb.load_key_stdin.4093.cYHVH9f/stdin.tmp.key
tomb  .  Password OK.
No key available with this passphrase.
tomb  .  Removing key temporarily stored from stdin
tomb [E] Failure mounting the encrypted file.

[melon3r]

It works for me. Also, you don't need to pipe two tombs, you can just tomb open -k /path/image.jpg /path/file.tomb

[edlmo]

Just checked the problem on debian (jessie) with a brand new tomb following this steps:

1. git clone https://github.com/dyne/Tomb.git
2. git checkout 534476a84988dc08ac1c7678d74651b880306aba . (previous working commit)
3. tomb dig -s 10 secret.tomb
4. tomb forge -k secret.tomb.key (simple password: abc123)
5. tomb lock -k secret.tomb.key secret.tomb
6. git checkout 5158c380fefa46396ce3f2ec6ca6b994384de7d2 . (problematic commit)
7. tomb open -k secret.tomb.key secret.tomb ----------> Error, output:

tomb  .  Commanded to open tomb secret.tomb
tomb  .  Valid key file found: ./secret.tomb.key
tomb  .  Mountpoint not specified, using default: /media/secret.tomb
tomb (*) Opening secret.tomb on /media/secret.tomb
tomb  .  This tomb is a valid LUKS encrypted device.
tomb  .  Cipher is "aes" mode "xts-plain64:sha256" hash "sha1"
tomb  .  A password is required to use key secret.tomb.key
tomb  .  Valid key file found: ./secret.tomb.key
tomb  .  Password OK.
No key available with this passphrase.
tomb [E] Failure mounting the encrypted file.

[melon3r]

Okay, now I can reproduce it. My tombs don't live too long, and I didn't realize that my tomb was post-bug. I'm looking into it.

[jaromil]

Hi, thanks for this report, very sensible bug introduced by the refactoring (still workin on it)

The bug may be in the new gpg decoder, the runtest script might have some interesting output already, yet this shows also the need for a regression test on old keys.

[edlmo]

Hi @jaromil , thanks to you! This is an awesome application, keep it going.

[jaromil]

Cheers. I could reproduce the bug (occurring on my years old tombs) but still cant find the cause.

Apparently the secret is integral, wondering about newline termination or so? maybe useful to hexdump the decoded key material in both versions of tomb and compare them byte by byte...

[edlmo]

Newline thing indeed, without going further on the other options, by adding "-n" to the print on this line the mount_tomb function is working again on a tomb created before the 5158c38 commit.

[jaromil]

Great, mine was just a guess, thanks for taking the time to verify that, indeed it opens well also my old tombs now, that was it.

[edlmo]

Perfect, gracias!

[genius-Loci]

hi, my problem is: tomb [W] Attempting key recovery. tomb . Password OK. tomb [E] Failure mounting the encrypted file.

[Narrat]

@genius-Loci: If using ZSH 5.3 see the README.md or #232

[genius-Loci]

Problem solved, Thank you.