The backup server is running headless, so I opted to store the key locally for now. Yes, I’m a moron. But hey, at least it’s not on the same medium.

# dd if=/dev/urandom of=/etc/luks.key count=256 ; chmod 600 /etc/luks.key

As long as the disk isn’t the only one, I can’t predict the device name it will come up as. Thus, it is referenced by its udev ID when formatting it with LUKS:

# cryptsetup luksFormat /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 /etc/luks.key

Open the new LUKS device:

# cryptsetup luksOpen -d /etc/luks.key /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 pv_crypt_1

The entry in /etc/crypttab makes the encrypted device come up on boot:

/etc/crypttab:

pv_crypt_1 /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 /etc/luks.key luks

Create a new Physical Volume on the crypted device:

# pvcreate /dev/mapper/pv_crypt_1

Now the Volume Group can be extended with the new PV:

# vgextend datavg /dev/mapper/pv_crypt_1

I rebooted at this point, in order to see if everything would come up as expected.

The new PV is now visible:

# pvs
  PV         VG     Fmt  Attr PSize   PFree
  /dev/dm-0  datavg lvm2 a-   931.51G 931.51G
  /dev/sdb1  datavg lvm2 a-   465.76G      0

The next step is to migrate the VG content to the new PV. Migration will take a very long time if the disk is full, so you may want to use a screen session for this.

# pvmove -v  /dev/sdb1

This is a classical LVM operation that may be cancelled at any time and picked up later. In fact, my Promise SATA driver crashed hard in the middle of the operation, and everything went along fine after a kernel upgrade.

When pvmove is done, throw out the original PV from the volume group:

# vgreduce datavg /dev/sdb1

The Volume Group is now on encrypted storage.

Create the underlying logical volume:
lvcreate -n datalv_crypted -L 1G vg00

Initialize a LUKS crypto device on the logical volume:
cryptsetup luksFormat /dev/vg00/datalv_crypted

If you have lost your mind and want to keep the passphrase in a file (which is what G.’s weirdo client had asked for):
dd if=/dev/urandom of=/etc/i_am_dumb count=256
cryptsetup luksFormat /dev/vg00/datalv_crypted /etc/i_am_dumb

Bring up the crypto device from the encrypted logical volume:
cryptsetup luksOpen /dev/vg00/datalv_crypted data # optionally -d /etc/i_am_dumb

Create a file system on the crypto device, /dev/mapper/data, which has now sprung to life:
mkfs.ext3 /dev/mapper/data

Enter the crypto device in /etc/fstab:
/dev/mapper/data /data ext3 defaults 0 0

Don’t forget to create the mount point:
mkdir /data

Enter the encrypted logical volume in /etc/crypttab. Substitute “none” with /etc/i_am_dumb if you are keeping the passphrase on the system.
data /dev/vg00/datalv_crypted none luks

Reboot. You will be prompted for the passphrase on bootup, unless you’re keeping it in a file. The new file system will be mounted on /data.

The usual process for resizing file systems now has to be extended by an additional step:

lvresize -L +1G /dev/vg00/datalv_crypted
cryptsetup resize /dev/mapper/data
resize2fs /dev/mapper/data

That’s all there is to it. In another installment, I will hopefully write about encrypted physical volumes, allowing live migration of an entire volume group to encrypted storage during full operation.

With the technical details out of the way, some additional words about keeping the passphrase on-disk:

If you work for someone who wants this, he’s not neccessarily an idiot, but maybe just a bit naive. It is your duty as the expert to explain why keeping the passphrase in-band with the encrypted data is nothing more than just a waste of CPU cycles. Seriously. This, G., means you.

While the X.509 standard for e-mail, S/MIME, can safely be considered a generally available standard nowadays, it’s pretty scary to see that certain vendors of encryption software for the enterprise have a very sketchy understanding of what PGP encrypted communication looks like in the real world. They seem to believe that PGP isn’t actually that relevant, while on the other hand, real people and real corporations have been using PGP to protect their (trade) secrets long before those PGP vendors had even been founded.

There are currently three major methods for PGP encryption of e-mail in the wild. One of these is an actual internet standard, one is a customary procedure, and the other, oh well…:

1) PGP/MIME

PGP/MIME is the only official standard for PGP e-mail encryption. It is defined in RFC 3156 (“MIME Security with OpenPGP”). Put simply, PGP/MIME takes the entire MIME encoded message and wraps another MIME layer around it. This “outer” layer contains either the encrypted message or it contains the original MIME encoded message plus an attachment containing the detached signature. PGP/MIME is widely supported by products that integrate e-mail and PGP encryption.

2) “PGP-Inline”

PGP-Inline is a retroactively applied name for the legacy method for PGP encryption that was used in the early days of PGP, before the introduction of PGP/MIME. It does not constitute an actual standard. Instead, there only is a certain behaviour that users have learned to expect from PGP-Inline messages.

A PGP-Inline message contains the message text in ASCII-armored form, either encrypted or clearsigned. It is evident that MIME multipart/alternative e-mails that contain the message text in both text and HTML form can not be handled very well in such an environment.

Attachments are encrypted each on their own. The file example.pdf is attached as example.pdf.asc, example.pdf.gpg or example.pdf.pgp, depending on implementation and user preference. As far as I can tell, there is no accepted standard for signed attachments in PGP-Inline. A well-behaved implementation of PGP-Inline can be observed in the Enigmail plugin for the Thunderbird MUA when PGP/MIME is turned off. This implementation uses detached signatures for signing attachments.

Vendors usually refer to RFC 4880 (“OpenPGP Message Format”) when being asked about PGP-Inline. While having a certain relevance, this RFC does not mention anything related to E-Mail. It is therefore in fact unsuitable as a guideline for the proper behaviour of PGP-Inline. Don’t get fooled by RFC mumbo-jumbo.

3) “Partitioned PGP”

Partitioned PGP can be described as “PGP-Inline with cloaked filenames”. Long after PGP/MIME had been widely accepted as a standard, the PGP corporation introduced their “Universal” product line. PGP Universal extends the commonpractice PGP-Inline method by concealing the filename. Our file example.pdf from the earlier example gets renamed to Attachment.pgp. The original filename is hidden inside the ciphertext in the “Literal Data Packet (Tag 11)” as described by RFC 4880.

Partitioned PGP carries over the original MIME Content-Type tags of Attachments by storing them inside proprietary MIME headers:

X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/html; charset="iso-8859-1"

To my best of knowledge, these extensions are not publicly documented. During my research I have only come across an archived e-mail from a developer at the PGP corporation that outlines the technique. This particular e-mail is my only point of reference when it comes to the technical details of partitioned PGP.

Restoration of these headers and of the original filename has been implemented by all relevant commercial vendors, most likely through a small amount of reverse engineering. The same applies for the HTML part of multipart/alternative messages, which PGP Universal attaches as PGPexch.htm. A skilled developer can easily understand the HTML part’s encoding by closely examining encrypted messages from PGP Universal.

Conclusion

While PGP/MIME will usually be supported by most communication partners, PGP-Inline still has lots of relevance as the lowest common denominator. As such, it should be as interoperable as possible, despite the lack of a hard and fast specification. Users that have no integration of PGP into their e-mail software will resort to exactly those techniques that are usually considered “PGP-Inline”: Encrypt the message, and encrypt each attachment on its own. This is where we all came from, before PGP/MIME.

The PGP corporation claim that their “Partitioned PGP” is identical with PGP-Inline. This is technically true only if a PGP-Inline implementation’s default mode of operation is to extract the original filename. If this is not the case, “Partitioned PGP” yields decrypted files that are named Attachment, Attachment1 and so on, which offer no clue about the original file name. While experienced UNIX users can easily determine the file type using the file command, typical end users have no proper means of handling the situation.

The PGP corporation may have their reasons for extending PGP-Inline in such a way. Cloaking the file name is fairly reasonable indeed. However, PGP/MIME has always been doing exactly the same by wrapping the MIME encoded message with its attachments into an opaque PGP layer. This was standardized and available long before the PGP corporation had even been founded.

I find it not very hard to believe that the manoeuver of extending PGP-Inline in a proprietary way is an attempt to create market share by forcing a de-facto standard into existence. With a big name such as “PGP”, everything seems possible. Also, if the PGP corporation really were that serious about leakage of potential confidential information, they should have taken care of the message headers as well. Instead, they chose to create an amount of incompatibility, that is covered by some RFC and appears to be subtle, but in fact irritates users and support staff on the receiving side in the worst possible way.

There is no doubt that the PGP corporation employs honest cryptography specialists that are a lot smarter than I will ever be, no matter how much I learn. Their marketing and product management departments, however, have created an enormous amount of distrust in me. On one hand, they’ll promise you heaven and earth with their big name and their global presence. On the other hand, they seem to be completely disconnected from the PGP community and appear to not have an idea of how cryptography has always been used in real, day-to-day production environments. Which is a real pity.