FASSAG Wiki - User contributions [en]

Glossary

2026-07-08T04:17:14Z

CRYSTL:

Since putting definitions of words in any relevant article is both unnecessary clutter and also very redundant, this page is intended to be a catch all for any term that needs further explanation, but there is not enough written about it for its own page. If an entry in the glossary is becoming too complex, consider creating its own page, and linking to it from here. Don't remove it from here until you have confirmed that nothing else links to it.

=== Security ===
While security is a very broad concept that has [[wikipedia:Security|many definitions]], in the concept of software, it mainly refers to ensuring someone cannot interact with your devices in a way that you do not want. For example, running software on your computer without permission. Security is most useful when thought of through the lens of [[Glossary#Threat modelling|threat modelling.]]

=== Threat Modelling ===
Threat modelling is the process of planning out how someone might interact with your device in a way that you do not want, and making a plan to prevent it. For example, if you do not want someone to be able to take your laptop apart and read your files off of your [[Glossary#Drive|drive]], you could encrypt it. It's important to understand what exactly you are concerned about, instead of just trying to "be secure."

=== Drive ===
A drive, or sometimes disk, is a device that contains data, for long periods of time. This is different from RAM, which only stores memory temporarily. The main tradeoff being that reading and writing to a drive is much slower than RAM. Drives can come in many forms, such as [[Glossary#SSD|SSD]], [[Glossary#HDD|HDD]], [[Glossary#(e)MMC|eMMC]], etc. The term drive can be a bit confusing though, as drives used to refer to devices with removable media, like [[Glossary#CD|CD]], [[Glossary#Floppy Disk|Floppy]], and even old Hard Disks. In present day though, drives rarely have removable media. The media itself cannot be read or interacted with without the hardware to ''drive'' it, which is why it is called a drive.

=== RAM ===
Random Access Memory, often just called "memory" is a device that contains data ''only'' while it is powered, but can be read from and written to very quickly. It is very important to note that RAM is intended ''temporary'' working memory, which is critical for a [[Glossary#CPU|CPU]] to function.

=== CPU ===
Central Processing Unit is an [[Glossary#IC|IC]] that performs the majority of the processing or "thinking" operations for the computer. CPUs take in instructions, and then refer to a list for what each instruction should do, and then perform that action. For example, if the CPU receives an instruction telling it to copy some data, it will do so! The list of instructions is called the Instruction Set Architecture (ISA).

=== IC ===
Integrated Circuit, or sometimes "chip", is an electronic ''circuit'', ''integrated'' into a single piece of silicon. The advantages of ICs is that they can operate much faster, use much less electricity for the same operations, and be much more durable than a larger more fragile board with components attached to it.

=== Circuit ===
Circuits, specifically electronic circuits, are the most basic concept that defines a computer. Circuits fundamentally are just electricity flowing and being directed through various components so that they can do useful things. Like a circuit starting at a battery, passing through a motor to turn a fan, and then returning to the battery. Computers use circuits to direct electricity to various components so that they can do useful things for us!

=== SSD ===
Solid State Drives are drives which have no moving parts. These drives instead of having disks, have flash chips on a board that contain the data. There are a few different types of flash chip, but most commonly [[Glossary#NAND|NAND]] is used. SSDs are usually removable from the device, and can be upgraded as needed, though some devices do have their SSD [[Glossary#Soldering|soldered]] to the motherboard. SSDs are usually either SATA or NVME, with NVME offering faster speeds, but usually at a higher price.

=== HDD ===
Hard Disk Drives are [[Glossary#Drive|drives]] which contain a spinning metal disk that can be magnetized. Depending on how the disk is magnetized, it stores a corresponding 1 or 0 bit. Very old hard drives, for example for the Centurion computer, had removable disks, or "platters".

=== NAND ===
{{Draft}}

=== (e)MMC ===
(Embedded) [[Glossary#Multi-Media|Multi-Media]] Card is a standard of flash chip typically used in products like SD cards. Though some cheaper smartphones and laptops do also used them. Compared to SSDs, they are usually much slower, though they are usually faster than HDDs. The main advantage is that they are quite cheap when compared to more expensive SSD storage.

=== CD ===
{{Draft}}

=== Floppy Disk ===
Floppy Disks, or sometimes "Floppies", are an older form of storage disk named after their ability to bend. Compared to modern drives, floppies were extremely small, only being able to store a few [[Glossary#Bytes|MB]] of data.

=== NVME ===
Non-Volatile Memory Express
{{Draft}}

=== SATA ===
{{Draft}}

=== Bytes ===
Bytes are the most common way to count data. Bytes are made of 8 [[Glossary#Bits|bits]]. Bytes are often abbreviated using the metric system, such as Kilobyte (KB), Megabyte (MB), Gigabyte (GB), etc. Which represent a thousand bytes, a million bytes, and a billion bytes, respectively. ( Need to talk about like Mibibytes )
{{Draft}}

=== Bits ===
{{Draft}}

=== Data ===
{{Draft}}

=== Multi-Media ===
Multi-Media is a term commonly used to describe a type of data storage that can contain any type of data. Older storage media sometimes only allowed for one type of media, though really, this was not very common, and most media was multi-media. CDs and DVDs for example, could be formatted either to contain music, or to contain arbitrary files, making them Multi-Media.

=== Soldering ===
Soldering is the process of connecting metal pieces together with a metal that melts at lower temperatures, like lead. Though lead is not used much anymore, as it is toxic, and usually low-temperature alloys are used instead. The main disadvantage of soldering is that it is very difficult for an inexperienced user to remove a soldered component. A soldered SSD for example, would be exceptionally difficult for a typical user to replace, and is generally done to make the device impossible to repair and upgrade.

Glossary

2026-07-08T02:18:34Z

CRYSTL: revisions

Since putting definitions of words in any relevant article is both unnecessary clutter and also very redundant, this page is intended to be a catch all for any term that needs further explanation, but there is not enough written about it for its own page. If an entry in the glossary is becoming too complex, consider creating its own page, and linking to it from here. Don't remove it from here until you have confirmed that nothing else links to it.

=== Security ===
While security is a very broad concept that has [[wikipedia:Security|many definitions]], in the concept of software, it mainly refers to ensuring someone cannot interact with your devices in a way that you do not want. For example, running software on your computer without permission. Security is most useful when thought of through the lens of [[Glossary#Threat modelling|threat modelling.]]

=== Threat Modelling ===
Threat modelling is the process of planning out how someone might interact with your device in a way that you do not want, and making a plan to prevent it. For example, if you do not want someone to be able to take your laptop apart and read your files off of your [[Glossary#Drive|drive]], you could encrypt it. It's important to understand what exactly you are concerned about, instead of just trying to "be secure."

=== Drive ===
A drive, or sometimes disk, is a device that contains data, for long periods of time. This is different from RAM, which only stores memory temporarily. The main tradeoff being that reading and writing to a drive is much slower than RAM. Drives can come in many forms, such as [[Glossary#SSD|SSD]], [[Glossary#HDD|HDD]], [[Glossary#(e)MMC|eMMC]], etc. The term drive can be a bit confusing though, as drives used to refer to devices with removable media, like [[Glossary#CD|CD]], [[Glossary#Floppy Disk|Floppy]], and even old Hard Disks. In present day though, drives rarely have removable media. The media itself cannot be read or interacted without without the hardware to ''drive'' it, which is why it was called a drive.

=== RAM ===
Random Access Memory, often just called "memory" is a device that contains data ''only'' while it is powered, but can be read from and written to very quickly. It is very important to note that RAM is intended ''temporary'' working memory, which is critical for a [[Glossary#CPU|CPU]] to function.

=== CPU ===
Central Processing Unit is an [[Glossary#IC|IC]] that performs the majority of the processing or "thinking" operations for the computer. CPUs take in instructions, and then refer to a list for what each instruction should do, and then perform that action. For example, if the CPU receives an instruction telling it to copy some data, it will do so! The list of instructions is called the Instruction Set Architecture (ISA).

=== IC ===
Integrated Circuit, or sometimes "chip", is an electronic ''circuit'', ''integrated'' into a single piece of silicon. The advantages of ICs is that they can operate much faster, use much less electricity for the same operations, and be much more durable than a larger more fragile board with components attached to it.

=== Circuit ===
Circuits, specifically electronic circuits, are the most basic concept that defines a computer. Circuits fundamentally are just electricity flowing and being directed through various components so that they can do useful things. Like a circuit starting at a battery, passing through a motor to turn a fan, and then returning to the battery. Computers use circuits to direct electricity to various components so that they can do useful things for us!

=== SSD ===
Solid State Drives are drives which have no moving parts. These drives instead of having disks, have flash chips on a board that contain the data. There are a few different types of flash chip, but most commonly [[Glossary#NAND|NAND]] is used. SSDs are usually removable from the device, and can be upgraded as needed, though some devices do have their SSD [[Glossary#Soldering|soldered]] to the motherboard. SSDs are usually either SATA or NVME, with NVME offering faster speeds, but usually at a higher price.

=== HDD ===
Hard Disk Drives are [[Glossary#Drive|drives]] which contain a spinning metal disk that can be magnetized. Depending on how the disk is magnetized, it stores a corresponding 1 or 0 bit. Very old hard drives, for example for the Centurion computer, had removable disks, or "platters".

=== NAND ===
{{Draft}}

=== (e)MMC ===
(Embedded) [[Glossary#Multi-Media|Multi-Media]] Card is a standard of flash chip typically used in products like SD cards. Though some cheaper smartphones and laptops do also used them. Compared to SSDs, they are usually much slower, though they are usually faster than HDDs. The main advantage is that they are quite cheap when compared to more expensive SSD storage.

=== CD ===
{{Draft}}

=== Floppy Disk ===
Floppy Disks, or sometimes "Floppies", are an older form of storage disk named after their ability to bend. Compared to modern drives, floppies were extremely small, only being able to store a few [[Glossary#Bytes|MB]] of data.

=== NVME ===
Non-Volatile Memory Express
{{Draft}}

=== SATA ===
{{Draft}}

=== Bytes ===
Bytes are the most common way to count data. Bytes are made of 8 [[Glossary#Bits|bits]]. Bytes are often abbreviated using the metric system, such as Kilobyte (KB), Megabyte (MB), Gigabyte (GB), etc. Which represent a thousand bytes, a million bytes, and a billion bytes, respectively. ( Need to talk about like Mibibytes )
{{Draft}}

=== Bits ===
{{Draft}}

=== Data ===
{{Draft}}

=== Multi-Media ===
Multi-Media is a term commonly used to describe a type of data storage that can contain any type of data. Older storage media sometimes only allowed for one type of media, though really, this was not very common, and most media was multi-media. CDs and DVDs for example, could be formatted either to contain music, or to contain arbitrary files, making them Multi-Media.

=== Soldering ===
Soldering is the process of connecting metal pieces together with a metal that melts at lower temperatures, like lead. Though lead is not used much anymore, as it is toxic, and usually low-temperature alloys are used instead. The main disadvantage of soldering is that it is very difficult for an inexperienced user to remove a soldered component. A soldered SSD for example, would be exceptionally difficult for a typical user to replace, and is generally done to make the device impossible to repair and upgrade.

LUKS

2026-07-08T01:00:43Z

CRYSTL:

{{Guide
| 0 = Intermediate
}}
Some external information that may also be helpful is the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

== Guide to Decent LUKS Security on Linux ==
LUKS is the [[Linux anatomy|Linux]] Unified Key Setup. This guide explains all of the different part of the LUKS system and why they are important for [[Glossary#Security|security]]. Check out the advanced guide if you want to know more about how to set these options and what they do in more detail.

=== Ciphers ===
Ciphers scramble the [[files]] that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

=== On-disk [[Format]] ===
The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for [[XTS]], it makes it the fastest and most secure option.

=== [[Initialization]] [[Vectors]] ( IV ) ===
By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, [[plain64]] is the fastest and most secure option.

=== [[Password]] [[Hashing]] ===
Password hashing helps make passwords that are not secure harder to break. A ''very'' secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. [[Argon2]] is the most secure option for most users.

=== [[Iteration]] Time ===
Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer!

== Disk Setup ==
Assuming you know what partition you want to use, setting up the disk is as simple as:

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously, these settings are the default on the latest cryptsetup (with the exception of <code>--use-random</code>). Setting them manually ensures that they are correct on older versions. You can check what the defaults are for your system by running <code>cryptsetup --help</code>. You can then verify that it was setup correctly with:

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup, it can be opened with:

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that "dm_name" can be set to whatever you like, and the disk will be available at:

<code>/dev/mapper/dm_name</code>

To [[format]] it, you can use the following:

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Glossary

2026-07-08T01:00:14Z

CRYSTL: added numerous entries to the glossary

Since putting definitions of words in any relevant article is both unnecessary clutter and also very redundant, this page is intended to be a catch all for any term that needs further explanation, but there is not enough written about it for its own page. If an entry in the glossary is becoming too complex, consider creating its own page, and linking to it from here. Don't remove it from here until you have confirmed that nothing else links to it.

=== Security ===
While security is a very broad concept that has [[wikipedia:Security|many definitions]], in the concept of software, it mainly refers to ensuring someone cannot interact with your devices in a way that you do not want. For example, running software on your computer without permission. Security is most useful when thought of through the lens of [[Glossary#Threat modelling|threat modelling.]]

=== Threat Modelling ===
Threat modelling is the process of planning out how someone might interact with your device in a way that you do not want, and making a plan to prevent it. For example, if you do not want someone to be able to take your laptop apart and read your files off of your [[Glossary#Drive|drive]], you could encrypt it. It's important to understand what exactly you are concerned about, instead of just trying to "be secure."

=== Drive ===
A drive, or sometimes disk, is a device that contains data, for long periods of time. This is different from RAM, which only stores memory temporarily. The main tradeoff being that reading and writing to a drive is much slower than RAM. Drives can come in many forms, such as [[Glossary#SSD|SSD]], [[Glossary#HDD|HDD]], [[Glossary#(e)MMC|eMMC]], etc. The term drive can be a bit confusing though, as drives used to refer to devices with removable media, like [[Glossary#CD|CD]], [[Glossary#Floppy Disk|Floppy]], and even old Hard Disks. In present day though, drives rarely have removable media.

=== RAM ===
Random Access Memory, often just called "memory" is a device that contains data while it is powered, but can be read from and written to very quickly. RAM is critical for a [[Glossary#CPU|CPU]] to function.

=== CPU ===
Central Processing Unit is an [[Glossary#IC|IC]] that performs the majority of the processing or "thinking" operations for the computer. CPUs take in [[Glossary#Bytes|bytes]], and then refer to a list of instructions for what each byte should do, and then perform that action. For example, if the CPU receives a byte telling it to copy some data, it will do so! The list of instructions is called the Instruction Set Architecture (ISA).

=== IC ===
Integrated Circuit, or sometimes "chip", is a complete electronic circuit, integrated into a single piece of silicon. The advantages of ICs is that they can operate much faster, use much less electricity for the same operations, and be much more durable than a larger more fragile board with components attached to it.

=== Circuit ===
Circuits, specifically electronic circuits, are the most basic concept that defines a computer. Circuits fundamentally are just electricity flowing and being directed through various components so that they can do useful things. Like a circuit starting at a battery, passing through a motor to turn a fan, and then returning to the battery. Computers use circuits to direct electricity to various components so that they can do useful things for us!

=== SSD ===
Solid State Drives are drives which have no moving parts. These drives instead of having disks, have flash chips on a board that contain the data. There are a few different types of flash chip, but most commonly [[Glossary#NAND|NAND]] is used. SSDs are usually removable from the device, and can be upgraded as needed, though some devices do have their SSD [[Glossary#Soldering|soldered]] to the motherboard. SSDs are usually either SATA or NVME, with NVME offering faster speeds, but usually at a higher price.

=== HDD ===
Hard Disk Drives are [[Glossary#Drive|drives]] which contain a spinning metal disk that can be magnetized. Depending on how the disk is magnetized, it will send out a corresponding 1 or 0 bit. Very old hard drives, for example for the Centurion computer, had removable disks, or "platters", which is why it was called a drive. Even though this fairly quickly stopped being the case, the name has stuck around, and now many storage devices are called drives.

=== NAND ===
{{Draft}}

=== (e)MMC ===
(Embedded) [[Glossary#Multi-Media|Multi-Media]] Card is a standard of flash chip typically used in products like SD cards. Though some cheaper smartphones and laptops do also used them. Compared to SSDs, they are usually much slower, though they are usually faster than HDDs. The main advantage is that they are quite cheap when compared to more expensive SSD storage.

=== CD ===
{{Draft}}

=== Floppy Disk ===
Floppy Disks, or sometimes "Floppies", are an older form of storage disk named after their ability to bend. Compared to modern drives, floppies were extremely small, only being able to store a few [[Glossary#Bytes|MB]] of data.

=== NVME ===
Non-Volatile Memory Express
{{Draft}}

=== SATA ===
{{Draft}}

=== Bytes ===
Bytes are the most common way to count data. Bytes are made of 8 [[Glossary#Bits|bits]]. Bytes are often abbreviated using the metric system, such as Kilobyte (KB), Megabyte (MB), Gigabyte (GB), etc. Which represent a thousand bytes, a million bytes, and a billion bytes, respectively. ( Need to talk about like Mibibytes )
{{Draft}}

=== Bits ===
{{Draft}}

=== Data ===
{{Draft}}

=== Multi-Media ===
Multi-Media is a term commonly used to describe a type of data storage that can contain any type of data. Older storage media sometimes only allowed for one type of media, though really, this was not very common, and most media was multi-media. CDs and DVDs for example, could be formatted either to contain music, or to contain arbitrary files, making them Multi-Media.

=== Soldering ===
Soldering is the process of connecting metal pieces together with a metal that melts at lower temperatures, like lead. Though lead is not used much anymore, as it is toxic, and usually low-temperature alloys are used instead. The main disadvantage of soldering is that it is very difficult for an inexperienced user to remove a soldered component. A soldered SSD for example, would be exceptionally difficult for a typical user to replace, and is generally done to make the device impossible to repair and upgrade.

2026-07-01T01:21:27Z

CRYSTL: remove draft tempalte

LUKS/Advanced

2026-07-01T01:20:11Z

CRYSTL: reworked this page

{{Draft}}{{Guide
| 0 = Advanced
}}For more more info on this topic, check the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ], the [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

= Guide to Decent LUKS Security on Linux =
The Intermediate Guide gives a high level overview of what different LUKS options can do, but this page intends to go into as much detail as possible about them while still aiming to be easy to understand. If you just want to know the "best" [[command]] to run, you can skip to the bottom. But reading this Guide is encouraged, as it will give you a better understand of what the options do, and how they will affect the security of your data!

== Ciphers ==
Ciphers are the [[algorithms]] used to [[Encryption|encrypt]] [[data]]. Picking the best algorithm is very important for ensuring your data is secure. If your cipher can be broken, then your data can be accessed without the key.

Of the widely supported options, the two most worth considering are [[Serpent]] and [[AES]].

[[Twofish]] ''may'' be better in lower-security applications where there's no AES acceleration ''and'' writes happen more often than reads, but generally, not a great option.

Serpent may theoretically be more secure, though in practice its potential advantages seem pretty minimal. It also hasn't been tested as much as AES, so it ''may'' have potential vulnerabilities not yet known about .

Another consideration is the actual [[implementation]]. Serpent has potential [[Vulnerability|vulnerabilities]] depending on the details of the implementation. Without looking into the specific implementation in-depth, it's hard to say how secure it is.

On the other hand, having [[hardware acceleration]] for AES has a number of advantages for security, most notably resistance to [[Side-channel attack|side-channel attacks]], but of course also speed. Some [[CPU|CPUs]] however, usually CPUs that aren't x86 based, do not have hardware accelerated AES. While it's theoretically possible that your CPU may have a vulnerability, as far as we are aware, no vulnerabilities have been reported on any present or past chip with AES support. Make sure your [[microcode]] is up to date! Practically speaking, the advantages of having hardware accelerated AES make it more secure than using Serpent in nearly all cases.

== On-disk Format ==
The on-disk format defines how the encrypted data is stored on the disk itself . While you ''could'' just write the encrypted blocks directly to the disk , you would be at risk of a number of different attacks. [[CBC]] is an older on-disk format and should not really be used. It has [[malleability]] vulnerabilities, and also, specially-crafted files can be [[fingerprinted]]. XTS is better at mitigating these issues, so it's the recommended default. It's also hardware accelerated on modern x86 CPUs. If your CPU does not have hardware accelerated AES and XTS, you ''may'' want to use CBC, for better speeds.

== Initialization Vectors ( IV ) ==
The purpose of IV is to add some randomness different blocks of the disk, so that overall patterns cannot be discovered. [[ESSIV]] was previously set as default for CBC to mitigate the fingerprinting issue, but this does not help CBC's issues with malleability. Since XTS has been used, plain64 has been the default. Since XTS is not vulnerable to fingerprinting, it does not need the added overhead of ESSIV.

== Password Hashing ==
The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing. Since it's hard to make ( and remember ) a very secure password, it's still a good idea to hash your password.

The best option is generally Argon2, since it is optimized to be impossible to [[Brute-force attack|brute-force]] on devices with limited memory, like [[GPU|GPUs]]. The point is to force the attacker to use their CPU, which is not usually not nearly as quick as a GPU for this kind of task. Unless you're primarily concerned about some [[Advanced Persistent Threat|APT]] trying to decrypt your data, it is a pretty good tradeoff.

Argon2 has a few different variants. Argon2i is weakest to brute-forcing, but has strong side-channel protection. It's generally not safe to use 2i with anything less than 10 iterations. Similarly, while Argon2d is most secure against brute-force attacks, it is more susceptible to side-channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice.

If your device is very memory constrained (like under 4GB), you ''may'' want to consider using PBKDF2 instead. You will want to increase the iteration time as high as you can tolerate, as it is far weaker to GPU brute-forcing.

== Iteration Time ==
This defines how long your computer is going to spend hashing the password. More iteration is better, and it's just a question of how long you are willing to spend waiting for your computer to has your password. If your password is very insecure though, a long has will not slow down an attacker much. 2 seconds ( 2000ms ) is the recommended default. Make sure your computer is not set to any "low-power mode" when setting up the disk, as this will affect the time it takes to hash.

See the [[Password]] Guide for more information about making a secure password.

== Benchmarking ==
If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark</code>.
<code># Tests are approximate using memory only (no storage IO).</code>
<code>PBKDF2-sha1 1736052 iterations per second for 256-bit key</code>
<code>PBKDF2-sha256 3355443 iterations per second for 256-bit key</code>
<code>PBKDF2-sha512 1096836 iterations per second for 256-bit key</code>
<code>PBKDF2-ripemd160 434733 iterations per second for 256-bit key</code>
<code>PBKDF2-whirlpool 364088 iterations per second for 256-bit key</code>
<code>argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)</code>
<code>argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)</code>
<code> Algorithm | Key | Encryption | Decryption</code>[[entropy]]
<code> aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s</code>
<code> serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s</code>
<code> twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s</code>
<code> aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s</code>
<code> serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s</code>
<code> twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s</code>
<code> aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s</code>
<code> serpent-xts 256b 445.6 MiB/s 401.0 MiB/s</code>
<code> twofish-xts 256b 220.3 MiB/s 236.9 MiB/s</code>
<code> aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s</code>
<code> serpent-xts 512b 445.2 MiB/s 437.6 MiB/s</code>
<code> twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</code>
As you can see from this sample output, <code>aes-xts</code> is the fastest! Assuming you're on an x86 machine, this will almost certainly also be the case for you. You'll also notice Argon2i only has 4 iterations here, making it unsafe to use. You can add <code>-i 5000</code> to test 5000ms as an example, to see how many iterations it achieves.

== [[Entropy]] ==
Though unlikely, to avoid an [[Entropy Starvation|entropy starved]] situation, you can use <code>--use-random</code> when setting up the disk.

There's a lot of debate and conflicting information online about the difference between <code>/dev/random</code> and <code>/dev/urandom</code> online. The main difference is that <code>/dev/random</code> will wait until it detects enough entropy has been gathered. Since it only affects when you initially setup the disk though, waiting for it to gather enough entropy is generally a good idea. Whether its method of ensuring it has gathered enough data is effective, is also somewhat debated, but it certainly doesn't hurt.

An easy way to ensure you have enough entropy, is to gather it from an external source. For example, you can run: <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>. This command gathers random bytes from [https://random.org random.org]. Using an external source like this is ok, since Linux has ways to gather entropy besides this that an attacker would not be able to replicate.

== Disk Setup ==
Assuming you know what partition you want to use, setting up the disk is as simple as:

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously, these settings are the default on the latest cryptsetup (with the exception of <code>--use-random</code>). Setting them manually ensures that they are correct on older versions. You can check what the defaults are for your system by running <code>cryptsetup --help</code>. You can then verify that it was setup correctly with:

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup, it can be opened with:

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that "dm_name" can be set to whatever you like, and the disk will be available at:

<code>/dev/mapper/dm_name</code>

Then you will need to format it, via something like:

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Linux anatomy

2026-07-01T01:17:40Z

CRYSTL: typo

{{Draft}}{{Guide
| 0 = Novice
}}

This guide introduces a novice Linux user to common terms used to describe various common parts of the core functionality of a typical Linux computer. Maybe you've heard about a "kernel" and want to know what it is, or perhaps you are curious why there are so many different types of Linux you can install.

We only assume some very basic familiarity to computers and operating systems in this guide--if you can install and run programs and you know that Linux and Windows are operating systems, you should be able to follow it.

== Linux ==
"Linux" is a term that has a few meanings, and sometimes you will see debates online (often jokingly) about what part of the software actually counts as Linux. Though some pedants might take issue with this, in this guide we will be using the term "Linux" to refer to '''an entire system''' that runs software on top of the Linux Kernel.

The basic gist is that Linux is a set of programs and utilities, as well as a core program called a "kernel", that work together to create a system which can be used for many different purposes, and be customized in many ways. Keep reading to gain a better understanding of how these pieces all fit together.

== Distribution ==
When you are deciding how to install Linux, one of the first considerations you may want to make is selecting a Linux Distribution (often abbreviated as "distro"). There are an incredible variety of Linux distributions out there, and different folks may recommend different distributions depending on your needs and taste.

But what exactly is a distribution in the first place? Why is this so different from how Windows works, where there are just a few "editions" which you have to pick? And why can't you just go to a single website and install "Normal Linux"?

In short, this is because, unlike macOS or Windows, there is no singular company or organization working on Linux as a whole. The Linux Kernel is worked on by a single large team of dedicated volunteers, but they have enough on their hands with just those responsibilities. And, for reasons that will be explained, it is impossible to have a usable system (especially a desktop system) with only a kernel.

So instead, many groups of volunteers have created their own organizations which do the important work of packaging together all the necessary components and building up a usable system on top of the Kernel. Distributions have the job of deciding on a ''package manager'', ''desktop environment'', ''init system'', ''windowing system'', ''compositor'', and more. They also usually come up with a unique look and branding for their distribution, and unique features that might set their distribution apart from their peers. When they do their job well, everything comes together seamlessly to create a cohesive and usable experience that gives a user the particular features they want.

=== Fixed-release ===
Some distros prioritize stability, which means that they are very careful about what versions of software are included, and they test the systems for bugs very carefully before upgrading them. These distributions usually release entire new versions of their desktop environments on a cadence, every 6 months or every year, in what is called a "Fixed release" schedule. This can be undesirable for some users, as they may become frustrated that newer software or features are not available yet on their distribution.

=== Rolling-release ===
Other distros prioritize new features, which means they give you access to the latest and greatest features and software. However, such distributions can sometimes have more bugs, crashes, or other glitches, because there is usually less time for the creators of the distribution to test the software they are showing. These distros are often "Rolling release", which just means that they do not release a single version every 6 months, but instead update single pieces of software as new updates come in and they appear to be stable.

=== Power-user distros ===
Many distributions are designed for power users. They might be minimal, requiring a lot of manual customization and setup, but allowing for a system to be built that is exactly how the user wants it to be. Or perhaps they have the goal of being as free of [[Proprietary|proprietary software]] as possible.

=== Beyond ===
There are also distributions which focus on creating an environment that is as close to the experience of using Windows as possible, in order to make it easier for Linux beginners to use comfortably. Distributions may also advertise themselves as being ideal for gaming, security research, or for use by lower-power machines. Whatever your needs, there is probably a Linux distribution for you.

Just a few examples of Linux distributions include [https://www.linuxmint.com/ Linux Mint], [https://ubuntu.com/desktop Ubuntu], [https://www.debian.org/ Debian], and [https://www.gentoo.org/ Gentoo]. Wikipedia has a [[wikipedia:List_of_Linux_distributions|helpful list]] of many more.

== Software vs. libraries ==

=== Software ===
As you likely know, a piece of software is any sort of application or tool that runs on the computer. A very general term, this might refer to a tiny tool that simply tells you the time, and it also might refer to the web browser that you're using right now. What differentiates software from libraries is the ability to ''run''.

=== Libraries ===
A library is a piece of functionality that can be used by software, to give it the ability to do something useful. You don't use libraries directly; instead, a program you use makes use of it.

Linux software uses many thousands of libraries, and many pieces of software may rely on one single library for functionality. Libraries rely on other libraries, as well! On your computer, there's a whole graph of ''dependencies'' putting software together, like puzzle pieces.

Libraries are always changing, and mismatches across software can arise when a change is made. This is where package managers become incredibly useful.

== Package manager ==
The idea behind a package manager is very simple, and it's likely you've encountered one before. The macOS and iOS App Stores, and the Windows Store are examples of package managers created by Apple and Microsoft. However, many apps on these stores are paid, whereas Linux package managers are almost always entirely free.

The main purpose of a package manager is obtaining and organizing versions of libraries and software, and making sure that all the puzzle pieces fit together without overlapping in a bad way. These software and libraries are provided in the form of ''packages'', which are basically tidy containers of installers that tell the system what needs to happen to get your program running.

A Linux distribution generally provides one (or sometimes two) package managers. These package managers usually have a ''repository'' which is a collection of software you might want to install. Usually, the distribution will provide a simple graphical application (often called a "Software Center" or Store) for updating your software and installing new software from the repository, and you don't need to worry about the details of the package manager at all. You should always check the Software Center provided by your distribution first when looking for new software to install, because this is almost always the easiest way to install it and keep it updated.

It is still useful to know what sort of package manager your distribution uses though, especially when you want to install new software from the internet that isn't available in the repository. Each package manager has its own way of installing software, so if you download a program it might not be installable on your system. In this way, Linux is different from Windows, where you can click on an .exe installer, or macOS, where you can drag a new program to the Applications folder. But luckily, the package manager often has everything you need, and you don't need to go onto web pages to install random things from the Internet!

Knowing what is available to install on your system gives you power. And if you want to become a more advanced user it may be useful to familiarize yourself with how to use your package manager from the [[terminal]].

== Desktop environment ==
The Desktop Environment, or DE for short, is a set of programs that shape how your experience works. Different DEs can radically change how programs are launched and switched, and displayed on the screen.

Docks, desktops, taskbars, app launchers, settings pages, file managers, and often software updaters are provided by the Desktop Environment. Different environments are suitable for different purposes.

The average user will likely find the choice of DE to be the single most impactful choice in terms of defining an experience of using the computer, because it shapes the look and feel of the desktop the most. Indeed, the biggest visual differences between Windows and macOS (the Dock/Taskbar, File Explorer/Finder, preferences panels, and more) have Linux equivalents determined by the DE.

Some desktop environments, like [https://www.gnome.org/ GNOME], focus on a straightforward singular experience with less customization options and certain consistent design patterns. These environments are sometimes less confusing, because you are forced into a common path which is encountered by more people, and so it'll be easier to compare your desktop with others when trying to figure out how to do something. Some users find the consistent interface to be more pleasing to the eye, as well (but this is very much a matter of individual taste).

Other desktop environments, like [https://kde.org/ KDE], are all about offering as much customization as possible, and creating exactly the desktop you want. These can sometimes be confusing for newer users, if they change options that cause their system to do something they didn't expect, and don't know how to change it back.

There are even more environments which prioritize absolute customization, or allow for all sorts of exotic setups. Ultimately, what DE you choose comes down to what level of expertise you are comfortable with, and where your priorities lie when using an operating system.

== Kernel ==

== Kernelspace and userspace ==

== Init system ==

== Windowing system ==

== Compositor ==

LUKS

2026-07-01T00:45:28Z

CRYSTL: /* On-disk Format */

{{Draft}}{{Guide
| 0 = Intermediate
}}
Some external information that may also be helpful is the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

== Guide to Decent LUKS [[Security]] on [[Linux]] ==
LUKS is the Linux Unified Key Setup. This guide explains all of the different part of the LUKS system and why they are important. Check out the advanced guide if you want to know more about how to set these options and what they do in more detail.

== Ciphers ==
Ciphers scramble the [[files]] that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

== On-disk [[Format]] ==
The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for [[XTS]], it makes it the fastest and most secure option.

== [[Initialization]] [[Vectors]] ( IV ) ==
By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, [[plain64]] is the fastest and most secure option.

== [[Password]] [[Hashing]] ==
Password hashing helps make passwords that are not secure harder to break. A ''very'' secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. [[Argon2]] is the most secure option for most users.

== [[Iteration]] Time ==
Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer!

LUKS

2026-07-01T00:17:55Z

CRYSTL: glossary

{{Draft}}{{Guide
| 0 = Intermediate
}}
Some external information that may also be helpful is the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

== Guide to Decent LUKS [[Security]] on [[Linux]] ==
LUKS is the Linux Unified Key Setup. This guide explains all of the different part of the LUKS system and why they are important. Check out the advanced guide if you want to know more about how to set these options and what they do in more detail.

== Ciphers ==
Ciphers scramble the [[files]] that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

== On-[[disk]] [[Format]] ==
The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for [[XTS]], it makes it the fastest and most secure option.

== [[Initialization]] [[Vectors]] ( IV ) ==
By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, [[plain64]] is the fastest and most secure option.

== [[Password]] [[Hashing]] ==
Password hashing helps make passwords that are not secure harder to break. A ''very'' secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. [[Argon2]] is the most secure option for most users.

== [[Iteration]] Time ==
Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer!

LUKS

2026-07-01T00:15:02Z

CRYSTL: mark some words as needing entry to glossary

LUKS

2026-06-17T08:06:26Z

CRYSTL: change from title to heading so the page isn't hidden on mobile

{{Draft}}{{Guide
| 0 = Intermediate
}}
Some external information that may also be helpful is the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

== Guide to Decent LUKS [[Security]] on [[Linux]] ==
LUKS is the Linux Unified Key Setup. This guide explains all of the different part of the LUKS system and why they are important. Check out the advanced guide if you want to know more about how to set these options and what they do in more detail.

== Ciphers ==
Ciphers scramble the [[files]] that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

== On-disk Format ==
The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for [[XTS]], it makes it the fastest and most secure option.

== Initialization Vectors ( IV ) ==
By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, [[plain64]] is the fastest and most secure option.

== [[Password]] [[Hashing]] ==
Password hashing helps make passwords that are not secure harder to break. A ''very'' secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. [[Argon2]] is the most secure option for most users.

== Iteration Time ==
Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer!

LUKS/Advanced

2026-06-17T02:57:15Z

CRYSTL: finish copying over data from the intermediate page . this page still needs a lot of cleanup and addition though .

{{Draft}}{{Guide
| 0 = advanced
}}For more more info on this topic, check the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ], the [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

= Guide to Decent LUKS Security on Linux =
The Main Page gives a high level overview of what different LUKS options can do, but this page intends to go into as much detail as possible about them while still aiming to be easy to understand. If you just want to know the "best" [[command]] to run, you can skip to the bottom. But reading this Guide is encouraged, as it will give you a better understand of what the options do, and how they will affect the security of your data!

== Ciphers ==
Ciphers are the [[algorithms]] used to [[Encryption|encrypt]] [[data]]. Picking the best algorithm is very important for ensuring your data is secure. If your cipher can be broken, then your data can be accessed without the key.

Of the widely supported options, the two most worth considering are [[Serpent]] and [[AES]].

Twofish ''may'' be better in lower-security applications where there's no AES acceleration ''and'' writes happen more often than reads, but generally, not a great option.

Serpent may theoretically be more secure, though in practice its potential advantages seem pretty minimal. It also hasn't been tested as much as AES, so it ''may'' have potential vulnerabilities not yet known about .

Another consideration is the actual implementation. Serpent has potential vulnerabilities depending on the details of the implementation. Without looking into the specific implementation in-depth, it's hard to say how secure it is.

On the other hand, having hardware acceleration for AES has a number of advantages for security, most notably resistance to side channel attacks, and of course, speed. Some chips however, almost always not x86, do not have hardware accelerated AES. It's also possible that your CPU may have a vulnerability, so that's something you may want to look into. As far as we are aware though, no vulnerabilities have been reported on any present or past chip with AES support. Practically speaking, the advantages of having hardware accelerated AES make it more secure than using Serpent in nearly all cases.

== On-disk Format ==
The on-disk format defines how the encrypted data is stored on the disk itself . While you ''could'' just write the encrypted blocks directly to the disk , you would be at risk of a number of different attacks . CBC ( Cipher-block chaining ) is an older on-disk format and should not really be used . It has malleability vulnerabilities ( meaning data can be inserted without knowing the encryption key ) , and also , specially-crafted files can be " fingerprinted " , meaning they can be located on the disk . XTS ( XEX-based tweaked-codebook mode with ciphertext stealing ) is better at mitigating these issues , so it's the recommended default . It's also usually hardware accelerated on x86 . XTS does have its own vulnerabilities , but most of these issues can be mitigated by using a filesystem that can verify and repair corrupted data , like ZFS or BTRFS .

== Initialization Vectors ( IV ) ==
The purpose of IV is to ad some randomness different blocks of the disk , so that overall patterns cannot be discovered . ESSIV ( Encrypted salt-sector initialization vector ) was set as default for CBC to mitigate the fingerprinting issue , but this does not help CBC's issues with malleability . For XTS , plain64 is recommended over plain , since it has no performance impact , and plain has some data leaking vulnerabilities that are viable on disks larger than 2TiB . XTS not being vulnerable to fingerprinitng , does not need the added overhead of ESSIV .

== Password Hashing ==
The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing . Argon2 is optimized to be impossible to brute-force on devices with limited memory , most notably , graphics cards . The point is to force the attacker to use their CPU , which is not usually not nearly as quick as a GPU for this kind of task . Unless you're primarily concerned about some APT trying to break into your device , it is pretty good tradeoff . If your device is very memory constrained ( like under 4GB ), you ''may'' want to consider using PBKDF2 ( Password-Based Key Derivation Function ) . You will almost certainly want to increase the iteration time more though , as it is far weaker to GPU brute-forcing . For a small note on Argon2 , it has a few different variants . Argon2i is weakest to brute-forcing , but has strong side-channel protection . It's generally not safe to use 2i with anything less than 10 iterations . Conversely , while Argon2d is most secure against brute force attacks , it is more susceptible to side channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice .

== Iteration Time ==
This defines how long your computer is going to spend hashing the password . More iteration is generally better , and is mostly a question of how long you willing to spend waiting for your computer to initially decrypt the drive . Do note that it doesn't decrease the speed of the drive after the key is decrypted . To be very clear , high iteration count is not an alternative to a secure password ! 2 seconds ( 2000ms ) is generally the recommended default , though of course you are welcome to set it as high as you are willing to tolerate . Make sure your computer is not set to any " low-power mode " when setting up the disk , as this will affect the time it takes to hash .

Very important note ! Make sure your password is secure ! Using something short is a very bad idea . Using a string of characters from a well known book is also not a great idea ! Something like a diceware password with at least 6 words is generally a good idea !

== Benchmarking ==
If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark .</code>
<code># Tests are approximate using memory only (no storage IO).</code>
<code>PBKDF2-sha1 1736052 iterations per second for 256-bit key</code>
<code>PBKDF2-sha256 3355443 iterations per second for 256-bit key</code>
<code>PBKDF2-sha512 1096836 iterations per second for 256-bit key</code>
<code>PBKDF2-ripemd160 434733 iterations per second for 256-bit key</code>
<code>PBKDF2-whirlpool 364088 iterations per second for 256-bit key</code>
<code>argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)</code>
<code>argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)</code>
<code> Algorithm | Key | Encryption | Decryption</code>
<code> aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s</code>
<code> serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s</code>
<code> twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s</code>
<code> aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s</code>
<code> serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s</code>
<code> twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s</code>
<code> aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s</code>
<code> serpent-xts 256b 445.6 MiB/s 401.0 MiB/s</code>
<code> twofish-xts 256b 220.3 MiB/s 236.9 MiB/s</code>
<code> aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s</code>
<code> serpent-xts 512b 445.2 MiB/s 437.6 MiB/s</code>
<code> twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</code>
As you can see from this sample output , aes-xts is the fastest ! Assuming you're on an x86 machine , this will almost certainly also be the case for you . You'll also notice Argon2i only has 4 iterations here , making it unsafe to use . You can add <code>-i 5000</code> to test 5000ms as an example , to see how many iterations it achieves .

== /dev/urandom ==
Though unlikely , to avoid an entropy-starved situation ( meaning the random numbers are not random enough ) , you can use <code>--use-random</code> when setting up the disk .

There's apparently a lot of debate and conflicting information online about the difference between /dev/random and /dev/urandom online . The main difference is that /dev/random will wait when it estimates that not enough entropy has been gathered . Since it only affects when you initially setup the disk though , waiting for it to gather enough entropy is generally a good idea . Whether its method of ensuring it has gathered enough data is effective , is also somewhat debated , but it certainly doesn't hurt .

= Summary =
Unless you have a strong reason to doubt AES-256 ( which is also post-quantum resistant ) , AES should be used . Using CBC even with ESSIV does not have any compelling reasons for consideration , so XTS likely your best choice , especially since it will be significantly faster to encrypt / decrypt on x86 . These options are the default for good reason , and unless you have a particularly special setup or threat model ; like if for example , if your CPU does not have hardware accelerated AES , or if it had a known vulnerability . Lastly , Argon2id is generally your best option for hashing .

== Disk Setup ==
Assuming you know what partition you want to use, setting up the disk is as simple as :

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously , these settings are the default on the latest cryptsetup ( with the exception of --use-random ) , but setting them manually ensures that they are correct on older versions . You can also check what the defaults are for your system by running cryptsetup --help . You can then verify that it was setup correctly with :

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup , it can be opened with :

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that " dm_name " can be set to whatever you like , and the disk will be available at :

<code>/dev/mapper/dm_name</code>

Then you will need to format it , via something like :

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Of course , you'll want to replace mkfs.ext4 with the setup command for your preferred partition type .

LUKS

2026-06-17T02:53:32Z

CRYSTL: add LUKS definition

{{Draft}}{{Guide
| 0 = Intermediate
}}
Some external information that may also be helpful is the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

= Guide to Decent LUKS [[Security]] on [[Linux]] =
LUKS is the Linux Unified Key Setup. This guide explains all of the different part of the LUKS system and why they are important. Check out the advanced guide if you want to know more about how to set these options and what they do in more detail.

== Ciphers ==
Ciphers scramble the [[files]] that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

== On-disk Format ==
The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for [[XTS]], it makes it the fastest and most secure option.

== Initialization Vectors ( IV ) ==
By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, [[plain64]] is the fastest and most secure option.

== [[Password]] [[Hashing]] ==
Password hashing helps make passwords that are not secure harder to break. A ''very'' secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. [[Argon2]] is the most secure option for most users.

== Iteration Time ==
Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer!

LUKS

2026-06-17T02:52:17Z

CRYSTL: finish simplifying things to the expected difficulty

{{Draft}}{{Guide
| 0 = Intermediate
}}
Some external information that may also be helpful is the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

= Guide to Decent LUKS [[Security]] on [[Linux]] =
This guide explains all of the different part of the LUKS system and why they are important! Check out the advanced guide if you want to know more about how to set these options and what they do in more detail.

== Ciphers ==
Ciphers scramble the [[files]] that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

== On-disk Format ==
The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for [[XTS]], it makes it the fastest and most secure option.

== Initialization Vectors ( IV ) ==
By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, [[plain64]] is the fastest and most secure option.

== [[Password]] [[Hashing]] ==
Password hashing helps make passwords that are not secure harder to break. A ''very'' secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. [[Argon2]] is the most secure option for most users.

== Iteration Time ==
Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer!

File:DRAFTS.png

2026-06-17T01:14:01Z

CRYSTL:

LUKS

2026-06-17T00:25:04Z

CRYSTL: prioritize the advanced guide

{{Draft}}

This page is written with [[Tiers|Intermediate]] users in mind, but of course everyone is encouraged to try to understand.

For more more info on this topic, check the [[LUKS/Advanced|Advanced Guide]].

Some external resources that may also be helpful are the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

= Guide to Decent LUKS Security on Linux =
If you just want to know the "best" command to run, you can skip to the bottom. But reading this Guide is encouraged, as it will give you a better understand of what the options do, and how they will affect the security of your data!

== Ciphers ==
Ciphers scramble the files that will be saved, so it's important to pick a good one. Computers have, for many decades now, had

built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

== Initialization Vectors ( IV ) ==
The purpose of IV is to ad some randomness different blocks of the disk , so that overall patterns cannot be discovered . ESSIV ( Encrypted salt-sector initialization vector ) was set as default for CBC to mitigate the fingerprinting issue , but this does not help CBC's issues with malleability . For XTS , plain64 is recommended over plain , since it has no performance impact , and plain has some data leaking vulnerabilities that are viable on disks larger than 2TiB . XTS not being vulnerable to fingerprinitng , does not need the added overhead of ESSIV .

== Password Hashing ==
The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing . Argon2 is optimized to be impossible to brute-force on devices with limited memory , most notably , graphics cards . The point is to force the attacker to use their CPU , which is not usually not nearly as quick as a GPU for this kind of task . Unless you're primarily concerned about some APT trying to break into your device , it is pretty good tradeoff . If your device is very memory constrained ( like under 4GB ), you ''may'' want to consider using PBKDF2 ( Password-Based Key Derivation Function ) . You will almost certainly want to increase the iteration time more though , as it is far weaker to GPU brute-forcing . For a small note on Argon2 , it has a few different variants . Argon2i is weakest to brute-forcing , but has strong side-channel protection . It's generally not safe to use 2i with anything less than 10 iterations . Conversely , while Argon2d is most secure against brute force attacks , it is more susceptible to side channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice .

== Iteration Time ==
This defines how long your computer is going to spend hashing the password . More iteration is generally better , and is mostly a question of how long you willing to spend waiting for your computer to initially decrypt the drive . Do note that it doesn't decrease the speed of the drive after the key is decrypted . To be very clear , high iteration count is not an alternative to a secure password ! 2 seconds ( 2000ms ) is generally the recommended default , though of course you are welcome to set it as high as you are willing to tolerate . Make sure your computer is not set to any " low-power mode " when setting up the disk , as this will affect the time it takes to hash .

Very important note ! Make sure your password is secure ! Using something short is a very bad idea . Using a string of characters from a well known book is also not a great idea ! Something like a diceware password with at least 6 words is generally a good idea !

== Benchmarking ==
If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark .</code><blockquote> # Tests are approximate using memory only (no storage IO).

PBKDF2-sha1 1736052 iterations per second for 256-bit key

PBKDF2-sha256 3355443 iterations per second for 256-bit key

PBKDF2-sha512 1096836 iterations per second for 256-bit key

PBKDF2-ripemd160 434733 iterations per second for 256-bit key

PBKDF2-whirlpool 364088 iterations per second for 256-bit key

argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

# Algorithm | Key | Encryption | Decryption

aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s

serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s

twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s

aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s

serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s

twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s

aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s

serpent-xts 256b 445.6 MiB/s 401.0 MiB/s

twofish-xts 256b 220.3 MiB/s 236.9 MiB/s

aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s

serpent-xts 512b 445.2 MiB/s 437.6 MiB/s

twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</blockquote>As you can see from this sample output , aes-xts is the fastest ! Assuming you're on an x86 machine , this will almost certainly also be the case for you . You'll also notice Argon2i only has 4 iterations here , making it unsafe to use . You can add <code>-i 5000</code> to test 5000ms as an example , to see how many iterations it achieves .

== /dev/urandom ==
Though unlikely , to avoid an entropy-starved situation ( meaning the random numbers are not random enough ) , you can use <code>--use-random</code> when setting up the disk .

There's apparently a lot of debate and conflicting information online about the difference between /dev/random and /dev/urandom online . The main difference is that /dev/random will wait when it estimates that not enough entropy has been gathered . Since it only affects when you initially setup the disk though , waiting for it to gather enough entropy is generally a good idea . Whether its method of ensuring it has gathered enough data is effective , is also somewhat debated , but it certainly doesn't hurt .

= Summary =
Unless you have a strong reason to doubt AES-256 ( which is also post-quantum resistant ) , AES should be used . Using CBC even with ESSIV does not have any compelling reasons for consideration , so XTS likely your best choice , especially since it will be significantly faster to encrypt / decrypt on x86 . These options are the default for good reason , and unless you have a particularly special setup or threat model ; like if for example , if your CPU does not have hardware accelerated AES , or if it had a known vulnerability . Lastly , Argon2id is generally your best option for hashing .

== Disk Setup ==
Assuming your disk is already correctly partitioned , setting up the disk is as simple as :

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously , these settings are the default on the latest cryptsetup ( with the exception of --use-random ) , but setting them manually ensures that they are correct on older versions . You can also check what the defaults are for your system by running cryptsetup --help . You can then verify that it was setup correctly with :

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup , it can be opened with :

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that " dm_name " can be set to whatever you like , and the disk will be available at :

<code>/dev/mapper/dm_name</code>

Then you will need to format it , via something like :

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Of course , you'll want to replace mkfs.ext4 with the setup command for your preferred partition type .

LUKS

2026-06-17T00:23:43Z

CRYSTL: update advanced link

{{Draft}}

This page is written with [[Tiers|Intermediate]] users in mind, but of course everyone is encouraged to try to understand.

For more more info on this topic, check the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ], the [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki], or the [[LUKS/Advanced|Advanced Guide]].

= Guide to Decent LUKS Security on Linux =
If you just want to know the "best" command to run, you can skip to the bottom. But reading this Guide is encouraged, as it will give you a better understand of what the options do, and how they will affect the security of your data!

== Ciphers ==
Ciphers scramble the files that will be saved, so it's important to pick a good one. Computers have, for many decades now, had

built in support for [[AES]], making it the fastest and most secure option for pretty much everyone.

== Initialization Vectors ( IV ) ==
The purpose of IV is to ad some randomness different blocks of the disk , so that overall patterns cannot be discovered . ESSIV ( Encrypted salt-sector initialization vector ) was set as default for CBC to mitigate the fingerprinting issue , but this does not help CBC's issues with malleability . For XTS , plain64 is recommended over plain , since it has no performance impact , and plain has some data leaking vulnerabilities that are viable on disks larger than 2TiB . XTS not being vulnerable to fingerprinitng , does not need the added overhead of ESSIV .

== Password Hashing ==
The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing . Argon2 is optimized to be impossible to brute-force on devices with limited memory , most notably , graphics cards . The point is to force the attacker to use their CPU , which is not usually not nearly as quick as a GPU for this kind of task . Unless you're primarily concerned about some APT trying to break into your device , it is pretty good tradeoff . If your device is very memory constrained ( like under 4GB ), you ''may'' want to consider using PBKDF2 ( Password-Based Key Derivation Function ) . You will almost certainly want to increase the iteration time more though , as it is far weaker to GPU brute-forcing . For a small note on Argon2 , it has a few different variants . Argon2i is weakest to brute-forcing , but has strong side-channel protection . It's generally not safe to use 2i with anything less than 10 iterations . Conversely , while Argon2d is most secure against brute force attacks , it is more susceptible to side channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice .

== Iteration Time ==
This defines how long your computer is going to spend hashing the password . More iteration is generally better , and is mostly a question of how long you willing to spend waiting for your computer to initially decrypt the drive . Do note that it doesn't decrease the speed of the drive after the key is decrypted . To be very clear , high iteration count is not an alternative to a secure password ! 2 seconds ( 2000ms ) is generally the recommended default , though of course you are welcome to set it as high as you are willing to tolerate . Make sure your computer is not set to any " low-power mode " when setting up the disk , as this will affect the time it takes to hash .

Very important note ! Make sure your password is secure ! Using something short is a very bad idea . Using a string of characters from a well known book is also not a great idea ! Something like a diceware password with at least 6 words is generally a good idea !

== Benchmarking ==
If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark .</code><blockquote> # Tests are approximate using memory only (no storage IO).

PBKDF2-sha1 1736052 iterations per second for 256-bit key

PBKDF2-sha256 3355443 iterations per second for 256-bit key

PBKDF2-sha512 1096836 iterations per second for 256-bit key

PBKDF2-ripemd160 434733 iterations per second for 256-bit key

PBKDF2-whirlpool 364088 iterations per second for 256-bit key

argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

# Algorithm | Key | Encryption | Decryption

aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s

serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s

twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s

aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s

serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s

twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s

aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s

serpent-xts 256b 445.6 MiB/s 401.0 MiB/s

twofish-xts 256b 220.3 MiB/s 236.9 MiB/s

aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s

serpent-xts 512b 445.2 MiB/s 437.6 MiB/s

twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</blockquote>As you can see from this sample output , aes-xts is the fastest ! Assuming you're on an x86 machine , this will almost certainly also be the case for you . You'll also notice Argon2i only has 4 iterations here , making it unsafe to use . You can add <code>-i 5000</code> to test 5000ms as an example , to see how many iterations it achieves .

== /dev/urandom ==
Though unlikely , to avoid an entropy-starved situation ( meaning the random numbers are not random enough ) , you can use <code>--use-random</code> when setting up the disk .

There's apparently a lot of debate and conflicting information online about the difference between /dev/random and /dev/urandom online . The main difference is that /dev/random will wait when it estimates that not enough entropy has been gathered . Since it only affects when you initially setup the disk though , waiting for it to gather enough entropy is generally a good idea . Whether its method of ensuring it has gathered enough data is effective , is also somewhat debated , but it certainly doesn't hurt .

= Summary =
Unless you have a strong reason to doubt AES-256 ( which is also post-quantum resistant ) , AES should be used . Using CBC even with ESSIV does not have any compelling reasons for consideration , so XTS likely your best choice , especially since it will be significantly faster to encrypt / decrypt on x86 . These options are the default for good reason , and unless you have a particularly special setup or threat model ; like if for example , if your CPU does not have hardware accelerated AES , or if it had a known vulnerability . Lastly , Argon2id is generally your best option for hashing .

== Disk Setup ==
Assuming your disk is already correctly partitioned , setting up the disk is as simple as :

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously , these settings are the default on the latest cryptsetup ( with the exception of --use-random ) , but setting them manually ensures that they are correct on older versions . You can also check what the defaults are for your system by running cryptsetup --help . You can then verify that it was setup correctly with :

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup , it can be opened with :

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that " dm_name " can be set to whatever you like , and the disk will be available at :

<code>/dev/mapper/dm_name</code>

Then you will need to format it , via something like :

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Of course , you'll want to replace mkfs.ext4 with the setup command for your preferred partition type .

Luks (Advanced)

2026-06-17T00:21:37Z

CRYSTL: CRYSTL moved page Luks (Advanced) to LUKS/Advanced

#REDIRECT [[LUKS/Advanced]]

LUKS/Advanced

2026-06-17T00:21:37Z

CRYSTL: CRYSTL moved page Luks (Advanced) to LUKS/Advanced

{{Draft}}{{Main|LUKS}}

This page is written with [[Tiers|Advanced]] users in mind, but of course everyone is encouraged to try to understand.

For more more info on this topic, check the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ], the [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].

= Guide to Decent LUKS Security on Linux =
The Main Page gives a high level overview of what different LUKS options can do, but this page intends to go into as much detail as possible about them while still aiming to be easy to understand.

== Ciphers ==
Ciphers are the [[algorithms]] used to [[Encryption|encrypt]] [[data]]. Picking the best algorithm is very important for ensuring your data is secure. If your cipher can be broken, then your data can be accessed without the key.

Of the widely supported options, the two most worth considering are [[Serpent]] and [[AES]].

Twofish ''may'' be better in lower-security applications where there's no AES acceleration ''and'' writes happen more often than reads, but generally, not a great option.

Serpent may theoretically be more secure, though in practice its potential advantages seem pretty minimal. It also hasn't been tested as much as AES, so it ''may'' have potential vulnerabilities not yet known about .

Another consideration is the actual implementation. Serpent has potential vulnerabilities depending on the details of the implementation. Without looking into the specific implementation in-depth, it's hard to say how secure it is.

On the other hand, having hardware acceleration for AES has a number of advantages for security, most notably resistance to side channel attacks, and of course, speed. Some chips however, almost always not x86, do not have hardware accelerated AES. It's also possible that your CPU may have a vulnerability, so that's something you may want to look into. As far as we are aware though, no vulnerabilities have been reported on any present or past chip with AES support. Practically speaking, the advantages of having hardware accelerated AES make it more secure than using Serpent in nearly all cases.

== On-disk Format ==
The on-disk format defines how the encrypted data is stored on the disk itself . While you ''could'' just write the encrypted blocks directly to the disk , you would be at risk of a number of different attacks . CBC ( Cipher-block chaining ) is an older on-disk format and should not really be used . It has malleability vulnerabilities ( meaning data can be inserted without knowing the encryption key ) , and also , specially-crafted files can be " fingerprinted " , meaning they can be located on the disk . XTS ( XEX-based tweaked-codebook mode with ciphertext stealing ) is better at mitigating these issues , so it's the recommended default . It's also usually hardware accelerated on x86 . XTS does have its own vulnerabilities , but most of these issues can be mitigated by using a filesystem that can verify and repair corrupted data , like ZFS or BTRFS .

2026-05-03T19:20:41Z

CRYSTL: completed table of contents ( MediaWiki:Sidebar )

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
** https://cryptpad.fr/pad/#/2/pad/view/v9+28PcpFVoMr4eVf-NpF64Do35ocDL3tQLbaWq2Bfk/
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

Main Page

2026-05-03T19:18:31Z

CRYSTL: add weekly meetup

Welcome to the '''FASSAG Wiki'''. This editable knowledge base contains an ever-changing collection of resources developed by the organization.

== What is FASSAG? ==

====== The Free Accessible Safe Software Advocacy Group ======
Our mission is to reach out and make technology accessible and easy to understand. We seek to provide resources and guidance on computer safety, guides on various software, at whatever level of complexity is right for you. You can get involved as much as you'd like! Whether you want to help out with research, or writing guides, or perhaps you're a developer and want to help improve software, we'd be happy to have your support.

== Getting Started ==

* [https://fassag.dev Home] — Get a top level view on our mission.
* [[TODO]] — What we're currently working on.
* [[Operations]] — Get a detailed look at how we operate.
* [[Organization]] — See how we structure ourselves.
* [[Weekly Meetup]] — Meet up and work on projects together!
* [https://codeberg.org/FASSAG Forge] — The Codeberg organization where all our code is stored.
* [https://matrix.to/#/#fassag-entrance:chat.solarpunk.moe?client=element.io Matrix Space] — Join to chat about FASSAG.

2026-05-03T19:12:49Z

CRYSTL:

MediaWiki:Sidebar

2026-05-03T19:12:16Z

CRYSTL:

MediaWiki:Sidebar

2026-05-03T19:09:31Z

CRYSTL:

MediaWiki:Help-mediawiki

2026-05-03T19:09:01Z

CRYSTL:

Manual

MediaWiki:Help-mediawiki

2026-05-03T18:52:25Z

CRYSTL: Created page with "Wiki Manual"

Wiki Manual