linux-kernel - Re: [RFC PATCH crypto] AES: Add support to Intel AES-NI instructions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 17 Dec 2008 14:39:58 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Huang Ying <ying.huang@...el.com>
Cc:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"linux-crypto@...breakpoint.cc" <linux-crypto@...breakpoint.cc>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [RFC PATCH crypto] AES: Add support to Intel AES-NI instructions

On Wed, Dec 17, 2008 at 11:33:39AM +0800, Huang Ying wrote:
> 
> - Now an AES core block algorithm is implemented with AES-NI as
> CRYPTO_ALG_TYPE_CIPHER, which can benefit all modes (CBC, LRW, etc). But
> because it seems that there is no asynchronous interface for
> CRYPTO_ALG_TYPE_CIPHER, the AES core block algorithm can not use a
> thread to defer real operations.
> 
> - To take full advantage of AES-NI pipeline implementation, at least
> "cbc(aes)", "ecb(aes)" and "ctr(aes)" should be implemented as
> CRYPTO_ALG_TYPE_ABLKCIPHER. So a thread can be used to defer real
> operation upon soft_irq.
> 
> Because the combination that kernel process context FPU usage + soft_irq
> AES usage is fairly rare, I think the above combination is acceptable.
> That is,
> 
> - In AES core block algorithm implementation with AES-NI, use x86_64
> implementation for the combination above.
> 
> - In "cbc(aes)", "ecb(aes)" and "ctr(aes)", use thread deferring for the
> combination above.

Yes that's pretty much what I'd like to see.

Ideally we should implement all the commonly used modes of
oeprations so that the simple AES cipher itself is never used
except on small chunks of data.  However, for now I think doing
just cbc should be sufficient since that's the most common use
case.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/