Backslash escaping in passwords and ideas on how to overcome similar problems

[jabbba]

Hi all,

I made the bad mistake of putting a backslash in my password. I debugged a bit the problem and found two separate unexpected behaviors (at least, I wasn't expecting them ;-) ). Please let me know if my interpretations are incorrect. Basically, backslashes are not escaped. This leads to two different consequences.

1. A backslash inside the password, not being escaped, is used to form ascii control (non-printable) characters; so for example \t enters in the password as tab (0x9), \f as form feed (0xC), and so on.

2. A backslash at end of the password has a more catastrophic effect (as far as I understood), neutralizing the '\n' in gpgpass="${tombpass}\n$TOMBSECRET", so causing gpgpass to be a concatenation of the password with the generated key, which if I understood well means that the gpg passphrase for the key is key itself, and i don't come up with any way to decrypt it (didn't make calculations but I think that brute-forcing it would imply the usual life-time of the universe). I didn't understand however which key has been encrypted since it wasn't passed in line 2 of $gpgpass.

Point (2) is what happened to me, and sadly, since this tomb was already in use with another password, I lost some important stuff. So, let me know if there are any mistakes in my reasoning (I really am a lamer in this context), or if there is a way to recover my key (and Yes, I obviously should have dug a backup tomb and yes I should have thought in advance not to use a backslash in the password).

The issue should be easily reproducible, but let me know if you need some details of my system.

That said, tomb is an utterly astonishing tool, and thank you very much for your good work.

[jaromil]

Dear @jabbba I sincerely hope your data can be recovered. This is indeed a difficult situation and I'd like to do some tests to address the shortcoming of password sanitisation in Tomb. Meanwhile please allow some time others may also chime in, my week is looking very busy so I'll likely come back later to this. Your case also motivates me more to use at least one of the extra password slots of the Tomb with a "backup" key, a sort of PUK that Tomb should strongly recommend to have printed on a QRcode and hidden somewhere.

[jabbba]

Hi jaromil,

and thank you for answering so soon. I'd be happy to recover it, they were bunch of day of work, that i wil have to re-do in part, but no more than that. I wrote here mainly to inform the developers.

thank you.

[Narrat]

Your case also motivates me more to use at least one of the extra password slots of the Tomb with a "backup" key, a sort of PUK that Tomb should strongly recommend to have printed on a QRcode and hidden somewhere.

One that gets automatically generated and protected with a $RANDOM pw?
Because if the user is asked for one the same could happen again.

But indeed an interesting issue.
And interesting to see, as I needed to read on this topic, how different shells work on this topic. Or programs like echo, print and printf.

[jaromil]

Interesting suggestion indeed to have a fully $RANDOM extra key that can be saved and/or printed for backup, IMHO this should also include the LUKS header (see #311).
I'm holding back and meditating a bit more on this for now, also in perspective of a major version 3.0 which can adopt https://zenroom.dyne.org for cryptographic operations, leaving us out of trouble for GPG, ASSUAN and a number of parsing related bugs.