blog: Add financial Results for 2015
[gnupg-doc.git] / misc / blog.gnupg.org / 20131215-gcrypt-bench.org
1 # About Libgcrypt 1.6 performance
2 #+STARTUP: showall
3 #+AUTHOR: Werner Koch
4 #+DATE: 15th December 2013
5
6 # We do not want any fancy layout of the charts.
7 #+HTML:<style>
8 #+HTML:  <!--/*--><![CDATA[/*><!--*/
9 #+HTML:  .figure { border: none; margin: 0 0 0 0;
10 #+HTML:            padding: 0; text-align: left;  }
11 #+HTML:  div.figure { float: none; }
12 #+HTML:  /*]]>*/-->
13 #+HTML:</style>
14
15 ** Speedups in Libgcrypt 1.6
16
17    Libgcrypt is a building block of modern GnuPG versions (GnuPG 2.x)
18    and also used by a wide range of other projects.  In fact all Linux
19    distributions install Libgcrypt by default.
20
21    One problem with Libgcrypt has always been that it did not deliver
22    top performance compared to OpenSSL.  Even another GNU crypto
23    library, Nettle, is in some areas faster.  The reason for this is
24    that Libgcrypt was based on an old GnuPG version.  Back in the
25    1990s performance was not the first aim for free crypto software.
26    The crypto authors haved been treated as arms trafficker in the US
27    and not allowed to freely distribute their code.  Thus the primary
28    goal was to write free crypto code in one of the free countries.
29    Further, patents severely hindered the use of crypto algorithms.
30    This together may explain why top performance was not an issue at
31    that time.  Over the years this changed to the better.  However,
32    free software development is mostly driven by user demand and there
33    was not much demand for a faster GnuPG.  Thus we did not care much
34    on speeding up Libgcrypt.  Well, basic support for VIA and Intel
35    CPU accelerated encryption features was eventually added but still
36    lots of other things could have been optimized.
37
38    Last year, Jussi Kivilinna joined the team and started to add CPU
39    optimized implementations of common cipher algorithms.  This
40    changed the picture for cipher and hash algorithms.  The soon to be
41    released Libgcrypt 1.6 is now up to modern standards on what can be
42    achieved on general purpose CPUs.
43
44    To check how 1.6.0 will compare to the older 1.5 version of
45    Libgcrypt, I did some benchmarks using a Thinkpad X220 which
46    features an i5-2410M processor at 2.3GHz running a 64 bit Debian
47    Wheezy.  Default compiler options have been used.
48
49    First let us see how hash algorithms compare (click to enlarge):
50
51    [[file:img/libgcrypt-1.6.0-hash-bench.png][file:img/libgcrypt-1.6.0-hash-bench_s.png]]
52
53    The olive bars indicate how many bytes can be hashed by version
54    1.5.3, the green bar gives the figure for the new 1.6.0, and
55    finally for some algorithms the hatched bar to what Nettle 2.7 is
56    up to.
57
58    The number for the completely insecure MD4 algorithms is way to
59    high (~750 MiB/s) to be included in this chart, thus it has been
60    capped.  For MD5 the old Libgcrypt is faster.  This is a bit
61    surprising but we have not researched the reason; anyway, MD5 shall
62    not be used by today's software because it has been completely
63    broken.  For most of the other algorithm the performance figures
64    are all quite similar.  For the important SHA-1 algorithm 1.6 gains
65    top speed of all compared implementations and further speedups are
66    expected in future versions.
67
68    The major improvements are for SHA-256 and SHA-512 (SHA-384 is a
69    basically SHA-512 with a truncated digest).  The use of Intel
70    provided code which utilizes SSSE3 clearly boosts the performance
71    on this machine and probably on a wide range of other modern Intel
72    CPUs.
73
74    All hash functions are a target for more optimization in
75    forthcoming versions of Libgcrypt.
76
77    Now what about cipher algorithms?  Have a look at this chart:
78
79    [[file:img/libgcrypt-1.6.0-cipher-bench.png][file:img/libgcrypt-1.6.0-cipher-bench_s.png]]
80
81    First, you notice that we have a lot of algorithms here.  The
82    benchmarks are all done for ECM mode encryption.
83
84    There are two extremes here: 3DES is by far the slowest algorithm.
85    It is also the oldest one but still considered rock solid.  In the
86    top performance range we see two algorithms: Arcfour (sometimes
87    called RC4), which is a simple, hard to correctly use, and worse
88    broken design which unfortunately is still used at a lot of places.
89    Even outperforming that are the modern Salsa algorithms, which are
90    considered strong and trustworthy.  They peak at about 750 MiB/s
91    and 1150 for the reduced round SalsaR12 variant.  Both are easy to
92    use stream ciphers.
93
94    The Serpent (an AES competition final candidate) and Camellia
95    (preferred in Japan) ciphers are in the same performance range for
96    1.5 but with the improvements of 1.6 Camellia gets close to the
97    performance of AES under 1.5.  Jussi put a lot of work into fine
98    tuning AES in 1.6.  Thus even with AES-NI hardware acceleration
99    disabled (as shown here) the throughput for AES encryption has been
100    doubled.
101
102    Given that AES is the standard encryption algorithms today, it is
103    worth to have a closer look at AES under different modes of
104    operation.
105
106    [[file:img/libgcrypt-1.6.0-aes-bench.png][file:img/libgcrypt-1.6.0-aes-bench_s.png]]
107
108    For each encryption mode you see three groups of bars; one for each
109    cipher size.  The first group is for Libgcrypt 1.5, the second for
110    1.6, and the third for Nettle.  Note that only 1.6 implements all
111    modes.
112
113    It is quite obvious that the throughput available with 1.6 is way
114    better than with 1.5 and also considerable higher than with Nettle.
115
116    Finally we have a look at the performance of AES-NI acceleration:
117
118    [[file:img/libgcrypt-1.6.0-aesni-bench.png][file:img/libgcrypt-1.6.0-aesni-bench_s.png]]
119
120    This time we have no values for Nettle.  If you take the different
121    scale in consideration it is quite clear how hardware supported
122    acceleration can boost performance.  However, we can‘t be sure
123    whether the CPU has been backdoored to leak key bits.
124
125    The actual numbers have been collected using the bench-slope test
126    program from Libgcrypt and the Nettle benchmark.  They are
127    available in a Gnumeric [[file:data/gcrypt-bench-x220-2300.gnumeric][spreadsheet]].
128
129    Jussi did a another set of benchmarks which include figures for
130    OpenSSL; you find them [[http://koti.kapsi.fi/~jukivili/gcrypt/haswell-3200-ubuntu-saucy-gcrypt.pdf][here]].  He did them using a modified version
131    of a 2008 [[http://panthema.net/2008/0714-cryptography-speedtest-comparison/][speedtest comparison]].  He compared OpenSSL 1.0.1e,
132    Libgcrypt-1.5, Libgcrypt-1.6 (ECB & CTR), and Nettle (2.7.1) on
133    Intel Haswell.  Used key sizes were 256 bit or shorter if 256 bit
134    is not supported.  Each measurement did a key setup for encryption,
135    the encryption, a key setup for decryption, and the decryption all
136    for different buffer lengths.