3

I have a partition encrypted with LUKS. I used it without problems every day until suddenly the password stopped working. Is there anything I can do?

I have tried with a different keyboard and from a different computer. I am 100% certain that I typed in the correct password. So (correct me if I am wrong) it seems to me that my hard disk must be corrupted. If this is the case, is it reasonable to assume that only one byte is corrupted, and if yes, can I try all possible one byte changes of the partition header?

EDIT: I should have mentioned that the encrypted partition contains /, so it was always in use. I don't know if LUKS does any write protection though.

JackSTE
  • 39
  • 1
  • 3

1 Answers1

3

You should restore from your backup. If you have no backup then you are screwed. That is the entire point of full-disk-encryption. There are methods to restore a corrupt luks header, but you would have had to make a backup of the header first.

See: cryptsetup FAQ - Backup and Data Recovery

The idea that you could somehow try all the possible changes if one byte was off is extremely silly, unless you know exactly which byte was broken.

Lets pretend for a second that your the header was only 1megabyte (it is bigger, I believe it is ~2MB). Then the number of possible changes is 2**(8,388,608) (or 4.2644×10^2,525,222) even if you could try a billion different possible changes per second you would still be attempting changes well past the time when our sun destroys our planet.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • Sorry if I am being stupid, but isn't your calculation about the number of arbitrary 1MB headers? If only one byte is wrong, there are 1M choices of the wrong byte and 256 possible values for that byte, which gives 2.5x10^8 headers to try. – JackSTE Dec 22 '11 at 23:43
  • But my computer takes half a second per check, so a 2MB header is too big. I was expecting something comparable to the key size... Does any change in the header result in a rejected password, or can one restrict attention to some small part of it? – JackSTE Dec 22 '11 at 23:51
  • 1
    How could you possibly identify which byte or bit is bad if you have no backup? How big is the master key? `cryptsetup luksDump /dev/luksvol | grep 'MK bits'. I bet it is the master key is either [128](http://www.wolframalpha.com/input/?i=2**128) or 256 bits. If you could try a billion possibilities a second, then you would be looking at **10,790,283,070,806,014,188,970 years**. Much smaller, but still effectively impossible. – Zoredache Dec 23 '11 at 01:39
  • What's wrong with going through my corrupted header byte by byte, and for each byte trying out all 256 values one by one, then restoring that byte's original (according to the corrupted header) value and moving to the next byte? Under our assumption that only one byte is corrupted, this should work. And it will take 256M checks, because we only care about one byte changes from the original. Exponentials only come into play when you want to change more than one thing at a time. The important questions are 1) is it likely that only one byte is corrupted, and 2) can we restrict this to 256 bits? – JackSTE Dec 23 '11 at 11:44
  • If you know how to do that, then go do that. The chance of that doing anything useful seems infinitesimally small to me. The chance that only a single byte would be broken seem extremely low. This is a system administration site. The correct answer to 'I lost/forgot my FDE password' or my FDE is corrupt, is use your back else you are screwed'. – Zoredache Dec 23 '11 at 20:48