+ * 5.17 Is LUKS FIPS-140-2 certified?
+
+ No. But that is more a problem of FIPS-140-2 than of LUKS. From a
+ technical point-of-view, LUKS with the right parameters would be
+ FIPS-140-2 compliant, but in order to make it certified, somebody
+ has to pay real money for that. And then, whenever cryptsetup is
+ changed or extended, the certification lapses and has to be
+ obtained again.
+
+ From the aspect of actual security, LUKS with default parameters
+ should be as good as most things that are FIPS-140-2 certified,
+ although you may want to make sure to use /dev/random (by
+ specifying --use-random on luksFormat) as randomness source for
+ the master key to avoid being potentially insecure in an
+ entropy-starved situation.
+
+
+ * 5.18 What about Plausible Deniability?
+
+ First let me attempt a definition for the case of encrypted
+ filesystems: Plausible deniability is when you hide encrypted data
+ inside an encrypted container and it is not possible to prove it is
+ there. The idea is compelling and on first glance it seems
+ possible to do it. And from a cryptographic point of view, it
+ actually is possible.
+
+ So, does it work in practice? No, unfortunately. The reasoning used
+ by its proponents is fundamentally flawed in several ways and the
+ cryptographic properties fail fatally when colliding with the real
+ world.
+
+ First, why should "I do not have a hidden partition" be any more
+ plausible than "I forgot my crypto key" or "I wiped that partition
+ with random data, nothing in there"? I do not see any reason.
+
+ Second, there are two types of situations: Either they cannot force
+ you to give them the key (then you simply do not) or the can. In
+ the second case, they can always do bad things to you, because they
+ cannot prove that you have the key in the first place! This means
+ they do not have to prove you have the key, or that this random
+ looking data on your disk is actually encrypted data. So the
+ situation will allow them to waterboard/lock-up/deport you
+ anyways, regardless of how "plausible" your deniability is. Do not
+ have a hidden partition you could show to them, but there are
+ indications you may? Too bad for you. Unfortunately "plausible
+ deniability" also means you cannot prove there is no hidden data.
+
+ Third, hidden partitions are not that hidden. There are basically
+ just two possibilities: a) Make a large crypto container, but put a
+ smaller filesystem in there and put the hidden partition into the
+ free space. Unfortunately this is glaringly obvious and can be
+ detected in an automated fashion. This means that the initial
+ suspicion to put you under duress in order to make you reveal you
+ hidden data is given. b) Make a filesystem that spans the whole
+ encrypted partition, and put the hidden partition into space not
+ currently used by that filesystem. Unfortunately that is also
+ glaringly obvious, as you then cannot write to the filesystem
+ without a high risk of destroying data in the hidden container.
+ Have not written anything to the encrypted filesystem in a while?
+ Too bad, they have the suspicion they need to do unpleasant things
+ to you.
+
+ To be fair, if you prepare option b) carefully and directly before
+ going into danger, it may work. But then, the mere presence of
+ encrypted data may already be enough to get you into trouble in
+ those places were they 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.
+
+ 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 can figure out how to do it yourself.
+
+
+ * 5.19 What about SSDs, Flash and Hybrid Drives?
+
+ The problem is that you cannot reliably erase parts of these
+ devices, mainly due to wear-leveling and possibly defect
+ management.
+
+ Basically, when overwriting a sector (of 512B), what the device
+ does is to move an internal sector (may be 128kB or even larger) to
+ some pool of discarded, not-yet erased unused sectors, take a
+ fresh empty sector from the empty-sector pool and copy the old
+ sector over with the changes to the small part you wrote. This is
+ done in some fashion so that larger writes do not cause a lot of
+ small internal updates.
+
+ The thing is that the mappings between outside-addressable sectors
+ and inside sectors is arbitrary (and the vendors are not talking).
+ Also the discarded sectors are not necessarily erased immediately.
+ They may linger a long time.
+
+ For plain dm-crypt, the consequences are that older encrypted data
+ may be lying around in some internal pools of the device. Thus may
+ or may not be a problem and depends on the application. Remember
+ the same can happen with a filesystem if consecutive writes to the
+ same area of a file can go to different sectors.
+
+ However, for LUKS, the worst case is that key-slots and LUKS
+ header may end up in these internal pools. This means that password
+ management functionality is compromised (the old passwords may
+ still be around, potentially for a very long time) and that fast
+ erase by overwriting the header and key-slot area is insecure.
+
+ Also keep in mind that the discarded/used pool may be large. For
+ example, a 240GB SSD has about 16GB of spare area in the chips that
+ it is free to do with as it likes. You would need to make each
+ individual key-slot larger than that to allow reliable overwriting.
+ And that assumes the disk thinks all other space is in use.
+ Reading the internal pools using forensic tools is not that hard,
+ but may involve some soldering.
+
+ What to do?
+
+ If you trust the device vendor (you probably should not...) you can
+ try an ATA "secure erase" command for SSDs. That does not work for
+ USB keys though and may or may not be secure for a hybrid drive. If
+ it finishes on an SSD after a few seconds, it was possibly faked.
+ UNfortunately, for hybrid drives that indicator does not work, as
+ the drive may well take the time to dully erase the magnetic part,
+ but only mark the SSD/Flash part as erased while data is still in
+ there.
+
+ If you can do without password management and are fine with doing
+ physical destruction for permanently deleting data (always after
+ one or several full overwrites!), you can use plain dm-crypt or
+ LUKS.
+
+ If you want or need the original LUKS security features to work,
+ you can use a detached LUKS header and put that on a conventional,
+ magnetic disk. That leaves potentially old encrypted data in the
+ pools on the disk, but otherwise you get LUKS with the same
+ security as on a magnetic disk.
+
+ If you are concerned about your laptop being stolen, you are likely
+ fine using LUKS on an SSD or hybrid drive. An attacker would need
+ to have access to an old passphrase (and the key-slot for this old
+ passphrase would actually need to still be somewhere in the SSD)
+ for your data to be at risk. So unless you pasted your old
+ passphrase all over the Internet or the attacker has knowledge of
+ it from some other source and does a targeted laptop theft to get
+ at your data, you should be fine.
+
+