Authenticated-Encryption Software Performance:
Comparison of CCM, GCM, and OCB

• Click on a Time or Overhead plot to see a larger version of it.
• Click on a Mode (CCM, GCM, OCB, etc) to retrieve the raw data.
• Here OCB means OCB3. A companion webpage compares the performance of OCB variants.
• Further notes can be found on the bottom of this page.

Environment (details)	Time (cpb vs. bytes)	Overhead (subtract time for CTR)	Mode (clickable)	Over 4096	Time 4096	IPI (cpb)	Size (bytes)	Init (cycles)
Intel x86 i5-650 “Clarkdale” 64-bit NI			CCM  GCM  OCB  CTR	2.90  2.46  0.21	4.17  3.73  1.48  1.27	4.57  4.53  1.87  1.37	512  656  624  244	265  337  295  115
Intel x86 i5-650 “Clarkdale” 32-bit NI			CCM  GCM  OCB  CTR	2.79  2.49  0.20	4.18  3.88  1.59  1.39	4.70  4.79  2.04  1.52	512  656  624  244	274  365  318  130
Intel x86 i5-650 “Clarkdale” 64-bit Käsper-Schwabe			GCM  GCM‑8K  OCB  CTR	14.7  3.19  0.31	22.4  10.9  8.05  7.74	26.7  15.2  9.24  8.98	1456  9648  3216  1424	3780  2560  3430  1180
ARM Cortex-A8 32-bit OpenSSL			CCM  GCM‑256   OCB  CTR	25.9  26.7  3.49	51.3  50.8  28.9  25.4	53.7  53.9  30.9  25.9	512  656  784  244	1390  3440  2050  236
PowerPC 970 64-bit OpenSSL			CCM  GCM‑256   OCB  CTR	38.2  16.0  0.0	75.7  53.5  37.5  37.5	77.8  56.2  39.6  37.8	512  656  784  244	1510  1030  2300  309
UltraSPARC III 64-bit OpenSSL			CCM  GCM‑256   OCB  CTR	25.3  15.2  0.9	49.4  39.3  25.0  24.1	51.7  41.5  26.5  24.4	512  656  784  244	1280  904  1770  213

Notes:

• We measure time (actually, rate) in cycles per byte (cpb). Timing figures are rounded to three decimal places.
• The overhead is defined as (time to encrypt n bytes with the mode) MINUS (time to encrypt n bytes with CTR mode).
• Columns 5 and 6 give the overhead and time for 4 KByte messages. For other lengths, see the plots or raw data.
• Column 7 gives the “Internet Performance Index” (IPI). This heuristic measure, introduced by McGrew and Viega (2004), is the average cycles per byte one will see if messages are distributed: 1500 bytes (60%), 576 bytes (20%), 552 bytes (15%), and 44 bytes (5%). While one could not convincingly justify the selection of this (or any other) distribution on message lengths, the point is simply to fix some distribution that will not overly emphasize long strings.
• Column 8 (Size) and column 9 (Init) specify the size of a context, in bytes, and the number of clock cycles needed to initialize the context.
• All compilations use GCC 4.5.1 under Debian Linux with -O3 and either -march or else -mcpu set to the correct architecture.
• Rows labeled NI use AES-NI.
• The row labeled Käsper/Schwabe employs AES, CTR, and GCM code from the online code distribution of Emilia Käsper and Peter Schwabe (accessed 30 July 2010). See those authors’ [FSE 2010] paper. The entry labeled GCM uses a bit-sliced Galois-field multiply and is constant time. The entry labeled GCM‑8K employs a bit-sliced AES and a table-based Galois-field multiply; because of the latter, it is probably not resistant to timing attacks.
• The rows labeled OpenSSL, and the GCM implementation using AES-NI, employ a pre-release of OpenSSL Version 1.1 (openssl-SNAP-20101023) from ftp://ftp.openssl.org/snapshot/. We include with our standard compiler settings -m32 to force use of the 32-bit subset of the instruction set; this gives an approximation to the performance one would see under a 32-bit OS. We note that OpenSSL chooses to implement GCM with rather small tables (256 bytes) to improve key agility and minimize the risk of timing attacks.
• All code used in this study that is not specifically credited to others was written by Ted Krovetz.
• All code used for the data on this page is in this zip file.