Deleting root partition necessary before luks encrypting it?

hunter99 · 2023-11-03 11:52:44

I have read on the arch wiki that you need to delete a partition before you setup luks encryption on it.

What I did is that before encrypting the root partition, I ran:

mkfs.ext4 /dev/nvm0n1p3

then ran:

cryptsetup luksFormat /dev/nvme0n1p3
cryptsetup luksOpen /dev/nvme0n1p3 cryptroot
mkfs.btrfs /dev/mapper/cryptroot

Then I proceeded with installation, is that fine or do I need to delete the partition before encrypting it.
If yes, what’s the correct way of deleting partition?
Can I just delete the partition and create it again in the same place via cfdisk?

Last edited by hunter99 (2023-11-03 11:53:52)

mpan · 2023-11-03 16:44:45

Welcome to Arch Linux forum.

No, there is no need to delete the partition before setting up LUKS (or dm_crypt) encryption. You would not have a partition to setup encryption on it, if it was deleted, would you? Please point to the ArchWiki page, which suggests that — perhaps a correction is needed.

However, the commands you invoked give a hint, that you may not entirely understand the process and what setting up encryption does. `mkfs.ext4` to be specific. This mean you set up a ext4 filesystem, only to destroy it in the very next command (`cryptsetup luksFormat`). The encrypted container overwrites what was present on the device, so it makes no sense to create any filesystem beforehead.

hunter99 · 2023-11-04 05:44:36

I am talking about this: https://wiki.archlinux.org/title/Dm-cry … #Partition
Though the title says its for non root, but arch wiki on another page said that these instructions can be applied to root partitions too.

What I meant from deleting was to delete the partition, then create it and then encrypt it. So it doesn't have any filesystem.

I didn't delete it though. I'm asking that if I don't delete and recreate a partition and just luks encrypt it and then format it with my desired filesystem keeping in mind that the partition has a filesystem before encrypting is an okay way to do it?

Last edited by hunter99 (2023-11-04 06:28:49)

seth · 2023-11-04 08:14:55

The wiki wrote:

Delete the partition and create an empty one if it has a file system.

That's really just a clumsy way to get rid of the filesystem, b/c otherwise cryptsetup might (idk at hand) warn/refuse you, because you're about to nuke an existing filesystem.

You've a disk and cut that into chunks w/ fdisk or g/parted. Those chunks are "partitions". (This is actually optional but usually a very good idea)
Then you run mkfs on one of those partitions that will get you a filesystem where you can put files.
The encyption sits between partition and filesystem.

If you want an encrypted container inside an existing filesystemd, that'd be eg. https://wiki.archlinux.org/title/Dm-cry … _container

hunter99 · 2023-11-04 10:18:31

seth wrote:

The wiki wrote:
Delete the partition and create an empty one if it has a file system.
That's really just a clumsy way to get rid of the filesystem, b/c otherwise cryptsetup might (idk at hand) warn/refuse you, because you're about to nuke an existing filesystem.
You've a disk and cut that into chunks w/ fdisk or g/parted. Those chunks are "partitions". (This is actually optional but usually a very good idea)
Then you run mkfs on one of those partitions that will get you a filesystem where you can put files.
The encyption sits between partition and filesystem.
If you want an encrypted container inside an existing filesystemd, that'd be eg. https://wiki.archlinux.org/title/Dm-cry … _container

I understand that. I just wanna know the way I did it from the commands I posted in my first post is an okay way to do it or not? Would it cause problems etc?

ua4000 · 2023-11-04 10:32:53

It is ok and will work.

But notice:
If your nvme device had unencrypted data before on it, then your steps have not entirely purged them. There could be still many remains of unencrypted date on the device, easily accessible by rescue tools.
Have a look at https://wiki.archlinux.org/title/Securely_wipe_disk if this concerns you.

mpan · 2023-11-04 18:33:44

I changed that paragraph. I don’t know, what was the intended purpose. Deleting and re-creating an identical entry in the partition table would leave the data intact. Perhaps the author was using some software, which merges partition and filesystem operations, causing an unintended effect of “hiding” old data.

hunter99 wrote:

I understand that. I just wanna know the way I did it from the commands I posted in my first post is an okay way to do it or not? Would it cause problems etc?

Some of them are unnecessary, but they cause no problems to the encrypted volume itself.

Note that, if you had data on that partition before, merely creating an encrypted volume will not erase it.

Not performing either of the following operations — pre-filling the partition with random values, not filling the encrypted volume with zeros — may allow adversaries to gain some information about⁽¹⁾ encrypted data stored in the volume. This attack is of negligible importance for an average user, while mitigating it is time-consuming.⁽²⁾ So it’s up to you to decide, if you want to care about it. If you will enable TRIM, it will reintroduce the same issue, so mitigation makes no sense.
____
⁽¹⁾ “About data”, not the data itself. The data itself is protected. But it’s possible to deduce usage patterns, whether you changed some things between two sampling instances, in extreme cases learning something about your setup.
⁽²⁾ Requires filling the entire volume with data, which is a slow process. On a large HDD it can easily take an entire day, but even on SSDs it takes some time.

Last edited by mpan (2023-11-04 18:36:24)

hunter99 · 2023-11-05 13:13:09

mpan wrote:

I changed that paragraph. I don’t know, what was the intended purpose. Deleting and re-creating an identical entry in the partition table would leave the data intact. Perhaps the author was using some software, which merges partition and filesystem operations, causing an unintended effect of “hiding” old data.
hunter99 wrote:
I understand that. I just wanna know the way I did it from the commands I posted in my first post is an okay way to do it or not? Would it cause problems etc?
Some of them are unnecessary, but they cause no problems to the encrypted volume itself.
Note that, if you had data on that partition before, merely creating an encrypted volume will not erase it.
Not performing either of the following operations — pre-filling the partition with random values, not filling the encrypted volume with zeros — may allow adversaries to gain some information about⁽¹⁾ encrypted data stored in the volume. This attack is of negligible importance for an average user, while mitigating it is time-consuming.⁽²⁾ So it’s up to you to decide, if you want to care about it. If you will enable TRIM, it will reintroduce the same issue, so mitigation makes no sense.
____
⁽¹⁾ “About data”, not the data itself. The data itself is protected. But it’s possible to deduce usage patterns, whether you changed some things between two sampling instances, in extreme cases learning something about your setup.
⁽²⁾ Requires filling the entire volume with data, which is a slow process. On a large HDD it can easily take an entire day, but even on SSDs it takes some time.

I'm not looking to securely erase/wipe disk. The thing that concerned me and made me ask this question here is because the wiki said to delete the partition first. I didn't do that and went on with the encryption.
I was worried as I might have messed it up and I posted the commands in the order I used them.
I just wanted to know if I have messed up the process or not, not related to securely wiping etc.

Also, I don't know why the wiki asks to delete the partition and create it again to get rid of a filesystem? Can the luksFormat command be not run on a partition having a filesystem already? I think luksFormat deletes the already present filesystem and makes a luks one.

Last edited by hunter99 (2023-11-05 13:17:15)

loqs · 2023-11-05 13:27:09

hunter99 wrote:

Also, I don't know why the wiki asks to delete the partition and create it again to get rid of a filesystem?

The author was mistaken? As has been already stated that command as with your mkfs.ext4 first step serve no purpose but will not introduce issues.

hunter99 wrote:

Can the luksFormat command be not run on a partition having a filesystem already?

It can.

hunter99 wrote:

I think luksFormat deletes the already present filesystem and makes a luks one.

Technically it is a container.

mpan · 2023-11-05 14:23:48

hunter99 wrote:

Can the luksFormat command be not run on a partition having a filesystem already?

Yes. To limit the risk of using it on a wrong device, `cryptsetup luksFormat` may warn you about finding a filesystem. That is the only difference from a device containing zeros or garbage.

But, if that would be an issue, deleting and re-creating an identical partition wouldn’t help. If you’d ever need to remove signatures used to detect filesystems, see wipefs.

hunter99 wrote:

I think luksFormat deletes the already present filesystem and makes a luks one.

If you invoke `cryptsetup luksFormat`, it puts a LUKS header on the device, writing over what was filesystem’s structures earlier:

[ f i l e s y s t e m   s t r u c t u r e s   a n d   d a t a ]
           … and after luksFormat:
[ [LUKS HEADER] t e m   s t r u c t u r e s   a n d   d a t a ]

frostschutz · 2023-11-05 14:30:21

cryptsetup luksFormat tries to wipe magic bytes (similar to wipefs - might be reversible) then writes a LUKS header (~16M of random data at the start of the device - for most filesystems, this damages critical metadata already).

Anything else remains untouched until you actually write something to the LUKS device itself.

mkfs.ext4 is more aggressive. For SSD it discards the entire block device (similar to blkdiscard). All data [except for empty new ext4 filesystem] is irrecoverably gone - unless your SSD somehow doesn't support TRIM.

So you don't have to worry about unencrypted data... you already zapped it.

----

Will there be lasting problems when running mkfs.ext4 before luksFormat? Theoretically possible, if you tried to fix ext4 after luksFormat.

fsck.ext4: Inode checksum does not match inode while reading bad blocks inode
This doesn't bode well, but we'll try to go on...
Pass 1: Checking inodes, blocks, and sizes
Inode 1 seems to contain garbage.  Clear<y>? yes
Inode 2 seems to contain garbage.  Clear<y>? yes
Root inode is not a directory.  Clear<y>? yes
Inode 3 seems to contain garbage.  Clear<y>? yes
Quota inode is not in use, but contains data.  Clear<y>? yes
Inode 4 seems to contain garbage.  Clear<y>? yes
Quota inode is not in use, but contains data.  Clear<y>? yes
Inode 5 seems to contain garbage.  Clear<y>? yes

...aaand LUKS is damaged at this point.

That's why you never use fsck without a safety net... especially not if it starts asking questions.

How to get rid of old ext4 traces (more thoroughly than wipefs / luksFormat does): allow discards for your luks device and fstrim your luks filesystem, it should clear out most of it

Last edited by frostschutz (2023-11-05 14:38:16)

hunter99 · 2023-11-06 10:37:03

mpan wrote:

hunter99 wrote:
Can the luksFormat command be not run on a partition having a filesystem already?
Yes. To limit the risk of using it on a wrong device, `cryptsetup luksFormat` may warn you about finding a filesystem. That is the only difference from a device containing zeros or garbage.
But, if that would be an issue, deleting and re-creating an identical partition wouldn’t help. If you’d ever need to remove signatures used to detect filesystems, see wipefs.
hunter99 wrote:
I think luksFormat deletes the already present filesystem and makes a luks one.
If you invoke `cryptsetup luksFormat`, it puts a LUKS header on the device, writing over what was filesystem’s structures earlier:
[ f i l e s y s t e m   s t r u c t u r e s   a n d   d a t a ]
           … and after luksFormat:
[ [LUKS HEADER] t e m   s t r u c t u r e s   a n d   d a t a ]

I'm confused now. You mean it doesn't completely overwrite the filesystem that was present before, according to the diagram you posted.
Does it mean you should always run wipefs to delete the filesystem before running cryptsetup luksFormat? Or delete the partition and also remove filesystem using fdisk?

Also the last person said something about ext4 traces left there? Does it mean the old ext4 filesystem wasn't completely overwritten or what?

frostschutz · 2023-11-06 13:54:25

hunter99 wrote:

I'm confused now. You mean it doesn't completely overwrite the filesystem that was present before, according to the diagram you posted.

It writes a header. And wipes a few magic bytes. It can't know what else is there, not without overwriting everything, which would take time. With SSD, discarding everything would be an option, but cryptsetup does not do that (mkfs.ext4 does, if that's your goal you can do it manually with blkdiscard and lose all your data).

hunter99 wrote:

Does it mean you should always run wipefs to delete the filesystem before running cryptsetup luksFormat?

wipefs only removes a few signatures (it even tells you which ones).

$ wipefs -a test.img
test.img: 6 bytes were erased at offset 0x00000000 (crypto_LUKS): 4c 55 4b 53 ba be
test.img: 6 bytes were erased at offset 0x00004000 (crypto_LUKS): 53 4b 55 4c ba be

LUKS uses a 16MiB header... but wipefs erases only 6 bytes (LUKS\xba\xbe/SKUL\xba\xbe which is LUKS magic signature). The actual LUKS header (metadata, key material) remains untouched by wipefs. If you want those gone, use luksErase instead.

$ wipefs -a test.img
test.img: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef

For ext4, wipefs erases only 2 bytes. Backup superblocks etc. all remain untouched.

If nothing else is written afterwards, wipefs is usually reversible.

hunter99 wrote:

Or delete the partition and also remove filesystem using fdisk?

fdisk usually only rewrites the partition tables, not touching what is on the partitions at all (not even a magic signature wipe here). The exception is msdos extended/logical partitions, these are not stored in the partition table but in within the extended partition.

You're fine as long as you don't forcibly try to fix ext4 on what is now your cryptsetup partition.

Last edited by frostschutz (2023-11-06 13:55:36)

hunter99 · 2023-11-06 22:29:55

frostschutz wrote:

hunter99 wrote:
I'm confused now. You mean it doesn't completely overwrite the filesystem that was present before, according to the diagram you posted.
It writes a header. And wipes a few magic bytes. It can't know what else is there, not without overwriting everything, which would take time. With SSD, discarding everything would be an option, but cryptsetup does not do that (mkfs.ext4 does, if that's your goal you can do it manually with blkdiscard and lose all your data).
hunter99 wrote:
Does it mean you should always run wipefs to delete the filesystem before running cryptsetup luksFormat?
wipefs only removes a few signatures (it even tells you which ones).
$ wipefs -a test.img
test.img: 6 bytes were erased at offset 0x00000000 (crypto_LUKS): 4c 55 4b 53 ba be
test.img: 6 bytes were erased at offset 0x00004000 (crypto_LUKS): 53 4b 55 4c ba be
LUKS uses a 16MiB header... but wipefs erases only 6 bytes (LUKS\xba\xbe/SKUL\xba\xbe which is LUKS magic signature). The actual LUKS header (metadata, key material) remains untouched by wipefs. If you want those gone, use luksErase instead.
$ wipefs -a test.img
test.img: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef
For ext4, wipefs erases only 2 bytes. Backup superblocks etc. all remain untouched.
If nothing else is written afterwards, wipefs is usually reversible.
hunter99 wrote:
Or delete the partition and also remove filesystem using fdisk?
fdisk usually only rewrites the partition tables, not touching what is on the partitions at all (not even a magic signature wipe here). The exception is msdos extended/logical partitions, these are not stored in the partition table but in within the extended partition.
You're fine as long as you don't forcibly try to fix ext4 on what is now your cryptsetup partition.

Does creating a filesystem, say btrfs as I did after setting up luksFormat remove the remaining headers/signatures of ext4 that were previously present?
I'm curious as to why fsck ext4 can be run on a luks encrypted btrfs partition as ext4 is not there?

Also, let's say I want to do the same some other day i.e encrypt a partition that already has a filesystem on it, is there a better way to do it than just running luksFormat on it?

Last edited by hunter99 (2023-11-06 22:53:43)

Arch Linux

#1 2023-11-03 11:52:44

Deleting root partition necessary before luks encrypting it?

#2 2023-11-03 16:44:45

Re: Deleting root partition necessary before luks encrypting it?

#3 2023-11-04 05:44:36

Re: Deleting root partition necessary before luks encrypting it?

#4 2023-11-04 08:14:55

Re: Deleting root partition necessary before luks encrypting it?

#5 2023-11-04 10:18:31

Re: Deleting root partition necessary before luks encrypting it?

#6 2023-11-04 10:32:53

Re: Deleting root partition necessary before luks encrypting it?

#7 2023-11-04 18:33:44

Re: Deleting root partition necessary before luks encrypting it?

#8 2023-11-05 13:13:09

Re: Deleting root partition necessary before luks encrypting it?

#9 2023-11-05 13:27:09

Re: Deleting root partition necessary before luks encrypting it?

#10 2023-11-05 14:23:48

Re: Deleting root partition necessary before luks encrypting it?

#11 2023-11-05 14:30:21

Re: Deleting root partition necessary before luks encrypting it?

#12 2023-11-06 10:37:03

Re: Deleting root partition necessary before luks encrypting it?

#13 2023-11-06 13:54:25

Re: Deleting root partition necessary before luks encrypting it?

#14 2023-11-06 22:29:55

Re: Deleting root partition necessary before luks encrypting it?

Board footer