I have been testing Ubuntu 21.04 and i have noticed when doing an encrypted install there is a recovery key generated (I don’t know if this is the first time this exists in Ubuntu), I don’t like that it’s only numeric and only 16 characters long.
In my opinion it would be better if it was like 7 or more random words from the language the user has selected at the beginning of the install , so the key could easily be written down on paper, or be remembered.
So I spent some time looking into this today and I don’t think it is a concern - firstly I have confirmed that the recovery password is cryptographically secure - this was added to the ubiquity installer in https://git.launchpad.net/ubiquity/commit/?id=0e4ca86842759767dac7c8dee31a3873e2944d6e and uses uuid4() from the python standard library - which in turn uses os.urandom() which is good enough for this purpose: https://github.com/python/cpython/blob/master/Lib/uuid.py#L715
With that out of the way, we can look at how to crack it - in this case, we use LUKS2 and so can use something like bruteforce-luks to try and crack it - unfortunately the version in the Ubuntu archive doesn’t know the newer LUKS2 header format so we have to compile it from source:
wget https://github.com/glv2/bruteforce-luks/releases/download/1.4.0/bruteforce-luks-1.4.0.tar.lz
tar xf bruteforce-luks-1.4.0.tar.lz
cd bruteforce-luks-1.4.0/
sudo apt install libcryptsetup-dev
./configure
make
Then assuming we have a suitable LUKS2 disk header in the file /run/user/1000/luks-header (I put this under /run/user/1000 as this is a RAM-backed tmpfs and so will be faster than accessing a real disk) - we can try and crack it as follows:
./bruteforce-luks -m 16 -l 16 -s 0123456789 /run/user/1000/luks-header -t 8 -v10
ie. restrict bruteforce-luks to only 16 char long passwords using the chars from 0-9 and use 8 threads and report progress every 10 seconds - this shows output like the following:
Tried / Total passwords: 8 / 1e+16
Tried passwords per second: 0.800000
Last tried password: 0000000000000015
Total space searched: 0.000000%
ETA: more than 200 years :(
Tried / Total passwords: 24 / 1e+16
Tried passwords per second: 1.200000
Last tried password: 0000000000000031
Total space searched: 0.000000%
ETA: more than 200 years :(
So it would take more than 200 years to crack such a password using this technique.
Thank you for looking into it!
Unfortunately this confirms my concerns, 200 yrs in computing time now, are not going to be 190 yrs in ten years time, so if i install Ubuntu 21.04 now then upgrade my way along, i could run into a problem without knowing, a couple of years into the future.
Can we have the possibility to opt-out of the recovery-key or supply a user defined recovery-key?
It doesn’t look like it is possible to set a custom recovery key at the moment but looking at the code in ubiquity I suspect it might be as simple as changing:
<object class="GtkEntry" id="recovery_key">
<property name="editable">False</property>
to:
<object class="GtkEntry" id="recovery_key">
<property name="editable">True</property>
@jibel does this seem like a reasonable change to make? I realise it is past UI freeze so this may not be possible for 21.04 but perhaps we can look into this for 21.10?
@alexmurray At the moment it is not possible to set a custom recovery key. The reason behind current implementation was that the keyboard layout at boot time is not necessarily known when machine is recovered from a user and the digits are easy to enter via a keypad or a standard location at the top of the keyboard.
Point 2 cannot be done for 21.04 but we can look into it for 21.10.
If the current strength of the digit only passphrase is an issue we can increase its length to the value you think is good for 21.04 (released on Apr. 22nd)