The Kingston Data Traveller Vault Privacy USB drive has a default amount of 10 password entries before it is erased. I am left with one and the question is whether any of the following two approaches will allow me to excercise more attempts to type the password (I should know the correct one, it's just been a long time since I have set it up). I do not intend to brute force it.

  1. copy the encrypted data from the drive and perform decryption outside the drive

  2. copy the encrypted data as a backup, enter the password on the drive, allow it to format itself and then copy the backuped data onto the drive again

  3. learn the AES representation of the stored password and try to guess the password outside the drive's environment and put in the correct password only after the matching AES representation has been found

  4. any other ideas?


1 Answer 1


The "correct" way to implement hardware encryption on a flash memory device is to encrypt with a key stored in an inaccessible part of the device, which is itself encrypted with the user password. This means that the device can be "wiped" simply by wiping the key and replacing it with another one. The reason for this is in how flash memory devices work: they are built with some spare capacity which is used to compensate for individual memory elements failing or wearing out through the expected lifetime of the device. However, this also means that data may exist on sectors which are no longer writable, so it wouldn't be possible to securely wipe them. This isn't a major problem if the entire device is encrypted - the remaining data, even if it can be extracted from the non-writable sectors, is encrypted, so remains secure. By removing and replacing the key, the data can effectively be rendered unreadable, without increasing the load on the flash memory with extra writes.

If a device instead encrypts based directly on the user input, you can't avoid the extra writes - you can't just forget the key, since the user has it, and may have left it lying around elsewhere, where some malicious person can find it and use it to decrypt the data.

The result of all this is that if a manufacturer has constructed their drive in the "correct" way, the password you enter is only used to decrypt the key which is used for the rest of the data. Since this is intentionally inaccessible, you can't usually extract it for offline brute forcing, even if you can extract the rest of the data on the device. It also means that brute forcing the actual key used doesn't mean working out the relatively short password that you'd enter, but instead working out the internal key, which could well be much longer - even something relatively insecure, like a SHA-256 hash of the word "password" would be 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8. That's infeasible to brute force when you don't know the key length or composition...

Now, it's possible that the manufacturer has implemented a different method, where the input is directly used to encrypt the data, but the steps outlined above are pretty well known and, given a reasonably secure key store on the device, really difficult to break.

I'd say that the data on that device is probably gone, unless you get lucky with the last try...

  • Why would the key be stored in "an inaccessible part of the device"? How can it be inaccessible? Great and detailed answer, but I still wonder if it is possible to either 1. save dump from the device, try password and set the device up again with a new password, hoping it is the same and load the encrypted data again 2. save data from both the device and the encrypted key in an inaccessible part and try loading it again after device has been set up; I was hoping it would be somehow similar to cracking the iPhone where flash memory has been cloned and loaded again to repeat the attack. Commented Feb 25, 2017 at 17:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .