I've got an LTO5 tape that was backed up using Backup Exec (BE), which used hardware compression when writing to the tape. I've been given the passphrase that BE used to create the actual encryption key, so I can access and restore the tape's file backup sessions without any issues. But there are online database sessions on there too, and these are not so easily restored without replicating the original database environment.

Now, I have 3rd party tools that will do the job for me, but they won't work with encrypted tapes. So I want to use Linux' stenc utility to enable me to read the decrypted data from the tape so I can copy the tape to an unencrypted one, but to do so I need to give stenc the actual key that BE uses.... but BE stores keys in encrypted form and will not export them.

I know LTO drives use AES-256 GCM encryption. Every key generator I've seen uses a "salt" along with the passphrase to generate AES-256 keys. The various versions of BE that I've used will all read the tape once I've used their key management process to create the key using the passphrase, so this implies (to me, at least) that either they're generating the key without a salt, or are using the same salt across installations.

Is there a way to generate a key for AES GCM without a salt? I must admit that I'm an encryption newb so forgive me if this is a nonsensical question.

  • $\begingroup$ It seems to me that you'd either need to find some documentation about the key derivation scheme used by the software, or reverse engineer it yourself. Either way, I doubt we can really help. $\endgroup$ – Ilmari Karonen Jul 17 '19 at 21:22
  • $\begingroup$ And yes, there are ways to generate AES keys from a passphrase without using a salt. In particular, you could take any key derivation scheme that uses a salt, and just make the salt a fixed constant. (Whether you'd want to do that or not depends on the circumstances, but it's not necessarily an obviously awful thing to do.) Or you could just use the (first 32 bytes of) the passphrase directly as the AES key (which is not recommended, but may be adequately secure for some purposes). Or you could just use a random salt and store it on the tape; are you sure your software isn't doing that? $\endgroup$ – Ilmari Karonen Jul 17 '19 at 21:29
  • $\begingroup$ If they are using a salt, then it's the same one across time, as all their encrypted tapes are readable by later versions of BE if you have the right passphrase. For AES-256 they demand a passphrase that's at least 16 characters long, so if they are just using that, I'm guessing they're repeating it (or padding it with nulls or something else). I actually had a look at using WinDbg to see what was going on in the code but there's a pretty steep learning curve to get your head around debugging an exe or running process without symbols. $\endgroup$ – GeoLIb Jul 20 '19 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.