Darren,
> If the encryption is implemented in true hardware in the data path of
> the drive, and if the encryption engine runs faster than the maximum
> data rate of the drive, there is ABSOLUTELY ZERO performance impact,
> contrary to your assertions that in-disk encryption increases the
> latency by 15-20%. OK, maybe I shouldn't say ZERO, because there is
> *some* latency added by the introduction of an AES hardware engine -
> one cipher block's worth. AES-256 requires 14 rounds of encryption
> per cipher block, so assuming one round per clock cycle, and being
> fast enough to keep up with the maximum data rate of the drive, the
> added latency is less than 200 nanoseconds.
I also was surprised by such misleading information especially published by
CTO
of well known and respected company. Unfortunately I wasn't able to post
comment
and ask Mr. Callas how exactly he made the measurements and what products he
used.
Mr. Callas mentioned many terrible things, like AES in ECB mode, latency,
etc.
My guess is that he build his post on older SED products with stand-alone
SATA bridges.
May be it is time to introduce and define the term of generations into SED
products.
SED Gen 1 -- a) encryption is done on PCB, within drive boundary, but
outside SOC
b) has one or more proprietary algorithm for encryption or host
interface
SED Gen 2 -- a) cipher is integrated into data path in SOC and operates on
the speed of data path
b) using approved algorithms (NIST or other standards
institute)
c) follow one or more interface standard (f.e. TCG Opal,
command set by T-13 or T-10).
Dmitry Obukhov,
Samsung Secure Storage
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
