-1

This question is an exact duplicate of:

I did a full install with FDE on a usb of Kali linux. However grub was bad so had to boot-repair from live image and I'm worried I messed up my encryption.

The output of fdisk -l is:

Disk /dev/sdb: 57.9 GiB, 62109253632 bytes, 121307136 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcdbbda92

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sdb1         2048    499711    497664  243M 83 Linux
/dev/sdb2       501758 121305087 120803330 57.6G  5 Extended
/dev/sdb5       501760 121305087 120803328 57.6G 83 Linux


Disk /dev/mapper/sdc5_crypt: 57.6 GiB, 61849206784 bytes, 120799232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/Kali--vg-root: 17.2 GiB, 18442354688 bytes, 36020224 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/Kali--vg-swap_1: 7.9 GiB, 8510242816 bytes, 16621568 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/Kali--vg-home: 32.5 GiB, 34892414976 bytes, 68149248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Why is /dev/sdb not seemingly encrypted?

marked as duplicate by msp9011, Rui F Ribeiro, slm Aug 14 '18 at 20:39

This question was marked as an exact duplicate of an existing question.

  • try lsblk instead of fdisk. chances are sdc5_crypt is actually on sdb, not sdc (might have been sdc at install time only) – frostschutz Aug 14 '18 at 6:38
2

The /dev/sdb represents the whole disk in raw form: you need it to access those parts of the disk that must not be encrypted, like the MBR, the partition table and the bootloader.

(If those parts are encrypted, then the system firmware cannot make any sense of the contents of the disk, and so the system cannot successfully boot from it.)

In Linux, enabling encryption does not change the way the original disk/partition device node works: instead, when you enter the encryption passphrase, a new device node is created that allows you to access the encrypted content in a decrypted form. You can then use this new device node just as if it were a regular, unencrypted disk.

This also allows you to layer on different disk management techniques on top of each other: in your case, you apparently have LVM on top of an encrypted partition on top of a partitioned disk.

Should you have a need for it (e.g. for diagnostic or verification purposes), you can use the corresponding original device node to access the raw data, e.g. to verify that the contents of the encrypted disk/partition are indeed unintelligible gibberish instead of any recognizable data you've written using the encryption device node.

As frostschutz commented, your /dev/mapper/sdc5_crypt probably actually is the "view" to /dev/sdb5 through the encryption: the name of the encryption device could be anything, it's just that the installer autogenerated the name using the name of the original disk device (as it was at the time of installation) with a _crypt suffix attached.

The lsblk or dmsetup ls --tree -o blkdevname can display the relationships between the various devices in easy-to-understand form.

I don't actually have enough information to say with 100% certainty whether your disks are encrypted or not (I'd need the output of either of the above-mentioned commands for that), but based on the sizes of the disk devices listed by fdisk, it looks like your /dev/mapper/Kali--vg-root, /dev/mapper/Kali--vg-swap_1 and /dev/mapper/Kali--vg-home (or in other words, logical volumes named root, swap_1 and home of LVM volume group Kali-vg) are probably contained within /dev/mapper/sdc5_crypt (which would then also be your LVM physical volume), which is probably the encryption device for /dev/sdb5.

The contents of /dev/sdb1 are not encrypted, as this is probably the /boot filesystem: it does not normally contain any user data, so there is not much point encrypting it. With a modern version of GRUB, however, it is technically possible to encrypt that too, but that makes the start-up procedure a bit inconvenient. You'd need to enter the boot password twice: once for GRUB, and then again for the Linux kernel. It would also make it much harder to recover from any problems that might happen on kernel updates.

Not the answer you're looking for? Browse other questions tagged or ask your own question.