linux-kernel - Re: Kernel crypto API: cryptoperf performance measurement

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <53F2FA10.2000300@iki.fi>
Date:	Tue, 19 Aug 2014 10:17:36 +0300
From:	Jussi Kivilinna <jussi.kivilinna@....fi>
To:	Stephan Mueller <smueller@...onox.de>, linux-crypto@...r.kernel.org
CC:	linux-kernel@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: Kernel crypto API: cryptoperf performance measurement

Hello,

On 2014-08-17 18:55, Stephan Mueller wrote:
> Hi,
> 
> during playing around with the kernel crypto API, I implemented a performance 
> measurement tool kit for the various kernel crypto API cipher types. The 
> cryptoperf tool kit is provided in [1].
> 
> Comments are welcome.

Your results are quite slow compared to, for example "cryptsetup
benchmark", which uses kernel crypto from userspace.

With Intel i5-2450M (turbo enabled), I get:

#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   524,0 MiB/s  11909,1 MiB/s
 serpent-cbc   128b    60,9 MiB/s   219,4 MiB/s
 twofish-cbc   128b   143,4 MiB/s   240,3 MiB/s
     aes-cbc   256b   330,4 MiB/s  1242,8 MiB/s
 serpent-cbc   256b    66,1 MiB/s   220,3 MiB/s
 twofish-cbc   256b   143,5 MiB/s   221,8 MiB/s
     aes-xts   256b  1268,7 MiB/s  4193,0 MiB/s
 serpent-xts   256b   234,8 MiB/s   224,6 MiB/s
 twofish-xts   256b   253,5 MiB/s   254,7 MiB/s
     aes-xts   512b  2535,0 MiB/s  2945,0 MiB/s
 serpent-xts   512b   274,2 MiB/s   242,3 MiB/s
 twofish-xts   512b   250,0 MiB/s   245,8 MiB/s

> 
> In general, the results are as expected, i.e. the assembler implementations 
> are faster than the pure C implementations. However, there are curious results 
> which probably should be checked by the maintainers of the respective ciphers 
> (hoping that my tool works correctly ;-) ):
> 
> ablkcipher
> ----------
> 
> - cryptd is slower by factor 10 across the board
> 
> blkcipher
> ---------
> 
> - Blowfish x86_64 assembler together with the generic C block chaining modes 
> is significantly slower than Blowfish implemented in generic C
> 
> - Blowfish x86_64 assembler in ECB is significantly slower than generic C 
> Blowfish ECB
> 
> - Serpent assembler implementations are not significantly faster than generic 
> C implementations
> 
> - AES-NI ECB, LRW, CTR is significantly slower than AES i586 assembler.
> 
> - AES-NI ECB, LRW, CTR is not significantly faster than AES generic C
> 

Quite many assembly implementations get speed up from processing
parallel block cipher blocks, which modes of operation that (CTR, XTS,
LWR, CBC(dec)). For small buffer sizes, these implementations will use
the non-parallel implementation of cipher.

-Jussi

> rng
> ---
> 
> - The ANSI X9.31 RNG seems to work massively faster than the underlying AES 
> cipher (by about a factor of 5). I am unsure about the cause of this.
> 
> 
> Caveat
> ------
> 
> Please note that there is one small error which I am unsure how to fix it as 
> documented in the TODO file.
> 
> [1] http://www.chronox.de/cryptoperf.html
> 
--
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/