# well, I managed to forget my luks password

## Tonglebeak

After using it for 6 months, I guess I forgot it. Everything I entered did not work, and I am unable to find the physical copy of my password anywhere. To make this question simple:

Is there a way to extract the hash from the luks header? I used luksdump but I'm not sure what's what. I know what most of the characters are, and I thought I knew the length...so I can get it close and write up a script on my laptop to try to brute force the hash, that's if it can be recovered.

Thanks.

----------

## khayyam

Tonglebeak ...

The hash can't be extracted, if it could the dmcypt would be open to brute forcing via the hash, dmcypt uses PBKDF2 so the hash is salted. Your only option is to run your crack against the volume, such attacks can't be parallelised, dmcypt makes each attempt consume time.

There is perhaps another reason for your key not working, the luks header is corrupt, of course if you can't be sure of the passphrase then it may be, as your currently thinking, wrong, but header corruption is also a possibility. If you've made a backup of the header then it's possible to replace it from the backup.

HTH & best ...

khay

----------

## Tonglebeak

I don't have a backup of the header  :Neutral:  luksDump does print out a bunch of info about keyslots and such. Would luksDump print anything out if the header was corrupt?

----------

## khayyam

Tonglebeak ...

As far as I know, no. I'd imagine having an integrity field, or checksum, would provide a 'crib' which the attacker could use as a starting point.

best ... khay

----------

## Hu

A checksum for some of the metadata would not reveal anything, since it is very obvious that the volume is a LUKS container.  The checksum could safely cover any data that can be obtained by reading the block device.  It is only unsafe when the checksum covers data that is protected by the encryption.

----------

## khayyam

 *Hu wrote:*   

> A checksum for some of the metadata would not reveal anything, since it is very obvious that the volume is a LUKS container.  The checksum could safely cover any data that can be obtained by reading the block device.  It is only unsafe when the checksum covers data that is protected by the encryption.

 

I see ... I was thinking along the lines of the header, or as you say metadata, being able to verify its integrity (being able to say if it were "corrupt" or not, as the OP asked) and this lead me to think that it'd refer to something other than the header, the encypted data, and so provide a possible 'crib'.

Anyhow, I hadn't given it much thought ...

best ... khay

----------

## Tonglebeak

Thank. God. I wasn't dumb enough to throw away my password. Did some cleaning and found it.

I can't believe how far off I was. I missed 1 number the entire time, and had another letter out of sequence along with a couple of caps. I can't believe after entering so many times, I just completely botched it. That's what I get for memorizing keystrokes instead of the password itself. One keystroke off and bam it ruined me as I kept trying.

----------

## khayyam

Tonglebeak ...

I also memorise via keystrokes, or keyboard placement, such mnemonic learning is actually easier, but I also use some other mnemonic tricks that allow me to remember how I arrived at the password, and I keep a pass.gpg on a USB stick just incase.

Anyhow, now you know the header isn't corrupt you should make a backup:

```
% mount /dev/sdb1 /mnt/usbstick 

% cryptsetup luksHeaderBackup --header-backup-file /mnt/usbstick/luks-header-sdaX /dev/sdaX
```

best ...

khay

----------

## Tonglebeak

 *khayyam wrote:*   

> Tonglebeak ...
> 
> I also memorise via keystrokes, or keyboard placement, such mnemonic learning is actually easier, but I also use some other mnemonic tricks that allow me to remember how I arrived at the password, and I keep a pass.gpg on a USB stick just incase.
> 
> Anyhow, now you know the header isn't corrupt you should make a backup:
> ...

 

Thanks. How do I verify the backup was successful? I opened the backup file but it's just a bunch of random garbage.

----------

## khayyam

 *Tonglebeak wrote:*   

> Thanks. How do I verify the backup was successful? I opened the backup file but it's just a bunch of random garbage.

 

Tonglebeak ... the header is binary, its an exact copy of the header on the disk and so will look like an encypted file.

```
% file luks-header-sda

luks-header-sda: LUKS encrypted file, ver 1 [aes, xts-plain, sha1] UUID: e71f35e6-dbc9-42a3-88d0-603690124c3d
```

Like any file if you wanted to be sure of its integrity you measure it against a copy known to be good, or via a checksum of the file. There is no builtin method of doing this, its assumed a copy/backup is byte for byte correct. You could of course make two and compare them, but again like any file its a comparison.

best ... khay

----------

## Goverp

 *Tonglebeak wrote:*   

> Thank. God. I wasn't dumb enough to throw away my password. Did some cleaning and found it.
> 
> I can't believe how far off I was. I missed 1 number the entire time, and had another letter out of sequence along with a couple of caps. I can't believe after entering so many times, I just completely botched it. That's what I get for memorizing keystrokes instead of the password itself. One keystroke off and bam it ruined me as I kept trying.

 

The required xkcd link.

IMHO passphrases, i.e. lists of words that anyone but you will find unrelated, are much easier to recall.  And if you want to include numbers and special characters, add a date and some punctuation.  Heck, you could even use a URL.  My passphrase is "http://xkcd.com/936/".  or maybe not  :Smile: 

(I don't actually use LUKS, so my apologies if it has password rules that invalidate the above.  But that would be a good reason to use something else.)

----------

