This article starts off with some inaccurate information right from the onset, so it leaves me with some credibility concerns that incline me to do some of my own testing.
Since Windows 10 1803, both Windows 10 and 11 Home and Pro have automatically enabled Bitlocker Encryption during the Out Of Box Experience (OOBE) as long as the following conditions are met:
The device is UEFI and Secure Boot enabled
The device has a TPM2.0 device that is enabled
There are no un-allowed Direct Memory Access (DMA) capable devices on a DMA capable bus.
The user signed in using a Microsoft Account and had an active internet connection at the time.
It is not specific to Windows 11 and has nothing to do with Home/Pro. This has been going on since 2018.
They also mention encryption built-in to SSDs. That is a fundamentally different kind of encryption. With Bitlocker, removing an SSD from a device or accessing it from anything but the original Windows environment will require the user to enter a 25-digit key to gain data access. Without Bitlocker, the on-disk encryption does not prevent data access in those scenarios. That encryption key exists primarily so that you can secure erase the disk by changing the encryption key. The alternative is a block-level erasure, which would put wear and tear on the SSD.
Pretty disappointing to see this coming from an otherwise reputable source like Tom’s Hardware.
You’re off with your claims about built-in encryption. While there are drives that do what you describe, there are also drives that require a key to be provided to the drive for unlocking it. There’s an entire specification for how the authentication to the hard drive is made at boot or when mounting it.
It sounds like the article is an update to the age old performance issue discussions between hardware and software RAID solutions.
If you use a software solution for anything where there's a dedicated hardware solution, the software solution is always slower due to CPU overhead.
Article recommendation boils down to: If you're going to use encryption, and you want your full disk speed, use a hardware encryption solution. In their test their hardware supported OPAL.
If you set up hardware encryption, be sure to change the master password and set the security level to maximum.
Be aware, this password is different than the Physical Secure ID (PSID) printed on the front of the disk. PSIDs are used when the release to reset command doesn't work, typically due to key issues, and the drive gets "locked".
You use the PSID to run a revert to factory defaults command, unlocking the drive. Since this triggers the drive to release its' key, the drive is considered "cryptographically erased" when you do this.
If you revert the drive, data on it is unrecoverable.
If you're going to revert a drive, I suggest using a QR Code reader to get the PSID off the drive. Some venders are sadists with the font they choose making it so much fun to figure out if it's a 1, l i I I O or 0...
Yeah, I was thinking maybe the data would be written out of order or something, but that wouldn’t be the case. The data will be garbled by the encryption, but still written sequentially, or however the internal drive controller decides is best.
Isn’t it CPU overhead for the encryption? It needs to encrypt like 3-400 MB/s, so it seems pretty reasonable that it’s a lot slower. The drive’s lifespan shouldn’t be affected for any reason I can think of.
Yeah, my SSD can do somewhere around 7GB/s read/write, barely half that with the encryption enabled.
And I have an external USB carry with an NVMe drive which should be perfectly capable of doing the maximum (1GB/s on a USB3.1 port) , but with encryption enabled, it's struggling to do over 350MB/s
That seems odd. You’d expect that if the cpu is doing the encryption and can do 3GB/s for the internal disk then it can do the same for the external one and be limited by the USB or disk speed of 1 GB/s
If it’s a Mac then it’s not the CPU that’s doing the encryption for the internal drive. Macs have separate hardware for that, the CPU can’t even get the key.
Macs have encryption in hardware in the dma channel for their built-in drives (Intel Macs with T2 and all ARM Macs), so the overhead is negligible on the internal ssd. Macs actually don’t even have unencrypted internal drives anymore. The filevault toggle only affects whether the volume encryption key stored in the secure enclave is itself encrypted or not.
Older Macs and external drives are a different story of course.
This is not a reason to prevent switching, quite the opposite. Encryption is an awesome thing, and should always be used. It also inevitably causes slowdowns, but the best case is that it’s practically nonexistent of a performance hit. Not a lot of Linux distros let you set up luks root encryption in the installer, and it’s still pretty tricky to setup. But also if you’re using Linux, you should always be using luks encryption if you can as well.
Add comment