I was just curious if someone had a high level overview of how a system like LUKS worked for full disk encryption, aka. how it stores keys and how those keys are verified, and if data is de-crypted by a wrapper for all standard i/o. I've seen partial explanations elsewhere but never a full high level explanation.
closed as too broad by Lie Ryan, S.L. Barth, techraf, Matthew, Rory Alsop♦ Aug 11 '16 at 10:32
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
I'm going to tell you what components compose the LUKS and how to they interact at a high level (I will not tell you the format of the metadata and how it is used).
This disk encryption solution is formed of two components: cryptsetup(userspace) and dm-crypt(kernelspace, Linux Kernel module).
cryptsetup is used to format the block device and to open the block device. Upon formatting and opening of the device you send the keys into kernelspace. The dm-crypt module instantiates an encryption context where it stores the session data/encryption key (CryptoAPI is the module inside the Linux Kernel that deals with all the criptography, it has criptographic accelerators support, etc). After you actually mount that block device, when you write/read to/from it, everything goes through that context.