Keep in mind, the author of this work talks about the methods of encrypting disk partitions that he uses himself, with.
linux
IN this manual used Linux dm-crypt (device-mapper) on the core 2.6 . We will encrypt the section /dev/sdc1, it can be any partition, disk, USB, or file created losetup. Here we will use /dev/loop0, look . device mapper uses a label to identify a section, in this example sdc1, but it can be any other string.
Encrypting disk partitions with LUKS
LUKS With dm-crypt very convenient for encrypting disk partitions, it allows you to have multiple passwords for one partition and also to easily change them. To check if you are available to use LUKS, type: cryptsetup --help if about LUKS nothing appeared, read below " dm-crypt without LUKS". First, create a partition, if necessary fdisk /dev/sdc.How to create an encrypted partition
# dd if=/dev/urandom of=/dev/sdc1 # Optional. Only for the paranoid# cryptsetup -y luksFormat /dev/sdc1 # This will destroy all data on sdc1 # cryptsetup luksOpen /dev/sdc1 sdc1 # mkfs.ext3 /dev/mapper/sdc1 # A file system will be created ext3 # mount -t ext3 /dev/mapper/sdc1 /mnt # umount /mnt # cryptsetup luksClose sdc1mount
# cryptsetup luksOpen /dev/sdc1 sdc1 # mount -t ext3 /dev/mapper/sdc1 /mntUnmount
# umount /mnt # cryptsetup luksClose sdc1dm-crypt without LUKS
# cryptsetup -y create sdc1 /dev/sdc1 # Or any other section like /dev/loop0 # dmsetup ls # Check, will show: sdc1 (254, 0) # mkfs.ext3 /dev/mapper/sdc1 # Only if done for the first time!# mount -t ext3 /dev/mapper/sdc1 /mnt # umount /mnt/ # cryptsetup remove sdc1 # Detach encrypted partition Do the same (without creating fs) to remount the partition. If an incorrect password is entered, the mount command will fail. In that case just remove the display sdc1 (cryptsetup remove sdc1) and create a new one.FreeBSD
A couple of popular disk encryption modules are gbde And geli. Geli faster because it uses hardware acceleration. See the FreeBSD handbook Chapter 18.6 for more detailed description. For work, geli must be loaded as a kernel module, or built into it at compile time. options GEOM_ELI device crypto # Or load as a kernel module:# echo "geom_eli_load="YES"" >> /boot/loader.conf # Or kldload geom_eliUsing a password and key
The author uses these settings for typical partition encryption, he uses a password and a key to encrypt " master key- master key". In order to mount the encrypted partition, you will need both a password and a key /root/ad1.key. "master key" is stored inside the partition and is invisible. The following example is typical for a USB or file image.Create an encrypted partition
# dd if=/dev/random of=/root/ad1.key bs=64 count=1 # This key encrypts the Master key# geli init -s 4096 -K /root/ad1.key /dev/ad1 # -s 8192 and OK for drives# geli attach -k /root/ad1.key /dev/ad1 # DO creates backup/root/ad1.key# dd if=/dev/random of=/dev/ad1.eli bs=1m # Optional and time consuming # newfs /dev/ad1.eli # Create a file system# mount /dev/ad1.eli /mnt # Mount encrypted partitionAttach
# geli attach -k /root/ad1.key /dev/ad1 # fsck -ny -t ffs /dev/ad1.eli # If in doubt, check the filesystem# mount /dev/ad1.eli /mntDetach
The unmount procedure is performed automatically at shutdown. # umount /mnt # geli detach /dev/ad1.eli/etc/fstab
The mounting of an encrypted partition can be configured via /etc/fstab. The password will be requested upon download. # grep geli /etc/rc.conf geli_devices="ad1" geli_ad1_flags="-k /root/ad1.key" # grep geli /etc/fstab /dev/ad1.eli /home/private ufs rw 0 0Password only
This is a more suitable way to encrypt a flash drive or an image based on a file, it only asks for a password. In this case, you don't need to worry about key files. The procedure is similar to the one described above, except for creating key files. Let's encrypt a 1 GB image created from a file /cryptedfile. # dd if=/dev/zero of=/cryptedfile bs=1M count=1000 # Create a 1GB file# mdconfig -at vnode -f /cryptedfile # geli init /dev/md0 # Encrypt with password only# geli attach /dev/md0 # newfs -U -m 0 /dev/md0.eli # mount /dev/md0.eli /mnt # umount /dev/md0.eli # geli detach md0.eli Now this image can be mounted on another machine by simply entering a password. # mdconfig -at vnode -f /cryptedfile # geli attach /dev/md0 # mount /dev/md0.eli /mntIntroduction
Storing data in encrypted form is a great way to protect information so that it does not get to an attacker. Cryptographic systems are developed to protect intellectual property, trade secrets or personal information. They can come in a variety of forms, offer different levels of functionality, and contain any number of options to suit a wide range of operating environments and environments. Today, the number of modern cryptographic methods, algorithms and solutions is much greater than before. And the quality of development is much better. Moreover, there are many workable solutions on the market based on open source, which allows you to achieve a good level of protection without spending large sums of money.
In December 2005, the Ponemon Institute conducted a survey among various information security professionals regarding encryption and data protection. Among the 6,298 respondents, only 4 percent of respondents used enterprise-wide encryption. The same survey revealed three main reasons for the staunch opposition to official encryption rules:
- 69% of those surveyed mentioned performance issues;
- 44% of respondents mentioned implementation difficulties;
- 25% of respondents spoke about the high cost of implementing cryptographic algorithms.
Organizations in many countries are subject to many levers of pressure to increase the "transparency" of their work. But, on the other hand, they have a statutory responsibility for not ensuring the safety of confidential information. This was the case, in particular, in the case of DSW shoe stores in the United States).
The US Federal Trade Commission filed a lawsuit against DSW, which stated that it did not provide an adequate level of information protection and did not take proper measures to build adequate systems for restricting access to this data, as well as the poor protection of network connections between store and office computers. In the case of DSW, approximately 1.4 million credit cards and about 96,000 checking accounts were potentially available to criminals. And before the agreements between the company and the FTC were reached, these accounts had already been used illegally.
Nowadays, software and engineering solutions for data encryption are available more than ever. The USB key, which is becoming cheaper day by day, is increasingly being used instead of smart cards. The latter, in turn, can also often be found, because most laptops contain a smart card reader.
Consumers are increasingly beginning to think about the dangers associated with the theft of personal information, owner data, credit card numbers. And these fears are only fueled by reports of massive sales of stolen information of this kind from institutions entrusted with such valuable data.
Consumers are also beginning to realize that it is important to protect personal information not only online but also offline. After all, unwanted access to your data doesn't always happen over the web. This issue is especially relevant for those whose unprotected laptops can either fall into the hands of service personnel to change the configuration, or to the service for repairs.
Technical Encryption Issues
Encryption features are essential to all modern multiplayer computer systems where data, processes and user information are logically separated. To authenticate a user in such a system, logins and passwords are hashed and compared with the hashes already in the system (or the hash is used to decrypt the session key, which is then checked for validity). In order to prevent unauthorized viewing of personal information, individual files or entire sections may be stored inside encrypted containers. A network protocols, for example, SSL \ TLS and IPSec, allow, if necessary, to strengthen cryptographic protection various devices(/dev/random, /dev/urandom, etc.) using modular algorithms that work with the operating system kernel.
The purpose of any disk encryption technology is to protect against unwanted access to personal information and to reduce the damage from loss of intellectual property resulting from illegal access or theft of a physical device. The Linux operating system with kernel version 2.6.4 introduced an advanced cryptographic infrastructure that simply and securely protects personal data at many levels of software. There are entire standards for storing data encrypted at a low level, like Linux Unified Key Setup (LUKS), and user-level implementations, such as the EncFS and CryptoFS file systems, which in turn are based on the Fast Userspace File System ( FUSE) under Linux. Of course, any cryptographic system is only as resistant to hacking as its passwords and access keys are. In total, there are three main levels at which encryption technologies are applied:
- file level and file system(per-file encryption, container with files);
- low block level (container with file system);
- hardware level (specialized cryptographic devices).
File-level encryption is a very simple technique commonly used for file sharing. Encryption is used on a case-by-case basis, which is handy for transferring a reasonable number of files. For multi-user file systems, there is a key management issue because folders and files of different users are encrypted different keys. Of course, you can use one key, but then we get a technology that resembles disk encryption. As always, it is the user's responsibility to choose the most secure password.
More advanced cryptographic applications work at the file system level, keeping track of files as they are created, written, or modified. This method provides the best protection for personal information in any way it is used, and it is also good for a large number of files. In addition, there is no need to worry about applications that do not know how to encrypt files individually.
Some cryptographic technologies are free and included in many distributions. By the way, latest versions Windows is equipped with a special file system that supports Encrypted File System (EFS) encryption. Fedora supports a number of encryption options, including LUKS (you can enable LUKS support under Windows if you use file FAT systems or FAT32 and the FreeOTFE application). And FUSE and EncFS are available in Extras packages. CryptoFS can also be installed by downloading from official site. .
The FUSE infrastructure consists of a loadable kernel module and a userspace library that serves as the basis for both the CryptoFS and Encrypted file systems. file system(EncFS). By its design, FUSE does not affect the kernel source code and at the same time provides high flexibility to implement many interesting additions, for example, the Secure Shell file system (SSHFS) remotely mounted file system.
CryptoFS stores encrypted data in a familiar directory structure, divided into two main parts: text information(list of files, folders, archives) and the actual encrypted data. You can only remount an encrypted directory using the key. When using CryptoFS, you do not need special privileges, and setting it up is also easy.
The EncFS file system is also a userspace implementation based on the FUSE library that provides protection against information theft and works on the principle of file-by-file encryption. It inherited its structure from earlier versions, but with improvements in both form and function. The EncFS file system can be dynamically expanded to meet growing user requirements. Files can be encrypted according to various parameters (for example, when changing content, attributes, etc.). Basically, the underlying storage for EncFS can be anything from an ISO image to a network partition or even a distributed file system.
Both file systems work end-to-end and can be used on top of other file systems and logical abstractions, such as a journal or extended file system that can be distributed across multiple physical media through a manager logical partitions(LVM). The following illustration schematically shows how this file system works: in this diagram, the visible directory is /mount (EncFS unencrypted data level).
Userspace overlay showing the interaction between FUSE and EncFS.
Below the file system abstraction layer are low-level (block) encryption schemes like those used in LUKS. Schemes of this type work only on disk blocks, ignoring the abstractions of the file system more high levels. Similar schemes can be used for swap files, for various containers, or even for entire physical media, including full encryption of the root partition.
LUKS works without exact knowledge of the file system format.
LUKS is designed according to Trusted Key Setup #1 (TKS1) and is compatible with Windows when using some common file system format (FAT/FAT32). The system is well suited for mobile users, supports issuing and revoking Gnu Privacy Guard (GPG) keys, and is completely free. LUKS is capable of much more than any other implementation described in this article. Moreover, LUKS supports a large number of solutions for creating and managing LUKS encrypted devices.
The CryptoFS file system only accepts a password, while media encrypted with LUKS works with any PGP (Pretty Good Privacy) keys with any number of passwords. EncFS also uses a password to protect files, but it opens a key stored in the corresponding root directory.
The differences between low level and userspace implementations are best seen in practical tests. At a low level, data can be "transparently" transferred to the file system, which handles writes and reads much more efficiently.
Test configuration
Our test platform was the Dell Latitude C610 laptop, a bit outdated, but still quite nimble representative of the technology of the 2002 model. On battery power, the C610 drops the CPU clock to 733MHz. Therefore, during testing, we did not unplug the laptop from the outlet. The following table shows the laptop configuration
The test results were obtained using the EXT3 file system under Linux. Perhaps EXT3 is not the most performant compared to other journaling filesystems. But experiments with fine tuning system format, block size, drive parameters, etc. are not subject to our testing, as they do not meet the criteria for simple setup and configuration. Recall that the purpose of the article was to show how Linux cryptographic solutions make it easy, efficient and cheap to create secure data stores.
Installation
LUKS, FUSE, and EncFS are available in the Fedora distribution, so no extra effort is required. But CryptoFS will have to be downloaded separately.
Compiling CryptoFS from source is fairly straightforward. Unzip the archive, run the configuration script in the target directory, then run make as shown in the illustration. The configuration file contains four parameters: encryption cipher, message digest algorithm, block size, and encryption salt count.
The installation process for CryptoFS is simple.
The configuration consists of specifying the paths of the start and end directories (for encrypted and unencrypted data). You can then run the cryptofs command as shown in the following figure.
CryptoFS setup.
Then you can run the mount command, after which you can see the mounted partition.
First, make sure to load the FUSE kernel module (modprobe fuse). EncFS simplifies the process of creating an encrypted container, as seen in the following illustration.
By omitting the key installation process (which is specific to each situation), LUKS can be easily configured as shown below.
Benchmarks and performance analysis
The performance differences between a native installation and a LUKS-encrypted installation are fairly minor. Especially given the noticeable difference in userspace solutions. To evaluate the performance of encrypted file systems one by one, we used Iozone. Records from 4 KB to 16 MB are used for tests, the file size varies from 64 KB to 512 MB, and the result is specified in KB/s.
Conclusion
At least where LUKS is used, you don't have to worry about performance. Although, of course, some performance loss is caused by "transparent" data encryption. LUKS is easy and simple to install and can be used on both Linux and Windows.
Corporate users will certainly have to deal with restrictions related to company policy. Often they ban open source solutions or ban some implementations. In addition, sometimes you have to consider restrictions on the import / export of encryption technologies regarding code strength, or the IT department requires telephone support from the solution provider, which allows you to forget about LUKS, EncFS and CryptoFS. In any case, LUKS is a great solution if similar problems you are not disturbed. A good option for small businesses or home users.
But keep in mind that data encryption is not a panacea. Because encryption is transparent, any Trojan, running on behalf of the user, can access encrypted data.
Editor's opinion
CryptoFS and EncFS are userspace implementations. As we explained earlier, they are simple in design and implementation, but come at the cost of performance and features. This is especially evident when compared with LUKS. Not only is it noticeably faster, but it also supports one or more PGP keys and can be used on an entire partition.
Userspace containers are important primarily for users who want to protect personal information in a multi-user environment. And who needs to protect their data so that even an administrator cannot access hardware or software resources. In addition to performance and cross-platform support advantages, LUKS integrates well with GNOME and PGP key management systems. And the ease of everyday use of LUKS encrypted partitions is simply impressive. By the way, EncFS supports Pluggable Authentication Module (PAM) under Linux in appropriate environments.
: - Russian
Active page development completed
If there is something to add, then supplement the sections with new information. Our typos and errors in the article can be edited safely, there is no need to report it by mail, please follow the style of this page and use section separators (gray lines of various thicknesses).
Data Encryption in Debian
Many people think that you do not need to encrypt your data. However, in everyday life, we often encounter such situations as “a flash drive was lost” or “a laptop was handed over for repair”, etc. If your data is encrypted, then you don’t have to worry about it at all: no one will publish it on the Internet, or use it in any other way.
Encryption with cryptsetup
Install the necessary components:
# apt-get install cryptsetupStandard Syntax
/dev/sda2. Let's enter the command:
# cryptsetup create sda2_crypt /dev/sda2This command will create an encrypted connection to our disk. In catalog /dev/mapper a new device will appear with the name we requested: /dev/mapper/sda2_crypt, accessing which we use encrypted disk access. In the case of LUKS, the name would be /dev/mapper/sda2_crypt
If there was already a file system on the disk and we would like to save data on it, then we need to encrypt them for their subsequent use:
# dd if=/dev/sda2 of=/dev/mapper/sda2_cryptIf a new disk is created on an empty partition, then you can format it:
# mkfs.ext3 /dev/mapper/sda2_cryptLater, you can mount this disk anywhere:
# mount /dev/mapper/sda2_crypt /path/to/mount/pointCheck data integrity (as usual, best used only in unmounted state):
# fsck.ext3 /dev/mapper/sda2_cryptAnd even decrypt back if we don't want to use encryption anymore:
# dd if=/dev/mapper/sda2_crypt of=/dev/sda2LUKS syntax
The above steps can be done according to the LUKS standard
We initialize the section:
cryptsetup luksFormat /dev/sda2We connect to the system:
cryptsetup luksOpen /dev/sda2 sda2_cryptFormatting:
mkfs.ext4 -v -L DATA /dev/mapper/sda2_cryptWe mount:
mount /dev/mapper/sda2_crypt /mnt/dataThe section can be manually disabled about the system
cryptsetup luksClose sda2_cryptConnection at startup
The file is used for this purpose. crypttab.
For our disk, write the following line into it:
nano /etc/crypttab # name mapper device key params/options # Standard syntax sda2_crypt /dev/sda2 none aes-cbc-plain:sha256 # and/or LUKS standard sda2_crypt /dev/sda2 none luksThe default is to encrypt with a password entered by the user. Thus, every time you boot your computer, the system will ask you every time for a password to connect each encrypted partition. Even if these sections are not registered in fstab.
If we want to mount manually, then add the option auto in the "Settings/Options" field.
Mounting an encrypted partition manually according to data from /etc/crypttab
cryptdisks_start msda2_cryptAnd shutdown with pre-mounted fs.
cryptdisks_stop sda2_cryptTo automatically mount the fs on the connected encrypted partition, add a line to /etc/fstab
/dev/mapper/sda2_crypt /mnt/data ext4 defaults 0 0Working with keys in LUKS
The LUKS section supports 8 different keys, each of which fits into its own slot.
View the list of used keys
cryptsetup luksDump /dev/sda22 types of keys can be used in LUKS - key phrases and files.
You can add a keyword
cryptsetup luksAddKey /dev/sda2You can add a key file (2048 bit) and set access rights to it.
dd if=/dev/urandom of=/root/ext2.key bs=512 count=4 cryptsetup luksAddKey /dev/sda2 /root/ext2.key chmod 400 /root/sda2.key cryptsetup -d /root/sda2.key luksOpen /dev/sda2 sda2_cryptTo connect at startup by key, edit /etc/crypttab
nano /etc/crypttab sda2_crypt /dev/sda2 /root/sda2.key luksYou can remove a passphrase or key from a section
cryptsetup luksKillSlot /dev/sda2 1Emergency mounting in a "foreign" distribution
No one is safe from problems and sometimes you need to access an encrypted partition from an emergency LiveCD disk.
We boot, connect the partition to the system and mount the fs:
cryptsetup luksOpen /dev/sda2 sda2_crypt mount -t ext4 /dev/mapper/sda2_crypt /mnt/backupAfter work, unmount the fs and disconnect the encrypted partition from the system
umount /mnt/backup cryptsetup luksClose sda2_cryptShutdown Error Messages
If the root partition is encrypted, then a message will be displayed upon shutdown
stopping early crypto disks... failedThis is a technical error. When shutting down, the file systems are always dismantled first, and only then the partition is dismounted. As a result, it turns out that the cryptsetup utility located on the root unmounted partition is no longer available for launch, which INIT tells us about. Without crutches, this problem cannot be solved, because. for this you need to consider options with transferring cryptsetup to a RAM disk
A similar situation develops when using software RAID containing the root partition. 8)
Encryption with the loop-aes module
Encryption of a hard drive partition, flash drive with a password
In this howto encryption method described AES256, other methods can be applied similarly (replacing the name of the method with the appropriate one). We will need the following packages:
# apt-get install loop-aes-utils loop-aes-modules-`uname -r`Note: if you are using a kernel for which the required loop-aes-modules is not in the repository, you can install the modules with the following commands:
# apt-get install module-assistant loop-aes-source # module-assistant a-i loop-aesFirst stage
On initial stage we are preparing the disk to work with it using encryption.
Let's select the partition of the disk (or flash drive) that we want to encrypt, for example it will be /dev/sda2. Let's enter the command:
# losetup -e AES256 -T /dev/loop0 /dev/sda2After executing this command, all calls to the device /dev/loop0 will be encrypted and encrypted and redirected to the device /dev/sda2. Now we have both encrypted and unencrypted channels to the storage device. The data is encrypted using the password you specified when executing losetup.
Now we can, for example, format the device:
# mkfs.ext3 /dev/loop0We can mount it:
# mount /dev/loop0 /path/to/mountwe can disable encryption:
# losetup -d /dev/loop0and most importantly, we can encrypt the partition without data loss:
# dd if=/dev/sda2 of=/dev/loop0and also decrypt if we decide that encryption is not our method:
# dd if=/dev/loop0 of=/dev/sda2Well, the best part is, we can do file system integrity checks:
# fsck.ext3 /dev/loop0This feature is not available in all partition encryption methods.
Everyday use
If you already had a section entry /dev/sda2 in your /etc/fstab, then you just need to add options, and if not, then write something like this:
/dev/sda2 /path/to/mount ext3 loop,encryption=AES256 0 0Now, when you boot the operating system, you will be prompted for a password to mount.
If you do not want the download process to be interrupted by a password request, then you can add options auto,user on record /etc/fstab:
/dev/sda2 /path/to/mount ext3 loop,encryption=AES256,noauto,user 0 0Of course, you can mount manually (or from a script):
# mount /dev/sda2 /path/to/mount -o loop,encryption=AES256Mounting multiple file systems
Sometimes you want to encrypt several sections with data at the same time, but so as not to enter a sea of passwords for each mount. For example, you have a flash drive that you carry from home to work, a portable hard drive, etc. Or just a few partitions / hard drives.
Let's say we have an encrypted partition /dev/sda2, which we mount to the directory every time we boot /mnt1. A new hard drive has arrived /dev/sdb1 and we want it to be automatically mounted to the directory mnt2 when mounting the first one. You can of course create common system on something like LVM, however, more simple way go:
prescribe in fstab like the following line:
/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0The system, on boot, mounts the points in the same order as described in fstab, so if the first partition is not mounted, then the key to mount the second partition will remain unavailable and the second partition will also not be mounted.
The password is stored as plain/text this is certainly not very beautiful, but it is stored on an encrypted partition (which can be unmounted). You can use instead gpg-key, however, this will not add much security (if they can already steal the key, then it will not make much difference what this key will be), encryption option with gpg-key described in man losetup, here I will only give an example of recording in fstab:
/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0Notes
For more information on supported encryption algorithms, see man losetup, you can also see a description of other program options losetup.
If you have problems installing AES modules, then read the documentation that comes with the package loop-aes-source.
GRUB and encrypted root disk
When installing a root partition on an encrypted disk, GRUB may show bugs in the main menu. This happens because the standard font /usr/share/grub/unicode.pf2 is not available. Copying the Font
cp /usr/share/grub/unicode.pf2 /boot/grub/Specify the setting
nano /etc/default/grub GRUB_FONT=/boot/grub/unicode.pf2Applying the setting:
update-grubEach of us stores a fair amount of confidential information on our hard drive. For some, these are just passwords for various network services, others are responsible for storing important documentation, and still others have been developing an innovative program for several years. In any case, the data must be protected from outsiders, which is in our mobile world quite problematic to do without the use of encryption systems.
Taking a look at the list of encryption software for Linux and analyzing the popularity and relevance of each of them, we conclude that there are only four secure and supported cryptosystems for encrypting hard drives and other storage media on the fly:
WARNING
For security reasons, indexing of encrypted partitions is best disabled by editing configuration file/etc/updatedb.conf. Files encrypted with EncFS cannot have hard links, because the encryption system binds data not to an inode, but to a file name.
Do you want to hide your data from prying eyes? We will teach you how to encrypt your hard drive.
Over the past year, the topic of Internet data security has come up frequently: first in connection with Snowden's revelations, then with a vulnerability in OpenSSL (Heartbleed bug). Shortly before the last one, a less noticeable bug was discovered in GnuTLS. As a result, we began to pay more attention to the security of remote data; but what about those that are stored on our disk?
Stack of block devices
Before considering encryption, it is important to understand how block devices work. They are system interfaces for storage devices like /dev/sda! Inside the block device is a hardware driver, such as SATA, and the actual hardware. Then operating system interacts with a block device to create a file system on it.
Block devices are usually considered in this capacity, although they have other functions. In particular, such a device can be an interface for a number of other block devices - they can form a stack. And you've already done this: you have a filesystem on /dev/sda1 (the disk partition), and this block device points to /dev/sda (the entire disk).
Technologies such as RAID and LVM (Logical Volume Management) are also stacks of block devices. You can have LVM on top RAID array, which, in turn, is also located on block devices of individual disks or their partitions.
Whole-device encryption with dm-crypt works like this: it creates a block device based on your storage medium, which encrypts data when stored and decrypts when read. You then mount a standard filesystem on top of the encrypted device and it functions just like it would on a normal disk partition.
Many distributions can be installed on an encrypted disk, but we will look at the creation and operation of dm-crypt devices directly, without touching the black magic that the installer does. Dm-crypt uses a kernel subsystem to map devices to control block devices with kernel cryptographic functions for encryption purposes.
Everything is done at the expense of the kernel, but at the user level, we need software to create and manage dm-crypt devices; cryptsetup is such a standard tool. It's probably already installed on your distribution; and if not, it will certainly be in the main repositories.
Encryption
The default values are usually more than enough, and all available options can be viewed with cryptsetup -help These options are only needed with LuksFormat. When creating a secure device, cryptsetup automatically uses correct settings to open it.
It's best to stick with popular ciphers and hashes unless you have a better reason to choose something else. Less commonly used methods may have hidden flaws, simply because they are less tested, which is what happened recently with the Whirlpool hash implementation in the libcgrypt library used by cryptsetup. When making corrections, those systems where the defective hashes were already used were affected.
Another reason to stick to conventional methods is portability. This is not important for an internal disk, but if you want to use an encrypted disk on another system, the same hashes and ciphers must also be set there.
LUKS
LUKS- Linux Unified Key Setup was created to provide a standard, cross-platform (despite the name) format for storing encrypted data on disks. It does not concern encryption methods, but the way information about them is stored.
It is also a more secure way to store keys or passwords, as the dm-crypt method is susceptible to hacking. Since LUKS is cross-platform, encrypted devices can also be accessed from Windows using .
