Galois/Counter Mode: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m Fixed link to Wikipedia article.
Citation bot (talk | contribs)
m Add: citeseerx, title. Converted bare reference to cite template. Removed parameters. | You can use this bot yourself. Report bugs here. | User-activated.
Line 1: Line 1:
'''Galois/Counter Mode''' ('''GCM''') is a [[block cipher mode of operation|mode of operation]] for symmetric key cryptographic [[block cipher]]s that has been widely adopted because of its efficiency and performance. GCM throughput rates for state-of-the-art, high-speed communication channels can be achieved with reasonable hardware resources.<ref>{{cite book |last=Lemsitzer |first=S. |last2=Wolkerstorfer |first2=J. |last3=Felber |first3=N. |last4=Braendli |first4=M. |chapter=Multi-gigabit GCM-AES Architecture Optimized for FPGAs |chapterurl=https://link.springer.com/chapter/10.1007/978-3-540-74735-2_16 |editor-last=Paillier |editor-first=P. |editor2-last=Verbauwhede |editor2-first=I. |title=Cryptographic Hardware and Embedded Systems — CHES 2007 |publisher=Springer |year=2007 |isbn=978-3-540-74734-5 |pages=227–238 |doi=10.1007/978-3-540-74735-2_16 |series=Lecture Notes in Computer Science |volume=4727}}</ref> The operation is an [[authenticated encryption]] algorithm designed to provide both data authenticity (integrity) and confidentiality. GCM is defined for block ciphers with a block size of 128 bits. '''Galois Message Authentication Code''' ('''GMAC''') is an authentication-only variant of the GCM which can be used as an incremental message authentication code. Both GCM and GMAC can accept initialization vectors of arbitrary length.
'''Galois/Counter Mode''' ('''GCM''') is a [[block cipher mode of operation|mode of operation]] for symmetric key cryptographic [[block cipher]]s that has been widely adopted because of its efficiency and performance. GCM throughput rates for state-of-the-art, high-speed communication channels can be achieved with reasonable hardware resources.<ref>{{cite book |last=Lemsitzer |first=S. |last2=Wolkerstorfer |first2=J. |last3=Felber |first3=N. |last4=Braendli |first4=M. |chapter=Multi-gigabit GCM-AES Architecture Optimized for FPGAs |editor-last=Paillier |editor-first=P. |editor2-last=Verbauwhede |editor2-first=I. |title=Cryptographic Hardware and Embedded Systems — CHES 2007 |publisher=Springer |year=2007 |isbn=978-3-540-74734-5 |pages=227–238 |doi=10.1007/978-3-540-74735-2_16 |series=Lecture Notes in Computer Science |volume=4727}}</ref> The operation is an [[authenticated encryption]] algorithm designed to provide both data authenticity (integrity) and confidentiality. GCM is defined for block ciphers with a block size of 128 bits. '''Galois Message Authentication Code''' ('''GMAC''') is an authentication-only variant of the GCM which can be used as an incremental message authentication code. Both GCM and GMAC can accept initialization vectors of arbitrary length.


Different block cipher modes of operation can have significantly different performance and efficiency characteristics, even when used with the same block cipher. GCM can take full advantage of parallel processing and implementing GCM can make efficient use of an [[instruction pipeline]] or a hardware pipeline. In contrast, the [[cipher block chaining]] (CBC) mode of operation incurs significant [[pipeline stall]]s that hamper its efficiency and performance.
Different block cipher modes of operation can have significantly different performance and efficiency characteristics, even when used with the same block cipher. GCM can take full advantage of parallel processing and implementing GCM can make efficient use of an [[instruction pipeline]] or a hardware pipeline. In contrast, the [[cipher block chaining]] (CBC) mode of operation incurs significant [[pipeline stall]]s that hamper its efficiency and performance.
Line 55: Line 55:


==Use==
==Use==
GCM mode is used in the [[IEEE 802.1AE]] (MACsec) Ethernet security, [[802.11ad|IEEE 802.11ad]] (also known as [[WiGig]]), ANSI ([[INCITS]]) [[Fibre Channel]] Security Protocols (FC-SP), [[IEEE P1619]].1 tape storage, [[Internet Engineering Task Force|IETF]] [[IPsec]] standards,<ref>RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)</ref><ref>RFC 4543 ''The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH''</ref> [[Secure Shell|SSH]]<ref>RFC 5647 ''AES Galois Counter Mode for the Secure Shell Transport Layer Protocol''</ref> and [[Transport Layer Security|TLS]] 1.2.<ref>RFC 5288 ''AES Galois Counter Mode (GCM) Cipher Suites for TLS''</ref><ref>RFC 6367 ''Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)''</ref> AES-GCM is included in the [[NSA Suite B Cryptography]]. GCM mode is used in the [[SoftEther VPN]] server and client,<ref>https://www.softether.org/1-features</ref> as well as [[OpenVPN]] since version 2.4.
GCM mode is used in the [[IEEE 802.1AE]] (MACsec) Ethernet security, [[802.11ad|IEEE 802.11ad]] (also known as [[WiGig]]), ANSI ([[INCITS]]) [[Fibre Channel]] Security Protocols (FC-SP), [[IEEE P1619]].1 tape storage, [[Internet Engineering Task Force|IETF]] [[IPsec]] standards,<ref>RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)</ref><ref>RFC 4543 ''The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH''</ref> [[Secure Shell|SSH]]<ref>RFC 5647 ''AES Galois Counter Mode for the Secure Shell Transport Layer Protocol''</ref> and [[Transport Layer Security|TLS]] 1.2.<ref>RFC 5288 ''AES Galois Counter Mode (GCM) Cipher Suites for TLS''</ref><ref>RFC 6367 ''Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)''</ref> AES-GCM is included in the [[NSA Suite B Cryptography]]. GCM mode is used in the [[SoftEther VPN]] server and client,<ref>{{Cite web | url=https://www.softether.org/1-features | title=Why SoftEther VPN - SoftEther VPN Project}}</ref> as well as [[OpenVPN]] since version 2.4.


==Performance==
==Performance==
Line 64: Line 64:
Intel has added the [[CLMUL instruction set|PCLMULQDQ]] instruction, highlighting its use for GCM.<ref>{{cite web |url=http://software.intel.com/en-us/articles/intel-carry-less-multiplication-instruction-and-its-usage-for-computing-the-gcm-mode |title=Intel Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode (Revision 2.02) |first1=Shay |last1=Gueron |first2=Michael |last2=Kounavis |date=April 2014 |accessdate=2018-04-29}}</ref> In 2011, SPARC added the XMULX and XMULXHI instructions, which also perform 64 × 64 bit [[carry-less product|carry-less multiplication]]. In 2015, SPARC added the XMPMUL instruction, which performs XOR multiplication of much larger values, up to 2048 × 2048 bit input values producing a 4096-bit result. These instructions enable fast multiplication over GF(2<sup>''n''</sup>), and can be used with any field representation.
Intel has added the [[CLMUL instruction set|PCLMULQDQ]] instruction, highlighting its use for GCM.<ref>{{cite web |url=http://software.intel.com/en-us/articles/intel-carry-less-multiplication-instruction-and-its-usage-for-computing-the-gcm-mode |title=Intel Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode (Revision 2.02) |first1=Shay |last1=Gueron |first2=Michael |last2=Kounavis |date=April 2014 |accessdate=2018-04-29}}</ref> In 2011, SPARC added the XMULX and XMULXHI instructions, which also perform 64 × 64 bit [[carry-less product|carry-less multiplication]]. In 2015, SPARC added the XMPMUL instruction, which performs XOR multiplication of much larger values, up to 2048 × 2048 bit input values producing a 4096-bit result. These instructions enable fast multiplication over GF(2<sup>''n''</sup>), and can be used with any field representation.


Impressive performance results have been published for GCM on a number of platforms. Käsper and Schwabe described a "Faster and Timing-Attack Resistant AES-GCM"<ref>{{cite book |last=Käsper |first=E. |last2=Schwabe |first2=P. |chapter=Faster and Timing-Attack Resistant AES-GCM |chapterurl=https://link.springer.com/chapter/10.1007/978-3-642-04138-9_1 |editor-last=Clavier |editor-first=C. |editor2-last=Gaj |editor2-first=K. |title=Cryptographic Hardware and Embedded Systems — CHES 2009 |publisher=Springer |year=2009 |isbn=978-3-642-04138-9 |pages=1–17 |doi=10.1007/978-3-642-04138-9_1 |series=Lecture Notes in Computer Science |volume=5747}}</ref> that achieves 10.68 cycles per byte AES-GCM authenticated encryption on 64-bit Intel processors. Dai et al. report 3.5 cycles per byte for the same algorithm when using Intel's AES-NI and PCLMULQDQ instructions. Shay Gueron and Vlad Krasnov achieved 2.47 cycles per byte on the 3rd generation Intel processors. Appropriate patches were prepared for the [[OpenSSL]] and [[Network Security Services|NSS]] libraries.<ref>{{cite web |last=Gueron |first=Shay |title=AES-GCM for Efficient Authenticated Encryption – Ending the Reign of HMAC-SHA-1? |url=https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf |work=Workshop on Real-World Cryptography |accessdate=8 February 2013}}</ref>
Impressive performance results have been published for GCM on a number of platforms. Käsper and Schwabe described a "Faster and Timing-Attack Resistant AES-GCM"<ref>{{cite book |last=Käsper |first=E. |last2=Schwabe |first2=P. |chapter=Faster and Timing-Attack Resistant AES-GCM |editor-last=Clavier |editor-first=C. |editor2-last=Gaj |editor2-first=K. |title=Cryptographic Hardware and Embedded Systems — CHES 2009 |publisher=Springer |year=2009 |isbn=978-3-642-04138-9 |pages=1–17 |doi=10.1007/978-3-642-04138-9_1 |series=Lecture Notes in Computer Science |volume=5747}}</ref> that achieves 10.68 cycles per byte AES-GCM authenticated encryption on 64-bit Intel processors. Dai et al. report 3.5 cycles per byte for the same algorithm when using Intel's AES-NI and PCLMULQDQ instructions. Shay Gueron and Vlad Krasnov achieved 2.47 cycles per byte on the 3rd generation Intel processors. Appropriate patches were prepared for the [[OpenSSL]] and [[Network Security Services|NSS]] libraries.<ref>{{cite web |last=Gueron |first=Shay |title=AES-GCM for Efficient Authenticated Encryption – Ending the Reign of HMAC-SHA-1? |url=https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf |work=Workshop on Real-World Cryptography |accessdate=8 February 2013}}</ref>


When both authentication and encryption need to be performed on a message, a software implementation can achieve speed gains by overlapping the execution of those operations. Performance is increased by exploiting [[instruction-level parallelism]] by interleaving operations. This process is called function stitching,<ref>Gopal, V., Feghali, W., Guilford, J., Ozturk, E., Wolrich, G., Dixon, M., Locktyukhin, M., Perminov, M. [http://download.intel.com/design/intarch/PAPERS/323686.pdf "Fast Cryptographic Computation on Intel Architecture via Function Stitching"] Intel Corp. (2010)</ref> and while in principle it can be applied to any combination of cryptographic algorithms, GCM is especially suitable. Manley and Gregg<ref>{{cite book |first=Raymond |last=Manley |first2=David |last2=Gregg |chapter=A Program Generator for Intel AES-NI Instructions |chapterurl=https://link.springer.com/chapter/10.1007/978-3-642-17401-8_22 |doi=10.1007/978-3-642-17401-8_22 |editor-last=Gong |editor-first=G. |editor2-last=Gupta |editor2-first=K.C. |title=Progress in Cryptology — INDOCRYPT 2010 |series=Lecture Notes in Computer Science |volume=6498 |pages=311-327 |isbn=978-3-642-17400-1 |publisher=Springer |year=2010}} </ref> show the ease of optimizing when using function stitching with GCM. They present a program generator that takes an annotated C version of a cryptographic algorithm and generates code that runs well on the target processor.
When both authentication and encryption need to be performed on a message, a software implementation can achieve speed gains by overlapping the execution of those operations. Performance is increased by exploiting [[instruction-level parallelism]] by interleaving operations. This process is called function stitching,<ref>Gopal, V., Feghali, W., Guilford, J., Ozturk, E., Wolrich, G., Dixon, M., Locktyukhin, M., Perminov, M. [http://download.intel.com/design/intarch/PAPERS/323686.pdf "Fast Cryptographic Computation on Intel Architecture via Function Stitching"] Intel Corp. (2010)</ref> and while in principle it can be applied to any combination of cryptographic algorithms, GCM is especially suitable. Manley and Gregg<ref>{{cite book |first=Raymond |last=Manley |first2=David |last2=Gregg |chapter=A Program Generator for Intel AES-NI Instructions |doi=10.1007/978-3-642-17401-8_22 |editor-last=Gong |editor-first=G. |editor2-last=Gupta |editor2-first=K.C. |title=Progress in Cryptology — INDOCRYPT 2010 |series=Lecture Notes in Computer Science |volume=6498 |pages=311–327 |isbn=978-3-642-17400-1 |publisher=Springer |year=2010}} </ref> show the ease of optimizing when using function stitching with GCM. They present a program generator that takes an annotated C version of a cryptographic algorithm and generates code that runs well on the target processor.


GCM has been criticized for example by Silicon Labs in the embedded world as the parallel processing is not suited to performant use of cryptographic hardware engines and therefore reduces the performance of encryption for some of the most performance-sensitive devices.<ref>{{cite web |url=http://community.silabs.com/t5/Official-Blog-of-Silicon-Labs/IoT-Security-Part-6-Galois-Counter-Mode/ba-p/169191 |title=IoT Security Part 6: Galois Counter Mode |date=2016-05-06 |accessdate=2018-04-29}}</ref>
GCM has been criticized for example by Silicon Labs in the embedded world as the parallel processing is not suited to performant use of cryptographic hardware engines and therefore reduces the performance of encryption for some of the most performance-sensitive devices.<ref>{{cite web |url=http://community.silabs.com/t5/Official-Blog-of-Silicon-Labs/IoT-Security-Part-6-Galois-Counter-Mode/ba-p/169191 |title=IoT Security Part 6: Galois Counter Mode |date=2016-05-06 |accessdate=2018-04-29}}</ref>


==Patents==
==Patents==
According to the authors' statement, GCM is unencumbered by patents.<ref>{{cite web |url=http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-nist-ipr.pdf |format=PDF |title=The Galois/Counter Mode of Operation (GCM) Intellectual Property Statement |first=David A. |last=McGrew |first2=John |last2=Viega |publisher=Computer Security Resource Center, NIST }}</ref>
According to the authors' statement, GCM is unencumbered by patents.<ref>{{cite web |url=http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-nist-ipr.pdf |title=The Galois/Counter Mode of Operation (GCM) Intellectual Property Statement |first=David A. |last=McGrew |first2=John |last2=Viega |publisher=Computer Security Resource Center, NIST }}</ref>


==Security==
==Security==
GCM has been proven secure in the [[Concrete security|concrete security model]].<ref>{{cite book |first=David A. |last=McGrew |first2=John |last2=Viega |url=https://link.springer.com/chapter/10.1007%2F978-3-540-30556-9_27 |chapter=The Security and Performance of the Galois/counter mode (GCM) of Operation |title=Proceedings of INDOCRYPT 2004 |series=Lecture Notes in Computer Science |volume=3348 |year=2004 |doi=10.1007/978-3-540-30556-9_27 |isbn=978-3-540-30556-9 |publisher=Springer }}</ref> It is secure when it is used with a block cipher that is indistinguishable from a random permutation; however, security depends on choosing a unique [[initialization vector]] for every encryption performed with the same key (''see'' [[stream cipher attack]]). For any given key and initialization vector combination, GCM is limited to encrypting {{nowrap|2<sup>39</sup>−256}} bits of plain text (64 GiB). NIST Special Publication 800-38D<ref name="NIST-SP-800-38D"/> includes guidelines for initialization vector selection.
GCM has been proven secure in the [[Concrete security|concrete security model]].<ref>{{cite book |first=David A. |last=McGrew |first2=John |last2=Viega |chapter=The Security and Performance of the Galois/counter mode (GCM) of Operation |title=Proceedings of INDOCRYPT 2004 |series=Lecture Notes in Computer Science |volume=3348 |year=2004 |doi=10.1007/978-3-540-30556-9_27 |isbn=978-3-540-30556-9 |publisher=Springer |citeseerx=10.1.1.1.4591 }}</ref> It is secure when it is used with a block cipher that is indistinguishable from a random permutation; however, security depends on choosing a unique [[initialization vector]] for every encryption performed with the same key (''see'' [[stream cipher attack]]). For any given key and initialization vector combination, GCM is limited to encrypting {{nowrap|2<sup>39</sup>−256}} bits of plain text (64 GiB). NIST Special Publication 800-38D<ref name="NIST-SP-800-38D"/> includes guidelines for initialization vector selection.


The authentication strength depends on the length of the authentication tag, as with all symmetric message authentication codes. The use of shorter authentication tags with GCM is discouraged. The bit-length of the tag, denoted ''t'', is a security parameter. In general, ''t'' may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, ''t'' may be 64 or 32, but the use of these two tag lengths constrains the length of the input data and the lifetime of the key. Appendix C in NIST SP 800-38D provides guidance for these constraints (for example, if {{nowrap|1=''t'' = 32}} and the maximal packet size is 2<sup>10</sup> bytes, the authentication decryption function should be invoked no more than 2<sup>11</sup> times; if {{nowrap|1=''t'' = 64}} and the maximal packet size is 2<sup>15</sup> bytes, the authentication decryption function should be invoked no more than 2<sup>32</sup> times).
The authentication strength depends on the length of the authentication tag, as with all symmetric message authentication codes. The use of shorter authentication tags with GCM is discouraged. The bit-length of the tag, denoted ''t'', is a security parameter. In general, ''t'' may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, ''t'' may be 64 or 32, but the use of these two tag lengths constrains the length of the input data and the lifetime of the key. Appendix C in NIST SP 800-38D provides guidance for these constraints (for example, if {{nowrap|1=''t'' = 32}} and the maximal packet size is 2<sup>10</sup> bytes, the authentication decryption function should be invoked no more than 2<sup>11</sup> times; if {{nowrap|1=''t'' = 64}} and the maximal packet size is 2<sup>15</sup> bytes, the authentication decryption function should be invoked no more than 2<sup>32</sup> times).

Revision as of 13:49, 30 January 2019

Galois/Counter Mode (GCM) is a mode of operation for symmetric key cryptographic block ciphers that has been widely adopted because of its efficiency and performance. GCM throughput rates for state-of-the-art, high-speed communication channels can be achieved with reasonable hardware resources.[1] The operation is an authenticated encryption algorithm designed to provide both data authenticity (integrity) and confidentiality. GCM is defined for block ciphers with a block size of 128 bits. Galois Message Authentication Code (GMAC) is an authentication-only variant of the GCM which can be used as an incremental message authentication code. Both GCM and GMAC can accept initialization vectors of arbitrary length.

Different block cipher modes of operation can have significantly different performance and efficiency characteristics, even when used with the same block cipher. GCM can take full advantage of parallel processing and implementing GCM can make efficient use of an instruction pipeline or a hardware pipeline. In contrast, the cipher block chaining (CBC) mode of operation incurs significant pipeline stalls that hamper its efficiency and performance.

Basic operation

Just as in normal counter mode, blocks are numbered sequentially, and then this block number is combined with an initialization vector (IV) and encrypted with a block cipher E, usually AES. The result of this encryption is then XORed with the plaintext to produce the ciphertext. Like all counter modes, this is essentially a stream cipher, and so it is essential that a different IV is used for each stream that is encrypted.

The ciphertext blocks are treated as coefficients of a polynomial which is then evaluated at a key-dependent point H, using finite field arithmetic. The result is then encrypted, producing an authentication tag that can be used to verify the integrity of the data. The encrypted text then contains the IV, ciphertext, and authentication tag.

GCM encryption operation

Mathematical basis

GCM combines the well-known counter mode of encryption with the new Galois mode of authentication. The key feature is that the Galois field multiplication used for authentication can be easily computed in parallel. This option permits higher throughput than authentication algorithms, like CBC, which use chaining modes. The GF(2128) field used is defined by the polynomial

The authentication tag is constructed by feeding blocks of data into the GHASH function and encrypting the result. This GHASH function is defined by

where H=Ek(0128) is the Hash Key, a string of 128 zero bits encrypted using the block cipher, A is data which is only authenticated (not encrypted), C is the ciphertext, m is the number of 128-bit blocks in A (rounded up), n is the number of 128-bit blocks in C (rounded up), and the variable Xi for i = 0, ..., m + n + 1 is defined as follows.[2]

First, the authenticated text and the cipher text are separately zero-padded to multiples of 128 bits and combined into a single message Si:

where len(A) and len(C) are the 64-bit representations of the bit lengths of A and C, respectively, v=len(A) mod 128 is the bit length of the final block of A, u=len(C) mod 128 is the bit length of the final block of C, and denotes concatenation of bit strings.

Then Xi is defined as:

The second form is a efficient iterative algorithm (each Xi depends on Xi−1) produced by applying Horner's method to the first. Only the final Xm+n+1 is retained as output.

If it is necessary to parallelize the hash computation, this can be done by interleaving k times:

GCM was designed by John Viega and David A. McGrew as an improvement to Carter–Wegman Counter CWC mode.

In November 2007, NIST announced the release of NIST Special Publication 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC making GCM and GMAC official standards.[3]

Use

GCM mode is used in the IEEE 802.1AE (MACsec) Ethernet security, IEEE 802.11ad (also known as WiGig), ANSI (INCITS) Fibre Channel Security Protocols (FC-SP), IEEE P1619.1 tape storage, IETF IPsec standards,[4][5] SSH[6] and TLS 1.2.[7][8] AES-GCM is included in the NSA Suite B Cryptography. GCM mode is used in the SoftEther VPN server and client,[9] as well as OpenVPN since version 2.4.

Performance

GCM is ideal for protecting packetized data because it has minimum latency and minimum operation overhead.

GCM requires one block cipher operation and one 128-bit multiplication in the Galois field per each block (128 bit) of encrypted and authenticated data. The block cipher operations are easily pipelined or parallelized; the multiplication operations are easily pipelined and can be parallelized with some modest effort (either by parallelizing the actual operation, by adapting Horner's method as described in the original NIST submission, or both).

Intel has added the PCLMULQDQ instruction, highlighting its use for GCM.[10] In 2011, SPARC added the XMULX and XMULXHI instructions, which also perform 64 × 64 bit carry-less multiplication. In 2015, SPARC added the XMPMUL instruction, which performs XOR multiplication of much larger values, up to 2048 × 2048 bit input values producing a 4096-bit result. These instructions enable fast multiplication over GF(2n), and can be used with any field representation.

Impressive performance results have been published for GCM on a number of platforms. Käsper and Schwabe described a "Faster and Timing-Attack Resistant AES-GCM"[11] that achieves 10.68 cycles per byte AES-GCM authenticated encryption on 64-bit Intel processors. Dai et al. report 3.5 cycles per byte for the same algorithm when using Intel's AES-NI and PCLMULQDQ instructions. Shay Gueron and Vlad Krasnov achieved 2.47 cycles per byte on the 3rd generation Intel processors. Appropriate patches were prepared for the OpenSSL and NSS libraries.[12]

When both authentication and encryption need to be performed on a message, a software implementation can achieve speed gains by overlapping the execution of those operations. Performance is increased by exploiting instruction-level parallelism by interleaving operations. This process is called function stitching,[13] and while in principle it can be applied to any combination of cryptographic algorithms, GCM is especially suitable. Manley and Gregg[14] show the ease of optimizing when using function stitching with GCM. They present a program generator that takes an annotated C version of a cryptographic algorithm and generates code that runs well on the target processor.

GCM has been criticized for example by Silicon Labs in the embedded world as the parallel processing is not suited to performant use of cryptographic hardware engines and therefore reduces the performance of encryption for some of the most performance-sensitive devices.[15]

Patents

According to the authors' statement, GCM is unencumbered by patents.[16]

Security

GCM has been proven secure in the concrete security model.[17] It is secure when it is used with a block cipher that is indistinguishable from a random permutation; however, security depends on choosing a unique initialization vector for every encryption performed with the same key (see stream cipher attack). For any given key and initialization vector combination, GCM is limited to encrypting 239−256 bits of plain text (64 GiB). NIST Special Publication 800-38D[3] includes guidelines for initialization vector selection.

The authentication strength depends on the length of the authentication tag, as with all symmetric message authentication codes. The use of shorter authentication tags with GCM is discouraged. The bit-length of the tag, denoted t, is a security parameter. In general, t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32, but the use of these two tag lengths constrains the length of the input data and the lifetime of the key. Appendix C in NIST SP 800-38D provides guidance for these constraints (for example, if t = 32 and the maximal packet size is 210 bytes, the authentication decryption function should be invoked no more than 211 times; if t = 64 and the maximal packet size is 215 bytes, the authentication decryption function should be invoked no more than 232 times).

As with any message authentication code, if the adversary chooses a t-bit tag at random, it is expected to be correct for given data with probability 2t. With GCM, however, an adversary can choose tags that increase this probability, proportional to the total length of the ciphertext and additional authenticated data (AAD). Consequently, GCM is not well-suited for use with very short tag lengths or very long messages.

Ferguson and Saarinen independently described how an attacker can perform optimal attacks against GCM authentication, which meet the lower bound on its security. Ferguson showed that, if n denotes the total number of blocks in the encoding (the input to the GHASH function), then there is a method of constructing a targeted ciphertext forgery that is expected to succeed with a probability of approximately n⋅2t. If the tag length t is shorter than 128, then each successful forgery in this attack increases the probability that subsequent targeted forgeries will succeed, and leaks information about the hash subkey, H. Eventually, H may be compromised entirely and the authentication assurance is completely lost.[18]

Independent of this attack, an adversary may attempt to systematically guess many different tags for a given input to authenticated decryption and thereby increase the probability that one (or more) of them, eventually, will be accepted as valid. For this reason, the system or protocol that implements GCM should monitor and, if necessary, limit the number of unsuccessful verification attempts for each key.

Saarinen described GCM weak keys.[19] This work gives some valuable insights into how polynomial hash-based authentication works. More precisely, this work describes a particular way of forging a GCM message, given a valid GCM message, that works with probability of about n⋅2−128 for messages that are n × 128 bits long. However, this work does not show a more effective attack than was previously known; the success probability in observation 1 of this paper matches that of lemma 2 from the INDOCRYPT 2004 analysis (setting w = 128 and l = n × 128). Saarinen also described a GCM variant Sophie Germain Counter Mode (SGCM) based on Sophie Germain primes.

See also

References

  1. ^ Lemsitzer, S.; Wolkerstorfer, J.; Felber, N.; Braendli, M. (2007). "Multi-gigabit GCM-AES Architecture Optimized for FPGAs". In Paillier, P.; Verbauwhede, I. (eds.). Cryptographic Hardware and Embedded Systems — CHES 2007. Lecture Notes in Computer Science. Vol. 4727. Springer. pp. 227–238. doi:10.1007/978-3-540-74735-2_16. ISBN 978-3-540-74734-5.
  2. ^ McGrew, David A.; Viega, John (2005). "The Galois/Counter Mode of Operation (GCM)" (PDF). p. 5. Retrieved 20 July 2013. Note that there is a typo in the formulas in the article.
  3. ^ a b Dworkin, Morris (2007–2011). Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (PDF) (Technical report). NIST. 800-38D. Retrieved 2015-08-18.
  4. ^ RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
  5. ^ RFC 4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
  6. ^ RFC 5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol
  7. ^ RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS
  8. ^ RFC 6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)
  9. ^ "Why SoftEther VPN - SoftEther VPN Project".
  10. ^ Gueron, Shay; Kounavis, Michael (April 2014). "Intel Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode (Revision 2.02)". Retrieved 2018-04-29.
  11. ^ Käsper, E.; Schwabe, P. (2009). "Faster and Timing-Attack Resistant AES-GCM". In Clavier, C.; Gaj, K. (eds.). Cryptographic Hardware and Embedded Systems — CHES 2009. Lecture Notes in Computer Science. Vol. 5747. Springer. pp. 1–17. doi:10.1007/978-3-642-04138-9_1. ISBN 978-3-642-04138-9.
  12. ^ Gueron, Shay. "AES-GCM for Efficient Authenticated Encryption – Ending the Reign of HMAC-SHA-1?" (PDF). Workshop on Real-World Cryptography. Retrieved 8 February 2013.
  13. ^ Gopal, V., Feghali, W., Guilford, J., Ozturk, E., Wolrich, G., Dixon, M., Locktyukhin, M., Perminov, M. "Fast Cryptographic Computation on Intel Architecture via Function Stitching" Intel Corp. (2010)
  14. ^ Manley, Raymond; Gregg, David (2010). "A Program Generator for Intel AES-NI Instructions". In Gong, G.; Gupta, K.C. (eds.). Progress in Cryptology — INDOCRYPT 2010. Lecture Notes in Computer Science. Vol. 6498. Springer. pp. 311–327. doi:10.1007/978-3-642-17401-8_22. ISBN 978-3-642-17400-1.
  15. ^ "IoT Security Part 6: Galois Counter Mode". 2016-05-06. Retrieved 2018-04-29.
  16. ^ McGrew, David A.; Viega, John. "The Galois/Counter Mode of Operation (GCM) Intellectual Property Statement" (PDF). Computer Security Resource Center, NIST.
  17. ^ McGrew, David A.; Viega, John (2004). "The Security and Performance of the Galois/counter mode (GCM) of Operation". Proceedings of INDOCRYPT 2004. Lecture Notes in Computer Science. Vol. 3348. Springer. CiteSeerX 10.1.1.1.4591. doi:10.1007/978-3-540-30556-9_27. ISBN 978-3-540-30556-9.
  18. ^ Niels Ferguson, Authentication Weaknesses in GCM, 2005-05-20
  19. ^ Markku-Juhani O. Saarinen (2011-04-20). "Cycling Attacks on GCM, GHASH and Other Polynomial MACs and Hashes". FSE 2012. {{cite journal}}: Cite journal requires |journal= (help)

External links