Hello,
I want to set up an encrypted System with LUKS and I am wondering how it works.
When I open an encrypted drive or file container, does LUKS decrypt the whole thing, then write/read the data in the decrypted container as long as I am working with it and encrypt/close it again when I am done? That would mean it could leak data. Or does it encrypt/decrypt the data every time my system wants to write/read something?
Please let me know how it works.
Hey @uyscuti and welcome to the forums!
What LUKS does is format the entire drive as a container. In order to read/write in such an encrypted drive, you have to first unlock it via the passphrase you input during its setup.
As long as you operate in that drive and you have it unlocked, you can work on it as a normal drive and everything you write in is automatically encrypted. Everything that you read from the drive (or the system does), is automatically decrypted.
What LUKS basically does is what every encryption/decryption tool/container does. The moment you lock it back (i.e. reboot), the drive locks back up again. It’s like opening your safe to put things in or take things out. What this method allows is that if someone steals your system, they have no access to anything on the drive. If you installed Linux with LUKS encryption, they won’t be able to even boot.
Thank you for your answer @vasileios 
According to what you wrote that means, when I unlock the drive it never decrypts the whole container at once. That means the whole drive is never fully decrypted/exposed, but just the fragment you are reading/writing currently, right? And that also means, before every little access to the HDD/SSD, for example every little log entry, a crypt algorithm is executed and that may affect the performance, right?
Basically it is mounting a virtual drive, and if someone is connection the hardware drive to another system the person gets an error because the filesystem itself is inside the encrypted container, right?
I also read the bootloader itself is not encrypted. So if I install Linux with encryption the bootloader is loading but it can’t read anything from the Linux system itself right?
When I also can give a little advice, also for others, if someone steals your system they still can point a gun to your head so that you must reveal the passphrase. I found this problem is solved by a cryptsetup patch called libnvcrypt on github.
Hey @uyscuti,
That is correct. The unlocking grants you permission to access, but that doesn’t mean everything is decrypted and exposed. Generally, everytime access to a LUKS drive takes place (reading or writing), yes, the CPU will allocate the necessary resources to decrypt or encrypt the file.
Yes. LUKS sets up via LVM (Logical Volume Manager), which becomes a giant container. That’s how full-disk encryption works, and it’s most effective when someone tries to access your hardware directly. Especially if you use a strong passphrase, cracking a LUKS drive can take a really, really long time, even for a supercomputer (in the centuries).
The bootloader does not matter. It’s a generic instruction set that diverts to the root drive for further loading and holds zero sensitive or personal information. The moment that root drive is encrypted, cracking the bootloader offers nothing.
That is good to know! You can also use VeraCrypt for that one. It offers double-container encryption, which means it creates two encryption containers on the same drive (or file, if you go with file-container). Giving up the passphrase for the main drive does not open the hidden one.
Further info on how LUKS works, you can find here:
https://infosecwriteups.com/how-luks-works-with-full-disk-encryption-in-linux-6452ad1a42e8
@vasileios Thank you again for your help. 
But if I may ask two more question:
I set up my system succsesfully. Than I checked:
sudo cryptsetup status "drive"
It says “keysize” 512 bits. Shouldn’t be the keysize 256 bits because standard hash algorĂthm is sha256?
I also wanted to make sure that the encryption works properly. So I used “hexedit” to view the “RAW” data on the drive. Now obviously cryptsetup is executed before hexedit reads the data, so I still just can see the plain data with hexedit. Isn’t there a way to get to the layer before cryptsetup is executed, to view the real encrypted data? Or is there a way to log every cryptsetup execution before something is read?
Hey @uyscuti!
You’re very welcome!
The keysize and the SHA are two different aspects. The key is for the encryption, while the SHA is for the file identification.
Yes, you can check the data on your drive, however you’ll need to do it outside of the operating system, so that the container is not mounted. This means that the only way you can access it is if you do a full drive read/mapping via a drive HEX editor to read its blocks. I haven’t done that for a very long time, so I am a bit out of date with the disk editors for Linux (provided you’ll open the drive from a Linux OS).