Cryptsetup raid 5

Simply run as root:. You can get more than the default benchmarks, see the man-page for the relevant parameters. Note that XTS mode takes two keys, hence the listed key sizes are double that for other modes and half of it is the cipher key, the other half is the XTS key.

While I have every confidence this really is his key and that he is who he claims to be, don't depend on it if your life is at stake. For that matter, if your life is at stake, don't depend on me being who I claim to be either. That said, as cryptsetup is under good version control and a malicious change should be noticed sooner or later, but it may take a while. Also, the attacker model makes compromising the sources in a non-obvious way pretty hard. Sure, you could put the master-key somewhere on disk, but that is rather obvious as soon as somebody looks as there would be data in an empty LUKS container in a place it should not be.

Doing this in a more nefarious way, for example hiding the master-key in the salts, would need a look at the sources to be discovered, but I think that somebody would find that sooner or later as well. That said, this discussion is really a lot more complicated and longer as an FAQ can sustain. If in doubt, ask on the mailing list. Not from dm-crypt itself. Note that if your partition or filesystem is misaligned, dm-crypt can make the effect worse though.

Also note that SSDs typically have much larger blocks internally e. The conventional recommendation if you want to do more than just a zero-wipe is to use something like. An alternative is using cryptsetup and a plain dm-crypt device with a random key, which is fast and on the same level of security. The defaults are quite enough. For the actual wipe you have several options. Basically, you pipe zeroes into the opened container that then get encrypted.

Simple wipe without progress-indicator:. This does not describe an emergency wipe procedure, see Item 5. This procedure here is intended to be used when the data should stay intact, e. Please only do this if you have a current backup. LUKS2: warning, untested! Remember that backup? This assumes the LUKS2 container uses the defaults, in particular there is only one data segment.

If you get a specific error message, investigate what it claims first. If not, you may want to check the following things. Check that you have the device mapper and the crypt target in your kernel. The output of "dmsetup targets" should list a "crypt" target. If it is not there or the command fails, add device mapper and crypt-target to the kernel.

Check that the hash-functions and ciphers you want to use are in the kernel. The default cipher, hash or mode may have changed the mode changed from 1. See under "Issues With Specific Versions of cryptsetup". The unlock time for a key-slot see Section 5 for an explanation what iteration does is calculated when setting a passphrase.

By default it is 1 second 2 seconds for LUKS2. If you set a passphrase on a fast machine and then unlock it on a slow machine, the unlocking time can be 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 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. You can also use the -i option to reduce iteration time and security level when setting a passphrase.

In order to change that, you will have to backup the data in the LUKS container i. Note that MK iterations are not very security relevant. This confuses blkid. Fix: Wipe the unused header areas by doing a backup and restore of the header with cryptsetup 1. For LUKS1, this means that the given keyslot has an offset that points outside the valid keyslot area.

Refer to Section "Backup and Data Recovery" and ask on the mailing list if you have trouble diagnosing and if still possible repairing this. First, make sure you have a correct passphrase. Then make sure you have the correct key-map and correct keyboard. If you are sure you are entering the passphrase right, there is the possibility that the respective key-slot has been damaged. There is no way to recover a damaged key-slot, except from a header backup see Section 6.

For security reasons, there is also no checksum in the key-slots that could tell you whether a key-slot has been damaged. The only checksum present allows recognition of a correct passphrase, but that only works with that correct passphrase and a respective key-slot 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 for LUKS1 in the cryptsetup distribution from version 1.

Note that this tool requires a libcryptsetup from cryptsetup 1. If the tool complains about missing functions in libcryptsetup, you likely have an earlier version from your distribution still installed. You can either point the symbolic link s from libcryptsetup.

Symptoms vary, but often the problem manifests itself when copying large amounts of data, typically several times larger than your main memory. Note: One thing you should always do on large data copying or movements is to run a verify, for example with the "-d" option of "tar" or by doing a set of MD5 checksums on the source or target with.

If you get mismatches here, RAM is the primary suspect. A lesser suspect is an overclocked CPU. I have found countless hardware problems in verify runs after copying data or making backups.

Bit errors are much more common than most people think. Some RAM issues are even worse and corrupt structures in one of the layers. This typically results in lockups, CPU state dumps in the system logs, kernel panic or other things.

It is quite possible to have a problem with an encrypted device, but not with an otherwise the same unencrypted device. The reason for that is that encryption has an error amplification property: If you flip one bit in an encrypted data block, the decrypted version has half of its bits flipped.

This is actually an important security property for modern ciphers. A corrupt block causes a lot more havoc than the occasionally flipped single bit and can result in various obscure errors.

Note that a verify run on copying between encrypted or unencrypted devices will reliably detect corruption, even when the copying itself did not report any problems.

If you find defect RAM, assume all backups and copied data to be suspect, unless you did a verify. First you should know that overclocking often makes memory problems worse.

So if you overclock which I strongly recommend against in a system holding data that has any worth , run the tests with the overclocking active. There are two good options. Both use different testing methods and I have found problems fast with either one that the other needed long to find. I recommend running the following procedure until the first error is found:. Run memtester for one cycle shut down as many other applications as possible and use the largest memory area you can get.

If you can reproduce the original problem reliably, a good additional test may be to remove half of the RAM if you have more than one module and try whether the problem is still there and if so, try with the other half. If you just have one module, get a different one and try with that. If you do overclocking, reduce the settings to the most conservative ones available and try with that.

There most definitely is. A dump from strace and friends can contain all data entered, including the full passphrase. Example with strace and passphrase "test":. Depending on different factors and the tool used, the passphrase may also be encoded and not plainly visible. Hence it is never a good idea to give such a trace from a live container to anybody. Recreate the problem with a test container or set a temporary passphrase like "test" and use that for the trace generation.

Item 2. 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 recommendation is at the end of this item.

First, passphrase length is not really the right measure, passphrase entropy is. If your passphrase is times the letter "a", it is long but has very low entropy and is pretty insecure. For example, a random lowercase letter a-z gives you 4. On the other hand, a random English word only gives you 0. Using sentences that make sense gives lower entropy, series of random words gives higher entropy. Do not use sentences that can be tied to you or found on your computer.

This type of attack is done routinely today. That said, it does not matter too much what scheme you use, but it does matter how much entropy your passphrase contains, because an attacker has to try on average. Historically, estimations tended to use computing time estimates, but more modern approaches try to estimate cost of guessing a passphrase.

This is in Incidentally, my older calculation for a machine around times slower was off by a factor of about , but in the right direction, i. I estimated the attack to be too easy. Nobody noticed ;- On the plus side, the tables are now pretty much accurate.

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. We will leave aside the check whether a try actually decrypts a key-slot. I will assume a useful lifetime of the hardware of 2 years. This is on the low side. Disregarding downtime, the machine can then break. This can be parallelized, it can be done faster than 2 years with several of these machines. For LUKS2, things look a bit better, as the advantage of using graphics cards is massively reduced.

Using the recommendations below should hence be fine for LUKS2 as well and give a better security margin. For plain dm-crypt no hash iteration this is it.

For a current CPU, there are about k iterations as can be queried with ''cryptsetup luksDump''. To get reasonable security for the next 10 years, it is a good idea to overestimate by a factor of at least Then there is the question of how much the attacker is willing to spend.

That is up to your own security evaluation. Then we get the following recommendations:. That is e. If paranoid, add at least 20 bit. That is roughly four additional characters for random passphrases and roughly 32 characters for a random English sentence. In practice it does not really matter. In most civilized countries you can just refuse to hand over the keys, no harm done. In some countries they can force you to hand over the keys if they suspect encryption.

The suspicion is enough, they do not have to prove anything. This is for practical reasons, as even the presence of a header like the LUKS header is not enough to prove that you have any keys. It might have been an experiment, for example. So they make you prove you do not have encrypted data. Of course, if true, that is impossible and hence the whole idea is not compatible with fair laws.

Note that in this context, countries like the US or the UK are not civilized and do not have fair laws. As a side-note, standards for biometrics fingerprint, retina, vein-pattern, etc. If you put your LUKS passphrase into a device that can be unlocked using biometrics, they may force a biometric sample in many countries where they could not force you to give them a passphrase you solely have in your memory and can claim to have forgotten if needed it happens. If you need protection on this level, make sure you know what the respective legal situation is, also while traveling, and make sure you decide beforehand what you will do if push comes to shove as they will definitely put you under as much pressure as they can legally apply.

This means that if you have a large set of random-looking data, they can 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? Tough luck. Anybody could claim that. Still, if you are concerned about the LUKS header, use plain dm-crypt with a good passphrase. If you just create a filesystem on it, most of the old data will still be there.

If the old data is sensitive, you should overwrite it before encrypting. In any case, not initializing will leave the old data there until the specific sector gets written. That may enable an attacker to determine how much and where on the partition data was written. If you think this is a risk, you can prevent this by overwriting the encrypted device here assumed to be named "e1" with zeros like this:.

A single overwrite with zeros should be enough. If you anticipate being in a desperate hurry, prepare the command beforehand. A LUKS header backup or full backup will still grant access to most or all data, so make sure that an attacker does not have access to backups or destroy them as well.

The only way to be sure there is physical destruction. If the situation permits, do both overwrite and physical destruction. If you have time, overwrite the whole drive with a single pass of random data. This is enough for most HDDs. This is possibly still insecure as the respective technologies are not fully understood in this regard.

Still, due to the anti-forensic properties of the LUKS key-slots, a single overwrite could be enough. If in doubt, use physical destruction in addition. That depends on the medium it is stored on. For write-once media, use physical destruction. For high security needs, shred or burn the medium. If your backup is on magnetic tape, I advise physical destruction by shredding or burning, after!

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.

Best keep them on paper, as that has excellent durability and secure destruction is easy, for example by burning and then crushing the ashes to a fine powder. A blender and water also works nicely. 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 writing to the raw partition. The LUKS1 header contains a bit "salt" per key-slot and without that no decryption is possible.

While the salts are not secret, they are key-grade material and cannot be reconstructed. This is a cryptographically strong "cannot". From observations on the cryptsetup mailing-list, people typically go though the usual stages of grief Denial, Anger, Bargaining, Depression, Acceptance when this happens to them. Observed times vary between 1 day and 2 weeks to complete the cycle. Seeking help on the mailing-list is fine.

Even if we usually cannot help with getting back your data, most people found the feedback comforting. If your header does not contain an intact key-slot salt, best go directly to the last stage "Acceptance" and think about what to do now. There is one exception that I know of: If your LUKS1 container is still open, then it may be possible to extract the master key from the running system.

For LUKS2, things are both better and worse. First, the salts are in a less vulnerable position now. But, on the other hand, the keys of a mapped open container are now stored in the kernel key-store, and while there probably is some way to get them out of there, I am not sure how much effort that needs. A salt is a random key-grade value added to the passphrase before it is processed.

It is not kept secret. The reason for using salts is as follows: If an attacker wants to crack the password for a single LUKS container, then every possible passphrase has to be tried. Typically an attacker will not try every binary value, but will try words and sentences from a dictionary. If an attacker wants to attack several LUKS containers with the same dictionary, then a different approach makes sense: Compute the resulting slot-key for each dictionary element and store it on disk. Then the test for each entry is just the slow unlocking with the slot key say 0.

For a single attack, this does not help. But if you have more than one container to attack, this helps tremendously, also because you can prepare your table before you even have the container to attack! The calculation is also very simple to parallelize.

This is where the salt comes in. If the salt is combined with the passphrase in the simplest form, just appended to it , you suddenly need a separate table for each salt value. With a reasonably-sized salt value bit, e. Short answer: yes. Do not use a low-entropy passphrase.

Note: For LUKS2, protection for bad passphrases is a bit better due to the use of Argon2, but that is only a gradual improvement. Longer answer: This needs a bit of theory. The quality of your passphrase is directly related to its entropy information theoretic, not thermodynamic.

The entropy says how many bits of "uncertainty" or "randomness" are in you passphrase. In other words, that is how difficult guessing the passphrase is. Example: A random English sentence has about 1 bit of entropy per character. A random lowercase or uppercase character has about 4. Now, if n is the number of bits of entropy in your passphrase and t is the time it takes to process a passphrase in order to open the LUKS container, then an attacker has to spend at maximum.

There is no way getting around that relationship. However, there is one thing that does help, namely increasing t, the time it takes to use a passphrase, see next FAQ item. Still, if you want good security, a high-entropy passphrase is the only option. For example, a low-entropy passphrase can never be considered secure against a TLA-level Three Letter Agency level, i.

Use at least 64 bits for secret stuff. That is 64 characters of English text but only if randomly chosen or a 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. For example, the total Harry Potter has about 1'' 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 and is entirely feasible. On the other hand, choosing 1. Now that I have mentioned it here, don't use tWoT either! If you add 2 or 3 typos and switch some words around, then this is good passphrase material. Iterations are done with the explicit purpose to increase the time that it takes to unlock a key-slot. This provides some protection against use of low-entropy passphrases.

The idea is that an attacker has to try all possible passphrases. Even if the attacker knows the passphrase is low-entropy see last item , it is possible to make each individual try take longer. The way to do this is to repeatedly hash the passphrase for a certain time. The attacker then has to spend the same time given the same computing power as the user per try. Example 1: Lets assume we have a really bad passphrase e. With the same CPU, an attacker would need to spend around seconds on average to break that passphrase.

Without iteration, it would be more like 0. Example 2: The user did a bit better and has 32 chars of English text. That would be about 32 bits of entropy. With 1 second iteration, that means an attacker on the same CPU needs around years. That is pretty impressive for such a weak passphrase.

Without the iterations, it would be more like 50 days on a modern CPU, and possibly far less. The attack can also happen quite some time after the luksFormat operation and CPUs can have become faster and cheaper.

For that reason you want a bit of extra security. Anyways, in Example 1 your are screwed. In example 2, not necessarily. The first can be prohibitively expensive, while the second is something you try even without solid proof that the decryption will yield something useful.

The numbers above are mostly made up, but show the idea. You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser. Thread starter hastala Start date Aug 9, Joined Aug 8, Messages 6. Bones [H]ard Gawd. Joined Mar 11, Messages 1, The hdparm run is a little on the low side, maybe, but not out of line with expectations for a non-encrypted RAID With encryption, you would be doing well to get half that.

Since you didn't post the bonnie command used for that run, we have no idea what you're testing, so it doesn't mean a whole lot. This is hdparm for the encrypted volume, looks like the reads are really bad now, can that be normal for the encrypted volume? Writing with putc Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Learn more. Is it possible to grow a luks-encrypted external raid5 array? Ask Question. Asked 10 years, 5 months ago. Active 9 years ago. Viewed 5k times. Improve this question. Add a comment. Active Oldest Votes. Improve this answer. Yep, you certainly can. Then I told the array to grow [ Then I needed to tell the encrypted partition it was bigger.

Community Bot 1. Regan W Regan W 66 1 1 bronze badge. Save my name, email, and website in this browser for the next time I comment. Notify me of followup comments via e-mail. All rights reserved Terms of Service. LUKS is the disk encryption for Linux. Or, you inherited a system from someone that has a mounted partition with LUKS encryption. For security compliance purpose, you are required to change the LUKS encryption password frequently. In this case you have to rotate the LUKS key without disrupting the mounted partition.

Any one of the eight different keys can be used to open the encrypted partition. You can choose to have only one key on a partition, or you can assign all eight different keys. Thanks for the well guidance and its really helpful for new knowledge.

Although i didnot tested it, But i have a question. Basically i am using a pendrive to transfer data between linux and windows.