ChaCha20-Poly1305

Last updated

ChaCha20-Poly1305 is an authenticated encryption with additional data (AEAD) algorithm, that combines the ChaCha20 stream cipher with the Poly1305 message authentication code. Its usage in IETF protocols is standardized in RFC 8439. [1] It has fast software performance, and without hardware acceleration, is usually faster than AES-GCM. [2]

Contents

History

The two building blocks of the construction, the algorithms Poly1305 and ChaCha20, were both independently designed, in 2005 and 2008, by Daniel J. Bernstein. [3] [4]

In 2013–2014, a variant of the original ChaCha20 algorithm (using 32-bit counter and 96-bit nonce) and a variant of the original Poly1305 (authenticating 2 strings) were combined in an IETF draft [5] [6] to be used in TLS and DTLS, [7] and chosen by Google, for security and performance reasons, as a newly supported cipher. [8] Shortly after Google's adoption for TLS, ChaCha20, Poly1305 and the combined AEAD mode are added to OpenSSH via thechacha20-poly1305@openssh.com authenticated encryption cipher [9] [10] but kept the original 64-bit counter and 64-bit nonce for the ChaCha20 algorithm.

In 2015, the AEAD algorithm is standardized in RFC 7539 [11] and RFC 7905 [12] to be used in TLS 1.2 and DTLS 1.2 and in RFC 7634 [13] to be used in IPsec. The same year, it was integrated by Cloudflare as an alternative ciphersuite. [14]

In June 2018, the RFC 7539 was updated and replaced by RFC 8439. [1]

Description

The ChaCha20-Poly1305 algorithm as described in RFC 8439 [1] takes as input a 256-bit key and a 96-bit nonce to encrypt a plaintext, with a ciphertext expansion of 128-bit (the tag size). In the ChaCha20-Poly1305 construction, ChaCha20 is used in counter mode to derive a key stream that is XORed with the plaintext. The ciphertext and the associated data is then authenticated using a variant of Poly1305 that first encodes the two strings into one. The way that a cipher and a one time authenticator are combined is precisely identical to AES-GCM construction in how the first block is used to seed the authenticator and how the ciphertext is then authenticated with a 16-byte tag.

The main external difference with ChaCha20 is its 64 byte (512 bit) block size, in comparison to 16 bytes (128 bit) with both AES-128 and AES-256. The larger block size enables higher performance on modern CPUs and allows for larger streams before the 32 bit counter overflows.

ChaCha20-Poly1305 Encryption ChaCha20-Poly1305 Encryption.svg
ChaCha20-Poly1305 Encryption

Variants

XChaCha20-Poly1305 – extended nonce variant

The XChaCha20-Poly1305 construction is an extended 192-bit nonce variant of the ChaCha20-Poly1305 construction, using XChaCha20 instead of ChaCha20. When choosing nonces at random, the XChaCha20-Poly1305 construction allows for better security than the original construction. The draft attempt to standardize the construction expired in July 2020. [15]

Salsa20-Poly1305 and XSalsa20-Poly1305

Salsa20-Poly1305 and XSalsa20-Poly1305 are variants of the ChaCha20-Poly1305 and XChaCha20-Poly1305 algorithms, using Salsa20 and XSalsa20 in place of ChaCha20 and XChaCha20. They are implemented in NaCl [16] and libsodium [17] but not standardized. The variants using ChaCha are preferred in practice as they provide better diffusion per round than Salsa. [3]

Reduced-round variants

ChaCha20 can be replaced with its reduced-round variants ChaCha12 and ChaCha8, yielding ChaCha12-Poly1305 and ChaCha8-Poly1305. The same modification can be applied to XChaCha20-Poly1305. These are implemented by the RustCrypto team and not standardized. [18]

Use

ChaCha20-Poly1305 is used in IPsec, [2] SSH, [19] TLS 1.2, DTLS 1.2, TLS 1.3, [12] [19] WireGuard, [20] S/MIME 4.0, [21] OTR v4 [22] and multiple other protocols. It is used in Software like Borg [23] as standard data encryption. Among others, it is implemented in OpenSSL, and libsodium.

Performance

ChaCha20-Poly1305 usually offers better performance than the more prevalent AES-GCM algorithm even on systems where the CPU(s) have the AES-NI instruction set extension.[ failed verification ] [2] Encryption and decryption speeds with software implementations are already above 1 GB/s when done on a single core, scaling up almost linearly if more cores are used in parallel. AES-NI reaches roughly same speed on a single core but does not scale as well to multiple CPUs, and without the instruction set extension it is difficult to implement efficiently. As a result, ChaCha20-Poly1305 is sometimes preferred over AES-GCM due to its similar levels of security and in certain use cases involving mobile devices, which mostly use ARM-based CPUs. Because ChaCha20-Poly1305 has less overhead than AES-GCM, so use ChaCha20-Poly1305 on mobile devices may consume less power than AES-GCM.

Security

The ChaCha20-Poly1305 construction is proven secure in the standard model and the ideal permutation model, for the single- and multi-user setting. [24] However, similarly to GCM, the security relies on choosing a unique nonce for every message encrypted. Compared to AES-GCM, implementations of ChaCha20-Poly1305 are less vulnerable to timing attacks.

See also

Related Research Articles

In cryptography, RC4 is a stream cipher. While it is remarkable for its simplicity and speed in software, multiple vulnerabilities have been discovered in RC4, rendering it insecure. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys are used. Particularly problematic uses of RC4 have led to very insecure protocols such as WEP.

The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).

<span class="mw-page-title-main">Symmetric-key algorithm</span> Algorithm

Symmetric-key algorithms are algorithms for cryptography that use the same cryptographic keys for both the encryption of plaintext and the decryption of ciphertext. The keys may be identical, or there may be a simple transformation to go between the two keys. The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link. The requirement that both parties have access to the secret key is one of the main drawbacks of symmetric-key encryption, in comparison to public-key encryption. However, symmetric-key encryption algorithms are usually better for bulk encryption. With exception of the one-time pad they have a smaller key size, which means less storage space and faster transmission. Due to this, asymmetric-key encryption is often used to exchange the secret key for symmetric-key encryption.

<span class="mw-page-title-main">Block cipher mode of operation</span> Cryptography algorithm

In cryptography, a block cipher mode of operation is an algorithm that uses a block cipher to provide information security such as confidentiality or authenticity. A block cipher by itself is only suitable for the secure cryptographic transformation of one fixed-length group of bits called a block. A mode of operation describes how to repeatedly apply a cipher's single-block operation to securely transform amounts of data larger than a block.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In computing, Internet Key Exchange is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. IKE uses X.509 certificates for authentication ‒ either pre-shared or distributed using DNS ‒ and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

In cryptography, Camellia is a symmetric key block cipher with a block size of 128 bits and key sizes of 128, 192 and 256 bits. It was jointly developed by Mitsubishi Electric and NTT of Japan. The cipher has been approved for use by the ISO/IEC, the European Union's NESSIE project and the Japanese CRYPTREC project. The cipher has security levels and processing abilities comparable to the Advanced Encryption Standard.

CRYPTREC is the Cryptography Research and Evaluation Committees set up by the Japanese Government to evaluate and recommend cryptographic techniques for government and industrial use. It is comparable in many respects to the European Union's NESSIE project and to the Advanced Encryption Standard process run by National Institute of Standards and Technology in the U.S.

Poly1305 is a universal hash family designed by Daniel J. Bernstein for use in cryptography.

CCM mode is a mode of operation for cryptographic block ciphers. It is an authenticated encryption algorithm designed to provide both authentication and confidentiality. CCM mode is only defined for block ciphers with a block length of 128 bits.

Authenticated Encryption (AE) is an encryption scheme which simultaneously assures the data confidentiality and authenticity. Examples of encryption modes that provide AE are GCM, CCM.

<span class="mw-page-title-main">Salsa20</span> Stream ciphers

Salsa20 and the closely related ChaCha are stream ciphers developed by Daniel J. Bernstein. Salsa20, the original cipher, was designed in 2005, then later submitted to the eSTREAM European Union cryptographic validation process by Bernstein. ChaCha is a modification of Salsa20 published in 2008. It uses a new round function that increases diffusion and increases performance on some architectures.

In cryptography, Galois/Counter Mode (GCM) is a mode of operation for symmetric-key cryptographic block ciphers which is widely adopted for its performance. GCM throughput rates for state-of-the-art, high-speed communication channels can be achieved with inexpensive hardware resources.

DNSCurve is a proposed secure protocol for the Domain Name System (DNS), designed by Daniel J. Bernstein. It encrypts and authenticates DNS packets between resolvers and authoritative servers.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

wolfSSL is a small, portable, embedded SSL/TLS library targeted for use by embedded systems developers. It is an open source implementation of TLS written in the C programming language. It includes SSL/TLS client libraries and an SSL/TLS server implementation as well as support for multiple APIs, including those defined by SSL and TLS. wolfSSL also includes an OpenSSL compatibility interface with the most commonly used OpenSSL functions.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

AES-GCM-SIV is a mode of operation for the Advanced Encryption Standard which provides similar performance to Galois/Counter Mode as well as misuse resistance in the event of the reuse of a cryptographic nonce. The construction is defined in RFC 8452.

Application Layer Transport Security (ALTS) is a Google-developed authentication and transport encryption system used for securing Remote Procedure Call (RPC) within Google machines. Google started its development in 2007, as a tailored modification of TLS.

References

  1. 1 2 3 Nir, Yoav; Langley, Adam (June 2018). ChaCha20 and Poly1305 for IETF Protocols. doi: 10.17487/RFC8439 . RFC 8439.
  2. 1 2 3 Nir, Yoav; Langley, Adam (June 2018). "Performance Measurements of ChaCha20". ChaCha20 and Poly1305 for IETF Protocols. sec. B. doi: 10.17487/RFC8439 . RFC 8439.
  3. 1 2 Bernstein, D. J. (January 2008). ChaCha, a variant of Salsa20 (PDF). The State of the Art of Stream Ciphers. Vol. 8. pp. 3–5.
  4. ↑ Bernstein, Daniel J. (2005), "The Poly1305-AES Message-Authentication Code", Fast Software Encryption, Lecture Notes in Computer Science, vol. 3557, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 32–49, doi: 10.1007/11502760_3 , ISBN   978-3-540-26541-2
  5. ↑ Langley, Adam (September 2013). ChaCha20 and Poly1305 based Cipher Suites for TLS. I-D draft-agl-tls-chacha20poly1305-00.
  6. ↑ Nir, Yoav (27 January 2014). ChaCha20 and Poly1305 for IETF protocols. I-D draft-nir-cfrg-chacha20-poly1305-00.
  7. ↑ Langley, Adam; Chang, Wan-Teh; Mavrogiannopoulos, Nikos; Strombergson, Joachim; Josefsson, Simon (24 January 2014). The ChaCha Stream Cipher for Transport Layer Security. I-D draft-mavrogiannopoulos-chacha-tls-01.
  8. ↑ Bursztein, Elie (24 April 2014). "Speeding up and strengthening HTTPS connections for Chrome on Android". Google Online Security Blog. Archived from the original on 2016-09-28. Retrieved 2021-12-27.
  9. ↑ Miller, Damien. "Super User's BSD Cross Reference: /OpenBSD/usr.bin/ssh/PROTOCOL.chacha20poly1305". bxr.su. Archived from the original on 2013-12-13. Retrieved 2021-12-28.
  10. ↑ Miller, Damien (29 November 2013). "ChaCha20 and Poly1305 in OpenSSH". Archived from the original on 2013-12-13. Retrieved 2021-12-28.
  11. ↑ Nir, Yoav; Langley, Adam (May 2015). ChaCha20 and Poly1305 for IETF Protocols. doi: 10.17487/RFC7539 . RFC 7539.
  12. 1 2 Langley, Adam; Chang, Wan-Teh; Mavrogiannopoulos, Nikos; Strombergson, Joachim; Josefsson, Simon (June 2016). ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS). doi: 10.17487/RFC7905 . RFC 7905.
  13. ↑ Nir, Yoav (August 2015). ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec. doi: 10.17487/RFC7634 . RFC 7634.
  14. ↑ "Do the ChaCha: better mobile performance with cryptography". The Cloudflare Blog. 2015-02-23. Retrieved 2021-12-28.
  15. ↑ Arciszewski, Scott (10 January 2020). XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305. I-D draft-irtf-cfrg-xchacha.
  16. ↑ "NaCl: Networking and Cryptography library - Secret-key authenticated encryption". Archived from the original on 2009-06-30.
  17. ↑ "libsodium - Authenticated encryption". Archived from the original on 2020-08-04.
  18. ↑ "chacha20poly1305 - Rust". docs.rs. ChaCha8Poly1305 / ChaCha12Poly1305 - non-standard, reduced-round variants (gated under the reduced-round Cargo feature). See the Too Much Crypto paper for background and rationale on when these constructions could be used. When in doubt, prefer ChaCha20Poly1305. XChaCha8Poly1305 / XChaCha12Poly1305 - same as above, but with an extended 192-bit (24-byte) nonce.
  19. 1 2 Thomson, Martin; Turner (May 2021). Using TLS to Secure QUIC. doi: 10.17487/RFC9001 . RFC 9001.
  20. ↑ Donenfeld, Jason A. "Protocol & Cryptography - WireGuard". www.wireguard.com. Retrieved 2021-12-28.
  21. ↑ Housley, Russ (February 2017). Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). doi: 10.17487/RFC8103 . RFC 8103.
  22. ↑ OTRv4, OTRv4, 2021-12-25, retrieved 2021-12-28
  23. ↑ borg rcreate, borgbackup, 2022-08-03, retrieved 2023-01-28
  24. ↑ Degabriele, Jean Paul; Govinden, Jérôme; Günther, Felix; Paterson, Kenneth G. (2021-11-12), "The Security of ChaCha20-Poly1305 in the Multi-User Setting", Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, New York, NY, USA: Association for Computing Machinery, pp. 1981–2003, doi:10.1145/3460120.3484814, ISBN   978-1-4503-8454-4, S2CID   244077782 , retrieved 2021-12-27
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.