In June 2010 - a
reader asked some good questions about notebook SSD encryption. Did it impact
performance and endurance? Had I already written about this in an article he had
missed?Editor:- On the contrary. My comments about encryption are
scattered
to the winds. So I'm going to use the opportunity of your question to fix
that.

The performance hit of SSD encryption depends how and where it's done.

Ideally if encryption is done by the SSD controller there can
be zero performance impact on writes.

That's because there's already a lot of
stuff going on with data
integrity management,
dynamic wear
leveling and garbage
collection. Encryption can be regarded as just one more algorithm which is
relatively simple compared to the other internal housekeeping activities.
Until the erase write takes place - there's a lot of address look ups and
logical to physical translations. That's why encryption can be a minimal
performance or endurance
overhead in a well designed SSD. But - as we know - most SSD designers today
are new to this market
and still learning their trade.

The only downside of internally encrypted SSDs (apart from
cost) is that if
the mapping tables get trashed (due to a physical fault) it is virtually
impossible to do a data
recovery. But then again - the type of people who use encrypted notebook
drives - probably do adequate
backups too.

On the other hand - if encryption is done by the OS - the
performance result will vary according to the internal design. It will range
from minimal to severe - depending on how well the internal
controller manages
write attenuation (and recognizes consecutive writes to small address spaces).
Another performance factor will come from the size of the RAM cache. (Depends
too on the vintage of the controller.) Despite that - some
skinny SSDs
(zero RAM cache) have good write attenuation - so don't need
RAM to deal with small
consecutive writes to the same space. As a rule of thumb - the lower the write
IOPS of the
SSD - the more likely it is that OS driven encryption will negatively impact
performance.

It's essential in my view to have encryption in a
notebook because they are easy to lose.

USB
flash sticks with internal encryption, on the other hand, can have appalling
write performance. They're different to SSDs insofar as a
true SSD
needs to have a good controller (fast embedded microprocessor and ASIC) whereas
in a "flash storage"
device there is zero wear leveling and so nearly all the cost of the encryption
processor simply goes into making the device more expensive.

Designers of USB flash sticks work in a very price competitive market.
That means the encryption processor will be as cheap and slow as possible -
because it's not part of the spec that users look at closely. Also encrypted
USB flash sticks are primarily used as backups. The user isn't expected to sit
and wait for the operation to complete - which means product marketers can
argue a case for saying performance doesn't matter so much.

Also new in this controller generation is support
for sector sizes additional to 512-bytes e.g., 520, 524, 528, 4K, etc., with
Data Integrity Field (DIF) for true enterprise-class SAS drive behavior and
performance.

Editor's comments:- one simple way of looking at
the SF-2000 would be as an incremental x2 version of what SandForce has
done before - which also demonstrates that the glass ceiling for their
architecture is much higher than some people might have thought.

In a
briefing yesterday I asked about the data recoverability of the SSDs based on
the new controllers - while acknowledging that the market it was aimed at - the
datacenter- does adequate backups so DR shouldn't be necessary.

Kent Smith, Director of
Product Marketing, SandForce told me that in this family of SSD controllers -
the company would be moving even closer towards what already exists in
military SSDs - and
offering the option of having on board
data sanitization.

The data in SF-2000 driven SSDs is double encrypted (encrypted on
the way in from the SATA controller and then encrypted again as it is written to
the flash array. The company's view is that it would be impossible for a DR
company to reconstruct data from the flash chips in the SSD without having
access to the SSD oem's unique key generation technology. (The oem has the
ability to do this as a one time programmable function.) Without that data -
even SandForce would be unable to read the contents of the SSD.

These technologies are
designed to make customer data secure. It would be possible for SSD oems to
select DR partners to whom they entrusted their own keys - but that's a
business decision for the SSD maker. Proliferation of such data is likely to be
restricted - because otherwise it defeats the security of the product.