diff options
Diffstat (limited to 'FAQ')
| -rw-r--r-- | FAQ | 84 |
1 files changed, 41 insertions, 43 deletions
@@ -51,7 +51,7 @@ A. Contributors security model BEFORE you face such a disaster! In particular, make sure you have a current header backup before doing any potentially dangerous operations. The LUKS2 header should be a bit more resilient - as critical data starts later and is stored twice, but you can decidely + as critical data starts later and is stored twice, but you can decidedly still destroy it or a keyslot permanently by accident. DEBUG COMMANDS: While the --debug and --debug-json options should not @@ -112,7 +112,7 @@ A. Contributors characters may have different encoding depending on system configuration and your passphrase will not work with a different encoding. A table of the standardized first 128 ASCII characters can, e.g. be found on - http://en.wikipedia.org/wiki/ASCII + https://en.wikipedia.org/wiki/ASCII KEYBOARD NUM-PAD: Apparently some pre-boot authentication environments (these are done by the distro, not by cryptsetup, so complain there) @@ -173,7 +173,7 @@ A. Contributors which means distribution is unlimited, you may create derived works, but attributions to original authors and this license statement must be retained and the derived work must be under the same license. See - http://creativecommons.org/licenses/by-sa/3.0/ for more details of the + https://creativecommons.org/licenses/by-sa/3.0/ for more details of the license. Side note: I did text license research some time ago and I think this @@ -191,7 +191,7 @@ A. Contributors * 1.7 Is there a mailing-list? - Instructions on how to subscribe to the mailing-list are at on the + Instructions on how to subscribe to the mailing-list are on the project website. People are generally helpful and friendly on the list. @@ -241,7 +241,7 @@ A. Contributors * 2.1 LUKS Container Setup mini-HOWTO This item tries to give you a very brief list of all the steps you - should go though when creating a new LUKS encrypted container, i.e. + should go through when creating a new LUKS encrypted container, i.e. encrypted disk, partition or loop-file. 01) All data will be lost, if there is data on the target, make a @@ -268,7 +268,7 @@ A. Contributors This can take a while. To get a progress indicator, you can use the tool dd_rescue (->google) instead or use my stream meter "wcs" (source - here: http://www.tansi.org/tools/index.html) in the following fashion: + here: https://www.tansi.org/tools/index.html) in the following fashion: cat /dev/zero | wcs > <target device> @@ -295,7 +295,7 @@ A. Contributors Just follow the on-screen instructions. - Note: Passprase iteration count is based on time and hence security + Note: Passphrase iteration count is based on time and hence security level depends on CPU power of the system the LUKS container is created on. For example on a Raspberry Pi and LUKS1, I found some time ago that the iteration count is 15 times lower than for a regular PC (well, for @@ -343,7 +343,7 @@ A. Contributors See Section 6 for details. Done. You can now use the encrypted file system to store data. Be sure - to read though the rest of the FAQ, these are just the very basics. In + to read through the rest of the FAQ, these are just the very basics. In particular, there are a number of mistakes that are easy to make, but will compromise your security. @@ -473,7 +473,7 @@ A. Contributors That is it. Reboot or start it manually to activate encrypted swap. Manual start would look like this: - /etc/init.d/crypdisks start + /etc/init.d/cryptdisks start swapon /dev/mapper/swap @@ -677,7 +677,7 @@ A. Contributors A bit more information on the process by which transactional guarantees are implemented can be found here: - http://lwn.net/Articles/400541/ + https://lwn.net/Articles/400541/ Please note that these "guarantees" are weaker than they appear to be. One problem is that quite a few disks lie to the OS about having flushed @@ -705,10 +705,6 @@ A. Contributors the key from STDIN and write it there with your own tool that in turn gets the key from the more secure key storage. - For TPM support, you may want to have a look at tpm-luks at - https://github.com/shpedoikal/tpm-luks. Note that tpm-luks is not - related to the cryptsetup project. - * 2.15 Can I resize a dm-crypt or LUKS container? @@ -787,7 +783,7 @@ A. Contributors The conventional recommendation if you want to do more than just a zero-wipe is to use something like - cat /dev/urandom > <taget-device> + cat /dev/urandom > <target-device> That used to very slow and painful at 10-20MB/s on a fast computer, but newer kernels can give you > 200MB/s (depending on hardware). An @@ -811,7 +807,7 @@ A. Contributors dd_rescue -w /dev/zero /dev/mapper/to_be_wiped Progress-indicator by my "wcs" stream meter (available from - http://www.tansi.org/tools/index.html ): + https://www.tansi.org/tools/index.html ): cat /dev/zero | wcs > /dev/mapper/to_be_wiped @@ -821,7 +817,7 @@ A. Contributors Remove the mapping at the end and you are done. - * 2.20 How to I wipe only the LUKS header? + * 2.20 How do I wipe only the LUKS header? This does _not_ describe an emergency wipe procedure, see Item 5.4 for that. This procedure here is intended to be used when the data should @@ -911,10 +907,10 @@ A. Contributors much longer. Also take into account that up to 8 key-slots (LUKS2: up to 32 key-slots) have to be tried in order to find the right one. - If this is problem, you can add another key-slot using the slow machine - with the same passphrase and then remove the old key-slot. The new - key-slot will have the unlock time adjusted to the slow machine. Use - luksKeyAdd and then luksKillSlot or luksRemoveKey. You can also use + If this is the problem, you can add another key-slot using the slow + machine with the same passphrase and then remove the old key-slot. The + new key-slot will have the unlock time adjusted to the slow machine. + Use luksKeyAdd and then luksKillSlot or luksRemoveKey. You can also use the -i option to reduce iteration time (and security level) when setting a passphrase. Default is 1000 (1 sec) for LUKS1 and 2000 (2sec) for LUKS2. @@ -973,7 +969,7 @@ A. Contributors that is intact. In order to find out whether a key-slot is damaged one has to look for - "non-random looking" data in it. There is a tool that automatizes this + "non-random looking" data in it. There is a tool that automates this for LUKS1 in the cryptsetup distribution from version 1.6.0 onwards. It is located in misc/keyslot_checker/. Instructions how to use and how to interpret results are in the README file. Note that this tool requires @@ -991,7 +987,7 @@ A. Contributors LUKS and dm-crypt can give the RAM quite a workout, especially when combined with software RAID. In particular the combination RAID5 + LUKS1 + XFS seems to uncover RAM problems that do not cause obvious - problems otherwise. Symptoms vary, but often the problem manifest + problems otherwise. Symptoms vary, but often the problem manifests itself when copying large amounts of data, typically several times larger than your main memory. @@ -1085,7 +1081,7 @@ A. Contributors 5. Security Aspects - * 5.1 How long is a secure passphrase ? + * 5.1 How long is a secure passphrase? This is just the short answer. For more info and explanation of some of the terms used in this item, read the rest of Section 5. The actual @@ -1124,7 +1120,7 @@ A. Contributors i.e. I estimated the attack to be too easy. Nobody noticed ;-) On the plus side, the tables are now (2017) pretty much accurate. - More references can be found a the end of this document. Note that + More references can be found at the end of this document. Note that these are estimates from the defender side, so assuming something is easier than it actually is is fine. An attacker may still have significantly higher cost than estimated here. @@ -1215,7 +1211,7 @@ A. Contributors already lock you up. Hidden containers (encryption hidden within encryption), as possible with Truecrypt, do not help either. They will just assume the hidden container is there and unless you hand over the - key, you will stay locked up. Don't have a hidden container? Though + key, you will stay locked up. Don't have a hidden container? Tough luck. Anybody could claim that. Still, if you are concerned about the LUKS header, use plain dm-crypt @@ -1271,7 +1267,7 @@ A. Contributors single overwrite could be enough. If in doubt, use physical destruction in addition. Here is a link to some current research results on erasing SSDs and FLASH drives: - http://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf + https://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf Keep in mind to also erase all backups. @@ -1295,7 +1291,7 @@ A. Contributors medium. If your backup is on magnetic tape, I advise physical destruction by - shredding or burning, after (!) overwriting . The problem with magnetic + shredding or burning, after (!) overwriting. The problem with magnetic tape is that it has a higher dynamic range than HDDs and older data may well be recoverable after overwrites. Also write-head alignment issues can lead to data not actually being deleted during overwrites. @@ -1317,7 +1313,7 @@ A. Contributors Overwriting the LUKS header in part or in full is the most common reason why access to LUKS containers is lost permanently. Overwriting can be done in a number of fashions, like creating a new filesystem on the raw - LUKS partition, making the raw partition part of a raid array and just + LUKS partition, making the raw partition part of a RAID array and just writing to the raw partition. The LUKS1 header contains a 256 bit "salt" per key-slot and without that @@ -1409,7 +1405,7 @@ A. Contributors combination of 12 truly random letters and digits. For passphrase generation, do not use lines from very well-known texts - (religious texts, Harry potter, etc.) as they are too easy to guess. + (religious texts, Harry Potter, etc.) as they are too easy to guess. For example, the total Harry Potter has about 1'500'000 words (my estimation). Trying every 64 character sequence starting and ending at a word boundary would take only something like 20 days on a single CPU @@ -1612,8 +1608,9 @@ A. Contributors cryptsetup -c aes-xts-plain64 luksFormat <device> - There is a potential security issue with XTS mode and large blocks. - LUKS and dm-crypt always use 512B blocks and the issue does not apply. + There is a potential security issue with XTS mode and blocks larger + than 2^20 bytes or so. LUKS and dm-crypt always use smaller blocks + and the issue does not apply. * 5.17 Is LUKS FIPS-140-2 certified? @@ -1701,8 +1698,9 @@ A. Contributors can demand encryption keys. Here is an additional reference for some problems with plausible - deniability: http://www.schneier.com/paper-truecrypt-dfs.pdf I strongly - suggest you read it. + deniability: + https://www.schneier.com/academic/paperfiles/paper-truecrypt-dfs.pdf + I strongly suggest you read it. So, no, I will not provide any instructions on how to do it with plain dm-crypt or LUKS. If you insist on shooting yourself in the foot, you @@ -1847,7 +1845,7 @@ A. Contributors document. It does require advanced skills in this age of pervasive surveillance.) - Hence, LUKS has not kill option because it would do much more harm than + Hence, LUKS has no kill option because it would do much more harm than good. Still, if you have a good use-case (i.e. non-abstract real-world @@ -1917,7 +1915,7 @@ A. Contributors cryptsetup --header <file> luksOpen <device> </dev/mapper/name> - If that unlocks your keys-lot, you are good. Do not forget to close + If that unlocks your key-slot, you are good. Do not forget to close the device again. Under some circumstances (damaged header), this fails. Then use the @@ -2037,7 +2035,7 @@ A. Contributors * 6.5 Do I need a backup of the full partition? Would the header - and key-slots not be enough? + and key-slots not be enough? Backup protects you against two things: Disk loss or corruption and user error. By far the most questions on the dm-crypt mailing list about how @@ -2631,7 +2629,7 @@ offset length name data type description safe under these circumstances, then you have bigger problems than this somewhat expected behavior. - The CVE was exagerrated and should not be assigned to upstream + The CVE was exaggerated and should not be assigned to upstream cryptsetup in the first place (it is a distro specific initrd issue). It was driven more by a try to make a splash for self-aggrandizement, than by any actual security concerns. Ignore it. @@ -2780,7 +2778,7 @@ offset length name data type description Mostly not. The header has changed in its structure, but the crytpgraphy is the same. The one exception is that PBKDF2 has been - replaced by Argon2 to give better resilience against attacks attacks by + replaced by Argon2 to give better resilience against attacks by graphics cards and other hardware with lots of computing power but limited local memory per computing element. @@ -2827,7 +2825,7 @@ offset length name data type description there to prevent precomputation. The problem with that is that if you use a graphics card, you can massively - speed up these computations as PBKDF2 needs very little memeory to compute + speed up these computations as PBKDF2 needs very little memory to compute it. A graphics card is (grossly simplified) a mass of small CPUs with some small very fast local memory per CPU and a large slow memory (the 4/6/8 GB a current card may have). If you can keep a computation in the small, @@ -2840,7 +2838,7 @@ offset length name data type description if you set, for example, 4GB of memory, computing Argon2 on a graphics card with around 100kB of memory per "CPU" makes no sense at all because it is far too slow. An attacker has hence to use real CPUs and furthermore is - limited by main memory bandwith. + limited by main memory bandwidth. Hence the large amount of memory used is a security feature and should not be turned off or reduced. If you really (!) understand what you are doing @@ -2864,7 +2862,7 @@ offset length name data type description second/slot unlock time, LUKS2 adjusts the memory parameter down if needed. In the other direction, it will respect available memory and not exceed it. On a current PC, the memory parameter will be somewhere around - 1GB, which should quite generous. The minimum I was able to set in an + 1GB, which should be quite generous. The minimum I was able to set in an experiment with "-i 1" was 400kB of memory and that is too low to be secure. A Raspberry Pi would probably end up somewhere around 50MB (have not tried it) and that should still be plenty. @@ -2994,7 +2992,7 @@ offset length name data type description - http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.html - - http://it.slashdot.org/story/12/12/05/0623215/new-25-gpu-monster-devours-strong-passwords-in-minutes + - https://it.slashdot.org/story/12/12/05/0623215/new-25-gpu-monster-devours-strong-passwords-in-minutes * Tools |