1
When encrypting devices it is always recommended to fill it with random data first, or it would become evident that the drive is encrypted and how much encrypted data there is. I've read that on an SSD this can cause performance problems since there are no empty blocks where the drive can quickly write to.
Would TRIM help in this situation? Is it recommended to leave some zeroed out space anyway?
However, TRIM cannot be used without security implications. Linux has a pretty good TRIM support for SSDs , but it is known that enabling TRIM on encrypted drives may give away both the size and the type of the filesystem that is being encrypted. According to the wiki, one must either accept the loss of performance or the loss of security.
Would setting up a RAID0 with TRIM support perhaps help giving the best of both worlds?
famyse
Posted 2016-07-18T22:19:08.950
Reputation: 11
What you read isn't correct. Random data is random, in any event the size of the SDD is on a label on the SSD, so does it matter? Encrypting the device before any data is on it is the only safe way to protect data from the over provisioning nature of SSDs. Just because it's random data does not mean its encrypted. – Ramhound – 2016-07-18T22:53:04.843
If you are going to enable discard (TRIM), you probably don't want to random fill it, since most SSD will "returns zero" after TRIM, either fully or partially. Otherwise just leave discard off. – Tom Yan – 2016-07-19T10:17:28.310
@bwDraco hardware encryption doesn't work that way. It's an "always on" thing and it mainly aim at providing a quick secure method of full disk wiping (regen crypto key). It does NOT have any relation with ATA "user password" (Security feature set). Neither would it necessarily make the data or password more secure. (Though the more recent TCG Opal thing might be a different story) – Tom Yan – 2016-07-19T10:24:35.017
@TonYan: Sure, hardware encryption is technically always on. However, as far as I can tell, Samsung SSDs do in fact tie the ATA user password to the encryption system: at a minimum, it locks out the drive, and most likely, setting a password encrypts the key itself and the drive cannot be accessed without the correct password. – bwDraco – 2016-07-19T12:58:36.383
@bwDraco setting ATA user password (i.e. enabling the ATA Security feature set) on ANY drive will locks out the drive, no matter if it supports encryption or not. Since the encryption key is always used automatically to decrypt the data, if someone is capable of bypassing the Security feature set / password, no extra effort to decrypt the data may be needed. Unless you notice that when you enable/disable (not unlock though) the user password, all the data on the disk will be wiped, there is no way the encryption is tied to the feature set. – Tom Yan – 2016-07-19T14:26:50.353
@TomYan: That's not how it works. As you've noted, the drive is always encrypting. When no password is set, the encryption key is stored in the clear on the drive firmware. When you set a password, the key itself is encrypted with the password; entering the password decrypts the key allowing the data on the drive to be accessed. This means that setting a password does not require the drive to be wiped; only resetting the password would render the data unreadable. – bwDraco – 2016-07-19T14:49:04.267
@bwDraco "Using a password to encrypt an encryption key" probably never make sense in ANY context; and if it's really implemented that way, it's not gonna be (much more) secure anyway, since all you need to do is still just crack the password. – Tom Yan – 2016-07-19T15:08:05.843
@TomYan: This is in fact the way most password-based SEDs work. Besides, ATA security does provide some measure of brute-force protection: by default, five consecutive failed attempts will cause the drive to require a power cycle before further attempts are accepted. – bwDraco – 2016-07-19T15:14:52.277