On Wed, Mar 25, 2015 at 21:51:42 CET, Milan Broz wrote: > On 03/25/2015 09:01 PM, Martin Hicks wrote: > > > > Hi, > > > > I figured that I'd push this patch to the list for comments. This stems > > from recent work on the linux-crypto/linuxppc-dev lists regarding > > AES-XTS support for the Freescale Talitos engine. The background can be > > found in this message and the rest of the thread: > > > > http://marc.info/?l=linux-crypto-vger&m=142533320730893&w=2 > > > > The AES-XTS mode in Talitos allows sending a starting IV (usually sector > > #), and the hardware increments this as new sectors are > > encrypted/decrypted. This allowed me to investigate not only > > dispatching 4kB IOs, but also to extend the scatter/gather lists to > > include as much IO as Talitos can handle in a single request (64kB - 1, > > or rounding down, 60kB). > > > > The original performance numbers that I quoted follow, with the extra > > larger-IO up to 60kB line: > > > > Write (MB/s) Read (MB/s) > > Unencrypted 140 176 > > aes-xts-plain64 4kB 113 115 > > aes-xts-plain64 512b 71 56 > > aes-xts-plain64 60kB 120 132 > > > > with IOs up to 60kB, the performance is even closer to the un-encrypted > > values. > > > > It's certainly not a pretty patch, but as a proof of concept it does > > work. I avoided the IV issues by just ifdeffing them out... > > Hi, > > Well, I already commented it on that thread. > http://marc.info/?l=linuxppc-embedded&m=142530788521032&w=2 [...] > (Why it is so slow for 512bytes sectors? Isn't it problem of hw? > The overhead should not be such high...) I am wondering that too. This hardware may have a really, really slow key-setup, far slower than the crypto merits. Would not be the first time that non-crypto people messed something like this up by faulty assumptions on how things are used. As to working with that, the right way to do this would be to check in the crypto hardware driver whether a new block just does the sector increment and then bypass the full key-setup in favor of the hardware increment, i.e. functionally this should be completely transparent to any user of AES-XTS. Of course, such key and IV caching in the driver may compromise some security aspects. Always remember that in crypto, it is better to explicitely not give the user security than to compromise security for a performance optimization. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
