Re: [dm-crypt] Larger encryption requests from dm-crypt

[Arno Wagner <arno@wagner.name>]

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@wagner.name
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