Using OpenSSL to emulate LTO 4 tape encryption

I have a mix of LTO 4 and LTO 3 tapes I would like to encrypt data on to. LTO 4 has built in encryption - load they key into the drive, and it handles the AES-256-GCM encyption transparently. LTO 3 has no such facility. Ideally I'd like to use some encryption software that I can pipe the tar archive through while not having to expand my current key managment scheme beyond tracking only 256 bit keys.

Assuming OpenSSL is the ideal way to do this, I'm hoping for advice on what the best way to do it would be. It can be assumed that a key will only be used once, when a tape is overwritten a new key is made and the old one destroyed.

1. I'm a little worried about using a salt since data loss on the tape could destroy it, rendering all the data lost as opposed to losing 1 file if the corruption is somewhere else.

2. With LTO 4 the 256 bit key is loaded directly as the key. In OpenSSL if I manually specify the key I have to worry about the IV too. Should the IV be derived from they (ie a hash), or should I use the key as the password and let OpenSSL derive a its own key/IV?

• OpenSSL is not a key management scheme. A salt is generally only used for hashing. If the drive performs the encryption then an IV is likely generated by the AES algorithm implementation by the drive. As it currently stands I'm not sure this question can be answered. – Maarten Bodewes Feb 11 '18 at 1:11
• @MaartenBodewes I didn't mean to suggest OpenSSL as a key manager. I mean that I have a key management scheme centered around 256 bit keys and want to fit OpenSSL into that for tar encryption. – chew socks Feb 11 '18 at 1:31
• I mentioned the salt because the man page (and other places) recommend the salt, and because it is the default when password based encryption is done in openssl enc. I don't believe there is any salting when the key and IV are manually set. – chew socks Feb 11 '18 at 1:33