Sandforce AES

[Quizzle]

Copy of letter sent to Sandforce. Feel free to comment.

Hello,

I'm interested in the cryptographic features of your SF-1200 and SF-1500 SSD controllers. I have been unable to find any review which discusses these features in detail, and your website barely mentions the features.

Could you explain in detail, or link to a detailed explanation, of your AES implementation? Specifically,

• Which AES mode are you using?
• Which algorithm do you use to create a key from the user supplied password?
• What constants, if any, do you use with these algorithms?
• Is there a way to disable cryptography on the drive, such that a reviewer could view the encrypted data directly in order to verify your encryption implementation? Do you have a software implementation of your cryptography features?
• Are internal data structures such as the free block list encrypted?
• Have any qualified cryptographers reviewed your implementation?

I realize that this may seem like a lot to ask, but I'm not aware of any consumer hardware which has ever done cryptography right. As it stands, your AES feature is of near-zero value to anyone who knows about cryptography, and nobody would buy an SSD for use with cryptographic software due for performance reasons.

As it stands, none of your competitors have cryptographically secure SSD controllers. Show that you've done it right, and make a profit.

 

[DesktopMan]

I'm also very interested in this. Hopefully Anand will cover this in detail at some point.

As for "nobody would buy an SSD for use with cryptographic software due for performance reasons" that's not really a big issue anymore. AES-NI will be introduced in most Intel CPUs in a year or two, and VIA has already had support for years. Even without hardware acceleration I do not have any performance loss with TrueCrypt on my x25-m in an i7 system.

 

[Quizzle]

The problem isn't encryption/decryption speed (although nobody appreciates a CPU hog), but the SSD itself.

If you only write the encrypted form of your files to the SSD, an attacker will be able to clearly see the size of your data, and possibly see older versions of the file (still encrypted). Cryptographers think that this is bad.

Cryptographic software using an SSD can't entirely avoid showing older data (due to 'reserved space' on the SSD), but they can and will fill the entire device to confuse matters. As the entire device is always full, this effectively disables TRIM, and you're left with a small, expensive, slow storage device. A HDD would perform just as well for much less money, hence "nobody would buy an SSD for use with cryptographic software due for performance reasons."

 

[Voo]

And not to forget that encrypted data is obviously more or less completely random data so the SF controller can't compress that very well so it's a rather large performance penalty as well.

Would be really interested in the answer and maybe also a nice AT article - I think you should write a mail to Anand as well, since he surely has better ways to get information about the subject and it'd make a really interesting article.

Also I'm no cryptography expert (well I know how to implement a basic AES in software and good enough why using that would be a horrible, horrible idea in any important application ) so even if they answered all the stuff above I probably wouldn't know what to think of it

 

[DesktopMan]

Quizzle: If you look at the latest Anandtech article here: http://anandtech.com/show/3690/the-...dforce-more-capacity-at-no-performance-loss/2

The performance impact on a drive filled with random data (as would happen with encryption) isn't much to speak of to be honest. It still beats the crap out of any hard drive. Of course, on older SSD controllers it's potentially a lot worse.

 

[DesktopMan]

Voo: You mentioned the compression, I think that's interesting as well. I'd like to see some tests on e.g. copying a 4GB zeroed file to the SSD and see what it behaves like. Does it actually make the saved space available to the OS? I'm having issues seeing how you could do that without a driver. What happens if you request data from the middle of that file? Does it do block wise compression etc etc.

 

[Voo]

No it doesn't make the space available to the OS, it just writes less data to the drive but it still takes up the whole size, so the only benefit is that it is faster. And Anand already tested the performance hit.. for example here: http://www.anandtech.com/show/3681/oczs-vertex-2-special-sauce-sf1200-reviewed/4

 

[jimhsu]

And not to forget that encrypted data is obviously more or less completely random data so the SF controller can't compress that very well so it's a rather large performance penalty as well.

Would be really interested in the answer and maybe also a nice AT article - I think you should write a mail to Anand as well, since he surely has better ways to get information about the subject and it'd make a really interesting article.

Also I'm no cryptography expert (well I know how to implement a basic AES in software and good enough why using that would be a horrible, horrible idea in any important application ) so even if they answered all the stuff above I probably wouldn't know what to think of it

That's why you compress first, then encrypt. The disadvantage is that there is a window of opportunity where the compressed, unencrypted data could be compromised...

 

[DesktopMan]

jimhsu: Surely they have a small internal cache for the compression -> encryption process? Otherwise they'd have to write all data twice, once compressed then once more when encrypting it. Also don't forget the data travels unencrypted to the drive, so if you have physical access all bets are off anyway. (Though that's usually true for any sort of end user encryption.)

Voo: Thanks for the link, I actually read it when it came out but forgot about it. The performance in all categories for truly random data is still better than most SSD offerings (all?). I personally have no issue using e.g. TrueCrypt on a SandForce drive. I doubt they'll ever detail enough of their encryption for people to trust it in general. Too many have been burned by mainstream hardware crypto in the past.

It would also be interesting to see if there is any latency accessing heavily compressed data. This would depend on the compression used of course. With simple RLE compression the block size would be the deciding factor, but I don't know what algorithm they use. The techniques available is a bit limited as random seeking in the compressed stream can't be too slow.

 

[Voo]

That's why you compress first, then encrypt. The disadvantage is that there is a window of opportunity where the compressed, unencrypted data could be compromised...

Well the only way to "compress first then encrypt" is if you use the built in AES and.. that's the whole point of this topic to find out how reliable that is? Also there's always a window of opportunity before you encrypt the data no matter if you do it in software or let the controller do that - so I don't really see any difference there.

 

[Quizzle]

Well DesktopMan, I think you have a point. Newer SSDs have enough over-provisioning and quick enough controllers that they seem to work fairly well even when full. 75% of fast is still fairly quick. I wonder if the drives would perform as well without TRIM, but I suspect that they should.

Where does this leave us? Software solutions break the compression and de-duplication features of SSDs (where available), leave old versions of data behind in the OP section of the drive, use CPU, memory, and system bus resources, and could lose encryption keys to malware. Hardware solutions could be much better, except that nobody ever seems to do it right.

I hope we get a response from Sandforce, and some reviews.

 

[DesktopMan]

Quizzle: The effect of TRIM on a software encrypted drive is actually quite interesting. It will potentially lead to information leak of free space over time, as after all the blocks have been encrypted and you delete something TRIM should still kick inn and clear the blocks belong to that file. This would also mean that the drive is at it's slowest right after the encryption is done, and will become faster as time goes by and TRIM does it's thing. This is assuming the encryption software doesn't disable TRIM of course.