- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
You must log in or register to comment.
Doesn’t really seem like news to me, encryption makes communication slower, that’s pretty standard.
deleted by creator
Most of SSD already has good encryption methods
Unless you purchase a SED-non FIPS or FIPS SSD, no, they don’t
and an easy way to safely wipe data without re-writing each byte.
ATA Secure Erase is a god send for SSD.
deleted by creator
Btw, hw-based encryption is always a compromise betwen security, speed and cost. And holes in the blackbox firmware can only be fixed with updates, as long as supported and if the vendor is willing to.
deleted by creator
You’re routinely reading and writing multi gig files in daily life? O.o Do you work with video editing or something?
I would see myself saying that not long ago, but now a 50GB game is nothing unusual.
True, but you’re limited in many, many ways before the SSD. Downloading the game? Network bottleneck. Playing the game? GPU/CPU bottleneck. (Not to mention, if a game is attempting to access multiple gigs of stored data every second, there’s likely something wrong with that game.)
Installing the game, absolutely. But you only do that once, and I doubt you’re installing a 500GB game daily.
deleted by creator
An 80gb game played in 16gb ram is always going to have work to do.
Yes, the initial install of the game is storage intensive. But again, that happens only once. I doubt you’re doing that very often.
deleted by creator
deleted by creator
… Then you would disable auto adoption of newly connected drives into bitlocker, would you not?
This is like complaining that the login screen pops up every time for a machine that doesn’t need security. Just change the setting instead of complaining about a niche use case.
The majority of users won’t notice a slowdown of even 50% on an SSD. It won’t effect game performance, your network will bottleneck before your SSD in any internet download, most users don’t interact with extremely large sets of data which is needed asap on the regular.
You’re essentially only going to have a problem, in daily use for the average user, in (un)packing large sets of data, or moving large sets of data between drives. Things most people don’t do regularly.
So a slight alteration to my question, how exactly does this negatively affect most users in daily usage.
deleted by creator
SSDs, unless you buy a specifically encryption supported drive, are not encrypted. If it doesn’t indicate SED, SED non-FIPS or a FIPS certification level, the drive doesn’t have an encryption circuit.
deleted by creator
I don’t think you understood my comment. I said nothing about adding more encryption, in fact I said the opposite.
deleted by creator
Sure, but 20-40% slower? That points to something being poorly optimised.
Yes, that’s what happens when there’s no hardware acceleration and it fails back to software.
They should still be using the CPU’s built-in AES hardware acceleration, yes? It seems they have good reason not to trust the SSD to handle the encryption but that doesn’t mean it has to be entirely implemented in software. CPU-accelerated AES shouldn’t be that much slower.
This is the same as all other solutions.
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.
[This comment has been deleted by an automated system]
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…
deleted by creator
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.
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.
What machine are you benchmarking on?
The performance hit is not really notable on the Intel machines with a T2 or the new M1 / M2 silicon.
That said, in googling for benchmarks, theres not really much to find.
deleted by creator
deleted by creator
More reason not to switch. 🙂👍
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.
[This comment has been deleted by an automated system]
24d97f02c8edbbe610fe03e013c4a659
The… need to flip a switch?
I think Granixo is referring to Windows 11, not disk encryption.
Yes, and saying that the need to flip “do the thing” to “don’t do the thing” is a reason to not upgrade to 11.
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.
First thing i do is disable bitlocker. Its PITA when dualbooting too
deleted by creator
With such a severe slowdown, does that also mean it’s going to be increasing usage of the drive and therefore shorten its lifespan?
No, it’s limited by CPU time. The drive neither knows or cares about encryption.
Some drives do, but it doesn’t affect lifespan either way. Writing 10GB of encrypted data is the same as 10GB unencrypted.
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.
This is the best summary I could come up with:
While many SSDs come with hardware-based encryption, which does all the processing directly on the drive, Windows 11 Pro force-enables the software version of BitLocker during installation, without providing a clear way to opt out.
While we have results for higher queue depths, note that the QD1 numbers are far more meaningful in the real world, as this is the most common type of file access in typical operating system environments… and that’s where software BitLocker impacted performance the most.
Lower latency delivers snappier performance in day-to-day use, and it’s the primary reason the industry at large has moved from slow rotating hard drives to faster SSDs.
Given that this extra layer of latency, albeit at varying degrees, will also be added to slower types of SSDs, like QLC or low-tier drives, this could have a much bigger real-world impact in some systems.
Windows 11 disk caching might be a factor there, but QD256 is basically fantasy land for storage workloads (remember, low queue depths are the most common), so we don’t put too much weight on it.
There’s a curious “bump” with the 990 Pro that we’ve noted before on the read speeds, but write performance shows a smoother line with the software BitLocker trailing up until the 256KiB block size.
The original article contains 2,491 words, the summary contains 212 words. Saved 91%. I’m a bot and I’m open source!
