LUKS: Difference between revisions

Line 5:

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 cryptsetup FAQ, the Arch Wiki, or the Advanced ~~page~~. '''TODO !!! LINK THESE'''

For more more info on this topic, check the cryptsetup FAQ, the Arch Wiki, or the [[Luks (Advanced)|Advanced Guide]]. '''TODO !!! LINK THESE'''

= Guide to Decent LUKS Security on Linux =

Line 11:

== Ciphers ==

Ciphers ~~are~~ the ~~algorithms that encrypt the data~~ that will be ~~written to the disk . Picking one that is resistant to attacks is critical , as otherwise your data is potentially vulnerable , even without the key .~~

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

Of the widely supported options , generally the two 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 , ( usually not x86 ) , do not have hardware accelerated AES~~ . ~~It's also possible that your CPU may~~ have ~~a vulnerability , so that's something you want to look into . Not currently aware of anything like this , though some Ryzen chips recently~~ had ~~an AES vulnerability that allowed unauthorized microcode to be installed . To be very clear~~ , ~~this has been patched with a microcode update~~ , ~~and is also not directly relevant to use~~ in ~~disk unlocking . Practically speaking~~ , the ~~advantages of having hardware accelerated AES likely make it more~~ secure ~~than using Serpent in nearly all cases~~ .

== On-disk Format ==

@@ Line 5: / Line 5: @@
 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 cryptsetup FAQ, the Arch Wiki, or the Advanced page. '''TODO !!! LINK THESE'''
+For more more info on this topic, check the cryptsetup FAQ, the Arch Wiki, or the [[Luks (Advanced)|Advanced Guide]]. '''TODO !!! LINK THESE'''
 = Guide to Decent LUKS Security on Linux =
@@ Line 11: / Line 11: @@
 == Ciphers ==
-Ciphers are the algorithms that encrypt the data that will be written to the disk . Picking one that is resistant to attacks is critical , as otherwise your data is potentially vulnerable , even without the key .
+Ciphers scramble the files that will be saved, so it's important to pick a good one. Computers have had, for many decades now, built in support for AES, making it the fastest and most secure option for pretty much everyone.
-Of the widely supported options , generally the two 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 , ( usually not x86 ) , do not have hardware accelerated AES . It's also possible that your CPU may have a vulnerability , so that's something you want to look into . Not currently aware of anything like this , though some Ryzen chips recently had an AES vulnerability that allowed unauthorized microcode to be installed . To be very clear , this has been patched with a microcode update , and is also not directly relevant to use in disk unlocking . Practically speaking , the advantages of having hardware accelerated AES likely make it more secure than using Serpent in nearly all cases .
 == On-disk Format ==