Seriously? Are you surprised at the speed increase provided by an SSD?
No I’m not, actually I was a little disappointed in my SSDs Performance.
Did you buy a no-Brand SSD from some shady eBay seller?
Well, Kind of… I bought a Dell OEM branded edition of a Samsung PM830 from a reputable eBay seller… in person to avoid ebay charges for him, this drive is reported to be a High performance part by trusted sources. I then used Diskcryptor to provide protection against unauthorised access to my files from konboot, ntpasswd, linux live disks or any other number of NTFS access based attacks.
Ahhh! I know what happened…. your SSD performance was limited by a less capable CPU that could only encrypt at low rate!
Actually, no the laptop hosting this drive has a recent model intel core chip that in benchmarks can easily encrypt twofish at a rate that could saturate the reported 550mb/s max speed of this drive.
After some investigation and what seemed like an endless series of setting tweaks the issue seemed to stem from a problem that plagued the first generations of SSDs…. Wastage due to deleted flash memory blocks not being released cleanly back to the drive controller for reuse. This performance issue was overcome with the introduction of the TRIM command which ‘recycles’ deleted data blocks (explained here and here).
How did the Software based Full Disk Encryption (FDE) intefere with TRIM?
At a low level FDE intercepts file system operations from the Operating system to the Disk and turns them into what looks like random gibberish, so instead of a disk populated with nice sensibly structured file system the stored data looks like nothing comprehensible until the appropriate encryption key is applied (these are usually derived from a password using something like PBKDF2).
This encryption provider that intercepts File system commands is where the performance degradation problem lies (at least in the case of diskcryptor) as it appears to interfere with the operation of the TRIM command.
This could be for many reasons but I would guess that the most likely culprit is that:
The TRIM command issued by the Operating System (OS) provides a set of LBAs where files previously were deleted from, these blocks do not exist as a structure in the FDE container and mapping from the OS specified blocks to the FDE blocks can not happen due to various reasons related to the abstraction of the encrypted data on the SSD into a virtual HDD (e.g potential storage errors due to lack of discreet block level representation of files meaning that a TRIM command would wipe out a block of data representing a segment of the encrypted container and so would have a corrupting effect on subsequent data in that container) so the encryption provider may likely strip the TRIM command out to ensure integrity.
Should you not have known this?
I thought this would have been the case BUT there was so much anecdotal evidence on online forum sites stating that late editions of solutions such as Truecrypt and Diskcryptor would not degrade performance on SSDs so I thought it was worth a check.
On initial encryption the performance was on par with its unencrypted throughput so I thought I had proven the online observations correct in this case.
My blind trust in the then ‘proven’ software solution is also why I spent a lot time looking @ other factors on my beta operating system before removing encryption especially as I installed an Intel chipset driver on this Win 8 edition around the time of the performance degradation and assumed a bug showed its face.
So is it a case of Speed or Security
Happily no, most modern SSD units support some form of strong encryption (e.g the PM830 has AES256, The Intel 320 has AES128 ) that can be ‘enabled’ (this is likely always on as there is no long initial encryption process) by adding a HDD password in the BIOS.
This has one major pro and huge negative:
Pro – The encryption is performed by the SSD controller so there is no host machine performance degradation due to the removal of an encryption overhead.
Con – The HDD password on the Samsung PM830 is 8 characters MAX, much weaker than my previous 37 character diskcryptor password (this is the reason I wanted to used a software approach in the first place).
So whats the outcome
Major laziness on my part came back back to bite me , I should have checked the performance of the software encrypted SSD after filling and then removing data from it and not just shortly after I encrypted it and should not have assumed that the on-line anecdotes and my intital benchmark were correct.
Lesson learned and I am peeling the egg of my face but enjoying my again speedy SSD .