Offhand, I'm thinking that if your using the entire device (
/dev/sdb) and your LUKS header is at the start of the drive, and if some other tool or OS "helpfully" decides that your disk is unformatted with no MBR or GPT, if it were to overwrite your LUKS header that would be bad. If you were using a partition for LUKS then at least a new MBR or GPT wouldn't be as devastating.
You should always backup the LUKS header anyway, as the
cryptsetup man page advises too.
And this is what the cryptsetup FAQ says about using "2.2 LUKS on partitions or on raw disks?" (it's long but I'll just paste it, mentions RAID & LVM can greatly complicate things, you may want to rethink using LVM on top of LUKS):
This is a complicated question, and made more so by the availability of RAID and LVM. I will try to give some scenarios and
discuss advantages and disadvantages. Note that I say LUKS for
simplicity, but you can do all the things described with plain
dm-crypt as well. Also note that your specific scenario may be so
special that most or even all things I say below do not apply.
Be aware that if you add LVM into the mix, things can get very complicated. Same with RAID but less so. In particular, data recovery
can get exceedingly difficult. Only do so if you have a really good
reason and always remember KISS is what separates an engineer from an
amateur. Of course, if you really need the added complexity, KISS is
satisfied. But be very sure as there is a price to pay for it. In
engineering, complexity is always the enemy and needs to be fought
without mercy when encountered.
Also consider using RAID instead of LVM, as at least with the old superblock format 0.90, the RAID superblock is in the place (end of
disk) where the risk of it permanently damaging the LUKS header is
smallest and you can have your array assembled by the RAID controller
(i.e. the kernel), as it should be. Use partition type 0xfd for that.
I recommend staying away from superblock formats 1.0, 1.1 and 1.2
unless you really need them. Be aware that you lose autodetection with
them and have to fall back to some user-space script to do it.
(1) Encrypted partition: Just make a partition to your liking, and put LUKS on top of it and a filesystem into the LUKS container. This
gives you isolation of differently-tasked data areas, just as ordinary
partitioning does. You can have confidential data, non-confidential
data, data for some specific applications, user-homes, root, etc.
Advantages are simplicity as there is a 1:1 mapping between partitions
and filesystems, clear security functionality and the ability to
separate data into different, independent (!) containers.
Note that you cannot do this for encrypted root, that requires an initrd. On the other hand, an initrd is about as vulnerable to a
competent attacker as a non-encrypted root, so there really is no
security advantage to doing it that way. An attacker that wants to
compromise your system will just compromise the initrd or the kernel
itself. The better way to deal with this is to make sure the root
partition does not store any critical data and move that to additional
encrypted partitions. If you really are concerned your root partition
may be sabotaged by somebody with physical access (that would however
strangely not, say, sabotage your BIOS, keyboard, etc.), protect it in
some other way. The PC is just not set-up for a really secure
boot-chain (whatever some people may claim).
(2) Fully encrypted raw block device: For this, put LUKS on the raw device (e.g. /dev/sdb) and put a filesystem into the LUKS
container, no partitioning whatsoever involved. This is very suitable
for things like external USB disks used for backups or offline
(3) Encrypted RAID: Create your RAID from partitions and/or full devices. Put LUKS on top of the RAID device, just if it were an
ordinary block device. Applications are just the same as above, but
you get redundancy. (Side note as many people seem to be unaware of
it: You can do RAID1 with an arbitrary number of components in Linux.)
See also Item 2.8.
(4) Now, some people advocate doing the encryption below the RAID layer. That has several serious problems. One is that suddenly
debugging RAID issues becomes much harder. You cannot do automatic
RAID assembly anymore. You need to keep the encryption keys for the
components in sync or manage them somehow. The only possible advantage
is that things may run a little faster as more CPUs do the encryption,
but if speed is a priority over security and simplicity, you are doing
this wrong anyways. A good way to mitigate a speed issue is to get a
CPU that does hardware AES.