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

  • auth
    7•4 months ago

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

    • @cbarrick@lemmy.worldEnglish
      27•4 months ago

      AES has been accelerated on all Intel CPUs since Broadwell, was common as far back as Sandy Bridge, and has been available since Westmere.

      AMD has had AES acceleration since Bulldozer.

      But the commenter is right that adding a second layer of encryption is useless in everything except very specific circumstances.

      • @theit8514@lemmy.world
        6•4 months ago

        Yes, but as I’ve found recently AES-NI is only as good as your software support for it. Had a team using an ancient version of winscp and they kept complaining about download speeds on our 10Gb circuit. Couldn’t replicate it on any other machine with the newest version of winscp so I installed their exact version. AES-NI support wasn’t added until like 2020 and it gave them 5x better download speed after upgrading.

      • auth
        4•4 months ago

        agreed that it is useless for most cases but I could see it being useful if you need multiple people to agree on decrypting a file.

          • auth
            1•4 months ago

            that’s another way, I guess… if you want to split the file, that is

            • @cbarrick@lemmy.worldEnglish
              3•4 months ago

              No, you don’t split the file. You split the master decryption key.

              Each user just needs to remember their own password, and SSS can reconstruct the master key when enough users enter their passwords.

        • @Killing_Spark@feddit.de
          2•4 months ago

          That’s pretty nitty although you can always just partition a long key and distribute the partitions to the different people

          • auth
            4•4 months ago

            there’s always more than one way to skin a rat

      • @taaz@biglemmowski.winEnglish
        4•4 months ago

        I’ve also found about this recently when moving my root from drive to drive which was after I upgraded to 13th gen intel (from various older i5s) and the best cipher changed (cryptsetup benchmark).

      • @krash@lemmy.ml
        2•4 months ago

        What circumstances would that be? I can’t see the use case doe this, but I’m open to see how and when that would be needed.

        • @cbarrick@lemmy.worldEnglish
          2•4 months ago

          There’s a Wikipedia article on multiple encryption that talks about this, but the arguments are not that compelling to me.

          The main thing is mostly about protecting your data from flawed implementations. Like, AES has not been broken theoretically, but a particular implementation may be broken. By stacking implementations from multiple vendors, you reduce the chance of being exposed by a vulnerability in one of them.

          That’s way overkill for most businesses. That’s like nation state level paranoia.

      • auth
        4•4 months ago

        it depends if your hardware supports the algos that cryptsetup/luks use I guess…