LUKS encryption for tape media?

Question

I was wondering, if it was possible to use LUKS encryption with tape drives, QIC for instance.

I'm using LUKS for USB drives and internal disks, even DVDs and CDROMs. But I was thinking of maybe using it to encrypt tape drives as well.

Should I just use cryptsetup luksFormat directly to the tape drive and then enable the device with cryptsetup luksOpen?

score 7 · Accepted Answer · answered Sep 22 '11 at 01:38

7

You are unlikely to be happy with the huge latencies introduced by LUKS on linear media. A better idea is to pipe the output of tar through OpenSSL, encrypting it with a streaming cipher, before sending it to the tape device.

answered Sep 22 '11 at 01:38

Ignacio Vazquez-Abrams

44,857
7
93
100

Sounds reasonable, and I was looking into how I'd do that. When using `tar`, I use xz encryption (`J`). How should I couple that with `openssl rc4`? The Idea is, that files get compressed before being encrypted and written to tape. Now, since `tar` takes care of encryption and device handling, how should I loop that through `openssl`? – polemon Sep 24 '11 at 22:51
XZ is compression, not encryption. `tar ... | openssl ... > /dev/XXtXX` – Ignacio Vazquez-Abrams Sep 25 '11 at 02:40
I ment XZ compression sorry. When simply writing to the device, I can only read and write the device, but what if I want to extract just one file, or read the contens (`tar t`)? – polemon Sep 25 '11 at 10:26
`openssl ... < /dev/XXtXX | tar ...` – Ignacio Vazquez-Abrams Sep 25 '11 at 16:16

score 4 · Answer 2 · answered Sep 22 '11 at 09:06

Tape devices are not suited for random access (they don't provide random-access), i.e. they are not block devices. And LUKS is designed for block devices, like e.g. XFS is a filesystem for block devices. You can't mkfs.xfs on a tape device, can you?

Thus, go with the OpenSSL streaming cipher encryption via pipe approach, like suggested by Ignacio.

Similar to the design of LUKS, you could generate a large random key for the streaming encryption which you then encrypt as file e.g. with gpg. That means you are flexible to change this 'envelope-key' and you could encrypt the 1st key with multiple public keys, such that multiple persons have access to it (without the need of a perhaps insecure key-exchange).

score 0 · Answer 3 · answered May 15 '17 at 14:06

Not an answer to your question, but an alternative suggestion for encrypting a tape backup.

You could use the FUSE filesystem encfs in reverse to mount a local path to a special folder, where the contents of that folder are on-the-fly encrypted versions of the source path. If you tar that folder, you'll be writing an archive of encrypted files.

When the time comes to restore the data, extract it to a folder, run encfs normally, and then you will be able to see all your original files.

The main drawback with this method is that the filenames are also encrypted, so you are unlikely to be able to restore just a few files from tape - you'll have to read the full tape back onto local disk, copy the decrypted files you need, then delete it all again.

An advantage is that tar only sees normal files, so its multi-volume handling will work well and split files across tapes. You can even restore one tape (or do a partial restore) as encfs files are self-contained (one encrypted file matches one real file), so no matter how many or how few encrypted files you get back off the tape, those files will be able to be decrypted. You just won't know what the filenames are until after you've copied them off the tape.

LUKS encryption for tape media?

3 Answers3