The limit is probably de/encryption speeds. cryptsetup benchmark shows just 3.5 GB/s for my 7640U with aes-xts 256 bit keys. At least for sequential stuff.
I think that is a bit slow since my lowly stone age Skylake Celeron gets 2.3GB/s in that test. Maybe there are some improvements left via future updates.
If you want to use software or hardware encryption depends on your attacker model and your level of trust in the systems TPM implementation. I’ll stay with using LUKS-based software encryption since all my systems are set up that way.
2 Likes
@Kelly_Wu I agree with you, but using hardware encryption seems like such an easy way to gain this perf back. We are buying high end drives for this purpose no?
@halemmerich thanks for the details! It seems that you are talking about software encryption, wouldn’t this be an extra argument towards hardware encryption? Having the drive controller handle it would leave the CPU out of it.
I only want to protect my data in the case of a lost or stolen laptop, I am not interesting enough for the NSA 
1 Like
Yes, the numbers are for software encryption. Any hardware encryption worth its salt should be fast enough to only incur a negligible performance penalty.
Your usecase seems like a prime example for SSD integrated hardware encryption. I like to be able to swap my hardware around and I do not know if that would be possible with a Bitlocker/TPM combination. I configure my systems automatically, so I will keep it all the same, even if it costs a bit of performance. This notebook is the first one where that actually makes a difference, all other SSDs I have are too slow anyway 
1 Like
I just cloned my drive to a new Samsung 990 2tb drive. I am using software encryption. I don’t really want to go through the mess of a reinstall. It might be worth it based on these numbers though. Then again windows 12 might be out in 2024 and that would be a better opportunity for a Clean install anyway.
I tested this with my new AMD and a Samsung 990. Unfortunately, the same result as with my 12 Intel Framework.
The enrolment of hardware Bitlocker works. The test reboot is OK and then the status says “Hardware encrypted”. However, after a further reboot, UEFI no longer finds the boot entry and the disk is inaccessible.
Only a revert with Samsung Magican can make the SSD usable again. I tested this with the current Windows 11.
BTW 11 Core Framework works well with Hardware Bitlocker. However, only until I installed the latest BIOS version. From then on, the error was as described above.
By the way, the performance and battery advantage were enormous.
2 Likes
Always go with software encryption for several reasons. 1) TPM modules do go bad. 2) Self Encrypting Devices always use proprietary crypto, and this crypto gets broken seemingly every year. New device, new crypto, broken by the next year. 3) Software encryption generally uses open/auditable cryptography, i.e. as secure as it can be. 4) Even non state actors are much more savvy than anyone is giving them credit for. Yes they could crack your SED because the how too’s are very public. 5) Real performance benefits are neglibile and so are the battery savings.
3 Likes
+1 to what nadb said.
Plus, for the ultra paranoid, your data is encrypted the moment it leaves the processor. Whereas if you go with SED, the data sent out to the PCIe channel, to the SSD, is not encrypted.
Worth a read (old…but good for background):
1 Like
I absolutely agree with you there and can give even more plus points for software. For example, the monitoring of encryption by an MDM or the automated enrolment of new devices.
However, hardware encryption controlled by BitLocker does not work properly with the firmware and therefore the plus points for hardware encryption are irrelevant for me.
@Heinz-Willi_Eichmeye Thanks a lot for your detailed feedback. I hope we can get this working!
I read in the documentation that the step of disabling “Block SID” in the BIOS could be persistent and had to be reactivated after the first boot following the successful activation of hardware encryption. Could this help you?
Here is a link to the guide in question: How to enable Bitlocker HW encryption with modern SSDs on system drive (e.g. Samsung 980 Pro)
However you might be right and the BIOS might be the problem… When I contacted the support to remove the WD SN850X from my order, I did ask about BIOS support of Bitlocker Hardware Encryption eDrive EIII1667 and here is the answer I got from Framework:
Currently we are not able to provide further details on the Microsoft Bitlocker Hardware Encryption. We’ll be sharing more details soon, certainly be posting updates on the Framework Blog here, as well as providing updates on our Community, Social Media and Mailing list .
I sure hope we get some news before I receive my batch 7! 
@nadb Sure there were some scandals in 2018 that gave hardware encryption a bad reputation, but this seems quite blown our of proportion, no? Has the crypto of the Samsung 990 Pro been broken already? What about the 980 pro that is 3 years old now? I feel fine relying on a proprietary solution from a company like Samsung, who is making products targeted to professionals and has so much to lose.
And regarding the performance benefits, look at the link from this post, they are real and mesured at 11% to 45%!
1 Like
No. Not blown out of proportion. Closed source cryptography is a huge red flag. It has no assurance of meeting even the most basic standards.
Maybe, if not it is just a matter of time.
Just like they have much to lose on release day…except I can’t think of a single Samsung drive in the last 7 years or so that did not have firmware bugs that could, and in many instance did result in data loss. I am certain the same level of care has been heaped upon their cryptography.
More of a Bitlocker problem, i.e. a proprietary cryptography suite that is clearly not very well optimized. If I had the choice between the two, and those were the only options yeah I would think hardware encryption was great, but they are not my only choices…hence my comments. I truly don’t recommend hardware encryption under any conditions, the juice is simply not worth the potential squeeze.
2 Likes
As for theoretical performance of software encryption, phoronix benchmarked LUKS encryption on linux and found only small performance cost: https://www.phoronix.com/review/fedora-38-encryption
2 Likes
If you DO want to use hardware encryption, BestBuy in the US is doing the pre black friday deal for members. They have the Samsung 990 Pro 2TB for $99.99 and the 4tb for $249.99. I am going to order one so I have the option to go either way.
1 Like
My desktop (Ryzen 7 5800x, X570 motherboard - new when the board came out so however long that is), which has an Opal-spec NVMe as the primary boot device and has had since I put it together, on Tuesday of this week decided that the drive partition should be locked and will not unlock it. No prompt for device password, nothing in the BIOS has any effect, and a linux PBA with sedutil-cli can read the drive status but can’t unlock the volume. It’s been encrypted since I put it together and it just decided to… not work. At some point I’ll remove the drive and see if I put into something else if I can at least unlock the drive so I can format it, but I expect I’ll just have to toss it.
Maybe it’s something to keep in mind if you’re going to rely on an Opal drive for your boot device.
1 Like
You can always reset the encryption with the code that’s written on the ssd. This will wipe all the data on the drive but better than just throwing away a perfectly good drive.
Are you sure you are inputting the right password? Keep in mind the sedutil pre boot thing tends to use en-us keyboard layout unless you tell it otherwise which can be a bit tricky last time I tried.
This was my experience as well. I thought I was going nuts until I found this thread. Thanks for posting. IMO this should be a priority bug, as it effectively bricks the SSD on the second reboot unless you know how to work with SEDs, and even then you’re just recovering the drive, not the data. There’s no bitlocker recovery scenario, it just looks to the BIOS like the SSD is gone.
Briked is a bit too strict. Access to the SSD can be restored with a PSID revert. But the content is gone.
1 Like
Might want to keep an eye on this thread, as this doesn’t appear to be supported on the AMD motherboards yet: Issues enabling BitLocker hardware encryption (Windows Encrypted Hard Drive) on AMD 7840
1 Like
I know that and you know that. A lot of people just following guides online about enabling Bitlocker don’t. It disappears from view in the UEFI and unless you start poking it with SED-specific tools, it looks like the drive is dead. Granted, it’s the second reboot after encrypting, so chances are you don’t have any irreplaceable data on there. But it does get pretty frustrating when you’ve spent that time getting the OS installed and patched, and software and accounts configured, only to lose it immediately.
Thanks! I didn’t see that in my search yesterday, I’ll check that thread out.
In this case, Intel and AMD CPU’s are experiencing the same issue when trying to enable and successfully use a Samsung 990Pro with hardware encryption.
Depending on the manufacture date of the SN850X, btw, WD’s spec sheet for it as of a few years ago changed to specify that it is Opal 2.01 compliant – meaning it has HW encryption. Wasn’t on the first run’s spec sheet; don’t know if that means it didn’t have it or it was just an oversight. A lot of online reviews do reflect the info from its first release, though.
Blows my mind a little that people keep citing a 5yo study on the subject of HW drive encryption that was explicitly taken on (as in: they say it in the study) due to inherent weaknesses in software drive encryption…
Yes, btw, the concerns are overblown. The issues from 5y ago had nothing to do with proprietary encryption (neither AES nor the Opal framework are proprietary to any HW vendor), and involved either firmware or hardware sideband attacks usually against either low-level drive commands or key acquisition methods. Put simply: when the attacker would need to create a custom JTAG rig to manually insert custom machine code into the key check to read drive data, your security is less likely to hinge on your drive and more likely to hinge on the fact that you’re running a Windows machine whose user credentials are still ridiculously easy to crack/bypass when you have physical access to it. Serious concern back then for MIL-SPEC stuff, not a serious concern for folks for example happy enough with LUKS or VeraCrypt as sufficient security. (I, for one, thought LUKS was fine for my needs back then, and HW encryption even more so – my security needs were limited to attacks of much lower sophistication than the ones in the paper, and a RAM dump is much easier to pull than any of the methods they used.)
Fortunately I worked in the field then, so it was a little easier for me to ignore the Internet tizzy calling HW encryption worthless as a result of the paper. Same snot as it always is: if you need security, layer your security and don’t rely on one silver bullet for it. There is no absolute to security; nothing is full-stop “secure.” Some flawless drive encryption mechanism could come out tomorrow and that’ll still be as true then as it is now.
2 Likes