[Image description:
Screenshot of terminal output:
~ ❯ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 62.5M 0 disk
└─topLuks 254:2 0 60.5M 0 crypt
└─bottomLuks 254:3 0 44.5M 0 crypt
/end image description]
I had no idea!
If anyone else is curious, it’s pretty much what you would expect:
cryptsetup -y -v luksFormat /dev/sda
cryptsetup open /dev/sda topLuks
cryptsetup -y -v luksFormat /dev/mapper/topLuks
cryptsetup open /dev/mapper/topLuks bottomLuks
lsblk
Then you can make a filesystem and mount it:
mkfs.ext4 /dev/mapper/bottomLuks
mount /dev/mapper/bottomLuks ~/mnt/embeddedLuksTest
I’ve tested putting files on it and then unmounting & re-encrypting it, and the files are indeed still there upon decrypting and re-mounting.
Again, sorry if this is not news to anyone else, but I didn’t realise this was possible before, and thought it was very cool when I found it out. Sharing in case other people didn’t know and also find it cool :)
It would be good if you wanted to have a system that two people need to be present to unlock. Like those nuke launch locks that need two keys.
You can also just split the password for a single LUKS into two parts and give one each to the two people :D
Yeah, you’re right. That’s better.
Tbf this would enforce the order in which the two people decrypt it, which may not be good if you expect these two people to “arrive” asyncrhonously and you don’t want them to have to wait for the other before entering their password/key. But maybe that’s too specific of a use case.
Never apologize for enjoying the discovery of new things. That’s awesome, enjoy it.
Where’s the ZFS love…
Great! Although I think that security actually goes down that way. Something something about statistics. A crypto expert could probably explain that properly and we could pretend to understand it.
Now recursively create more layers until you have barely any free space left on the disk, then do some performance benchmarks. ;)
I guess your…Luks not running out.
Take my angry upvote, you heathen.