On 29/04/12 05:23, MauMau wrote:
Q2: Is AES-XTS slower than AES-CBC? Does AES-NI speed up AES-XTS
like AES-CBC?
Yes it is slower because there is an additional encryption operation
on the "tweak".
I think AES-NI speeds up the implementation of the underlying AES
cipher, and therefore would be used no matter what the mode (perhaps
one of the openssl developers can confirm??)
To test out the speed implications I knocked together a quick piece
of code to do 1,000,000 AES-256 XTS encryptions of a 4k record
followed by 1,000,000 AES-256 CBC encryptions. XTS took approx. 108s
to run, whilst CBC took approx. 41s to run (on my underpowered netbook).
To put this into perspective that means that XTS took approx. 0.1ms
to encrypt a single 4k record, compared to 0.04ms for CBC. In other
words a 0.06ms performance penalty. Now I don't know what your
application is attempting to do, but I suggest that in most scenarios
that kind of penalty is not going to be noticed, and will probably be
negligible compared to the file i/o.
I really appreciate your performance measurement. I'll also do some
performance testing on a machine with AES-NI.
I'm thinking of placing files on SSD. So 60us difference per block may
be relatively long compared to tehe I/O. Hmm...
To transfer 4k data (random access) from an SSD your looking at a
throughput of between 33Mb/s and 11 Mb/s which equates to 0.12ms -
0.36ms (dependent on the disk).
http://www.tomshardware.com/charts/ssd-charts-2011/AS-SSD-4K-Random-Read,2784.html
If your application is multi-threaded with multiple threads trying to
access the disk at the same time the file IO time will go up as threads
are blocked waiting for the disk. So you may well find the overhead of
the XTS operation is not too bad. Don't forget of course that XTS it
typically used for disk encryption....it is designed for exactly this
purpose.
Something else to consider is key length. Obviously you're going to get
a lot better performance out of AES-128 XTS than you will AES-256 XTS.
Its a performance/security trade off. Whether that trade off is
worthwhile is going to depend a lot on the value of the data that you're
encrypting. See:
http://www.keylength.com/en/4/
The table at the bottom gives you an idea of how long an AES-128 bit key
is likely to remain secure for, i.e. sometime after 2030. Now if you're
protecting sensitive government secrets then that's probably not going
to be good enough. However, if you're protecting volatile data that's
only sensitive for a short period of time then 128 bits is more than
enough. So you have to ask yourself what the impact would be of the
disclosure of your data in 2030. If the answer is not much then the
security/performance trade off might be worth it.
Matt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
