Page MenuHomePureOS Tracker

GNOME Disks destroys disk encryption password when trying to change it
Open, HighPublic

Description

Started GNOME Disks, trying to change my disk encryption password: https://tracker.pureos.net/w/pureos/tips/change_disk_encryption_password/

Error is reported:

After restart I was not able to unlock my disk! Neither old or the new password worked.

Perhaps a candidate for reporting upstream.

Event Timeline

mladen created this task.Aug 10 2018, 12:20
mladen created this object with edit policy "Restricted Project (Project)".
mladen reassigned this task from zlatan.todoric to mak.Nov 9 2018, 01:06
mladen added a subscriber: zlatan.todoric.
mladen reassigned this task from mak to jeremiah.foster.Jan 26 2019, 02:59
mladen added a subscriber: mak.

I will try to reproduce this.

jeremiah.foster triaged this task as High priority.Jan 28 2019, 11:07

Looks like this is a wipefs error. Needs more investigation.

@jeremiah.foster as per @chris.lamb advice, I want to raise a concern about this, we either need to fix it now, or to somehow warn users about this issue.

It looks like using GNOME disks may change the LUKS header file when it does a wipefs. I would warn users about this and instead refer folks to this resource: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#2-setup

jeremiah.foster added a comment.EditedFeb 24 2019, 11:03

Here are the warnings from cryptsetup's FAQ. We need to determine which one is relevant to GNOME Disks before advising users to use GNOME disks.

DISTRIBUTION INSTALLERS: Some distribution installers offer to create LUKS containers in a way that can be mistaken as activation of an existing container. Creating a new LUKS container on top of an existing one leads to permanent, complete and irreversible data loss. It is strongly recommended to only use distribution installers after a complete backup of all LUKS containers has been made.

UBUNTU INSTALLER: In particular the Ubuntu installer seems to be quite willing to kill LUKS containers in several different ways. Those responsible at Ubuntu seem not to care very much (it is very easy to recognize a LUKS container), so treat the process of installing Ubuntu as a severe hazard to any LUKS container you may have.

NO WARNING ON NON-INTERACTIVE FORMAT: If you feed cryptsetup from STDIN (e.g. via GnuPG) on LUKS format, it does not give you the warning that you are about to format (and e.g. will lose any pre-existing LUKS container on the target), as it assumes it is used from a script. In this scenario, the responsibility for warning the user and possibly checking for an existing LUKS header is shifted to the script. This is a more general form of the previous item.

LUKS PASSPHRASE IS NOT THE MASTER KEY: The LUKS passphrase is not used in deriving the master key. It is used in decrypting a master key that is randomly selected on header creation. This means that if you create a new LUKS header on top of an old one with exactly the same parameters and exactly the same passphrase as the old one, it will still have a different master key and your data will be permanently lost.

PASSPHRASE CHARACTER SET: Some people have had difficulties with this when upgrading distributions. It is highly advisable to only use the 95 printable characters from the first 128 characters of the ASCII table, as they will always have the same binary representation. Other characters may have different encoding depending on system configuration and your passphrase will not work with a different encoding. A table of the standardized first 128 ASCII characters can, e.g. be found on http://en.wikipedia.org/wiki/ASCII

KEYBOARD NUM-PAD: Apparently some pre-boot authentication environments (these are done by the distro, not by cryptsetup, so complain there) treat digits entered on the num-pad and ones entered regularly different. This may be because the BIOS USB keyboard driver is used and that one may have bugs on some computers. If you cannot open your device in pre-boot, try entering the digits over the regular digit keys.

This affects Ubuntu as well, leading me to believe the issue is upstream in GNOME disks; https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1790979

What evidence is there that the password was "destroyed"? Is it possible that something else happened? I say this because the GNOME disks dialog is stating that there was an error changing the passphrase, it doesn't say that the password was changed or destroyed.