[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 :)

  • JJLinux@lemmy.ml
    link
    fedilink
    arrow-up
    4
    ·
    4 months ago

    Never apologize for enjoying the discovery of new things. That’s awesome, enjoy it.

  • hperrin@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    4 months ago

    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.

    • Jawa@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      You can also just split the password for a single LUKS into two parts and give one each to the two people :D

      • flashgnash@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        But then you know both parts of the password and so must be killed to keep the machine secure

        • Jawa@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          3 months ago

          Ideally you would never have to because you just have the two people come up with their part of the password and then initialise the LUKS partition together. Sorta like a key ceremony

    • communism@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      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.

  • Qkall@lemmy.ml
    link
    fedilink
    arrow-up
    3
    ·
    4 months ago

    we really ain’t making any jokes on the name of the drives? okay…

  • Max-P@lemmy.max-p.me
    link
    fedilink
    arrow-up
    1
    ·
    4 months ago

    Yeah, LUKS and most block level overlays just don’t care. That’s what good abstraction layers do for you!

    You can LUKS on a disk image mounted over SSHFS that itself resides on a Ceph cluster and mounted over iSCSI for all it cares. Is it a block device? Yes? Good to go.

    You can even LUKS a floppy if you want. Or a CD.

  • theit8514@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    You can, sure, but you probably shouldn’t. Encrypting and decrypting consume additional cpu time, and you won’t gain much in terms of security.

    • auth@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      4 months ago

      not really if you have a hardware chip that does the encrypt/decrypting