Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 4 down vote accepted

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.

share|improve this answer
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 2: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

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).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.