{"history":[],"article":{"id":"4b75f4a6-e124-4e74-9bde-eed20905bdfc","title":"Salsa20","slug":"salsa20","content":":::summary\n![The Salsa quarter-round function. Four parallel copies make a round.](https://upload.wikimedia.org/wikipedia/commons/4/47/Salsa///round///function.svg)\n**Name:** Salsa20 \n**Designers:** [Daniel J. Bernstein](https://bliptext.com/articles/daniel-j-bernstein) \n**Publish Date:** 2007 (designed 2005) \n**Derived To:** ChaCha \n**Related To:** Rumba20 \n**Certification:** [eSTREAM](https://bliptext.com/articles/estream) portfolio \n**Key Size:** 128 or 256 bits \n**State Size:** 512 bits \n**Structure:** ARX \n**Rounds:** 20 \n**Speed:** 3.91 [cpb](https://bliptext.com/articles/cycles-per-byte) on an Intel Core 2 Duo \n**Cryptanalysis:** 2008 cryptanalysis breaks 8 out of 20 rounds to recover the 256-bit secret key in 2251 operations, using 231 keystream pairs. \n:::\n\n# \n**Salsa20** and the closely related **ChaCha** are [stream ciphers](https://bliptext.com/articles/stream-cipher) developed by [Daniel J. Bernstein](https://bliptext.com/articles/daniel-j-bernstein).\nSalsa20, the original cipher, was designed in 2005, then later submitted to the [eSTREAM](https://bliptext.com/articles/estream) European Union cryptographic validation process by Bernstein.\nChaCha is a modification of Salsa20 published in 2008.\nIt uses a new round function that increases diffusion and increases performance on some architectures.\nBoth ciphers are built on a [pseudorandom function](https://bliptext.com/articles/pseudorandom-function) based on [add–rotate–XOR](https://bliptext.com/articles/block-cipher) (ARX) operations — 32-bit addition, bitwise addition (XOR) and [rotation](https://bliptext.com/articles/bit-rotation) operations.\nThe core function maps a [256-bit](https://bliptext.com/articles/256-bit) [key](https://bliptext.com/articles/key-size), a 64-bit [nonce](https://bliptext.com/articles/cryptographic-nonce), and a 64-bit counter to a 512-bit block of the [key](https://bliptext.com/articles/key-size) stream (a Salsa version with a 128-bit [key](https://bliptext.com/articles/key-size) also exists).\nThis gives Salsa20 and ChaCha the unusual advantage that the user can efficiently seek to any position in the key stream in constant time.\nSalsa20 offers speeds of around 4–14 [cycles per byte](https://bliptext.com/articles/cycles-per-byte) in software on modern [x86](https://bliptext.com/articles/x86) processors, and reasonable hardware performance.\nIt is not patented, and Bernstein has written several [public domain](https://bliptext.com/articles/public-domain) implementations optimized for common architectures.\n\n# Structure\nInternally, the cipher uses bitwise addition ⊕ ([exclusive OR](https://bliptext.com/articles/exclusive-or)), 32-bit addition [mod](https://bliptext.com/articles/modular-arithmetic) 232 ⊞, and constant-distance rotation operations <<< on an internal state of sixteen 32-bit words.\nUsing only [add-rotate-xor operations](https://bliptext.com/articles/block-cipher) avoids the possibility of [timing attacks](https://bliptext.com/articles/timing-attack) in software implementations.\nThe internal state is made of sixteen 32-bit words arranged as a 4×4 matrix.\nThe initial state is made up of eight words of key, two words of stream position , two words of nonce (essentially additional stream position bits) , and four fixed words :\nThe constant words spell \"expand 32-byte k\" in ASCII (i.e. the 4 words are \"expa\", \"nd 3\", \"2-by\", and \"te k\").\nThis is an example of a [nothing-up-my-sleeve number](https://bliptext.com/articles/nothing-up-my-sleeve-number).\nThe core operation in Salsa20 is the quarter-round that takes a four-word input and produces a four-word output:\nb ^= (a + d) <<< 7;\nc ^= (b + a) <<< 9;\nd ^= (c + b) <<< 13;\na ^= (d + c) <<< 18;\nOdd-numbered rounds apply to each of the four columns in the 4×4 matrix, and even-numbered rounds apply it to each of the four rows.\nTwo consecutive rounds (column-round and row-round) together are called a double-round:\n// Odd round\nQR( 0, 4, 8, 12) // column 1\nQR( 5, 9, 13, 1) // column 2\nQR(10, 14, 2, 6) // column 3\nQR(15, 3, 7, 11) // column 4\n// Even round\nQR( 0, 1, 2, 3) // row 1\nQR( 5, 6, 7, 4) // row 2\nQR(10, 11, 8, 9) // row 3\nQR(15, 12, 13, 14) // row 4\nAn implementation in C/C++ appears below.\nIn the last line, the mixed array is added, word by word, to the original array to obtain its 64-byte key stream block.\nThis is important because the mixing rounds on their own are invertible.\nIn other words, applying the reverse operations would produce the original 4×4 matrix, including the key.\nAdding the mixed array to the original makes it impossible to recover the input.\n(This same technique is widely used in hash functions from [MD4](https://bliptext.com/articles/md4) through [SHA-2](https://bliptext.com/articles/sha-2).)\nSalsa20 performs 20 rounds of mixing on its input.\nHowever, reduced-round variants Salsa20/8 and Salsa20/12 using 8 and 12 rounds respectively have also been introduced.\nThese variants were introduced to complement the original Salsa20, not to replace it, and perform better in the eSTREAM benchmarks than Salsa20, though with a correspondingly lower security margin.\n\n## XSalsa20 with 192-bit nonce\nIn 2008, Bernstein proposed a variant of Salsa20 with 192-bit nonces called XSalsa20.\nXSalsa20 is [provably secure](https://bliptext.com/articles/provably-secure) if Salsa20 is secure, but is more suitable for applications where longer nonces are desired.\nXSalsa20 feeds the key and the first 128 bits of the nonce into one block of Salsa20 (without the final addition, which may either be omitted, or subtracted after a standard Salsa20 block), and uses 256 bits of the output as the key for standard Salsa20 using the last 64 bits of the nonce and the stream position.\nSpecifically, the 256 bits of output used are those corresponding to the non-secret portions of the input: indexes 0, 5, 10, 15, 6, 7, 8 and 9.\n\n# eSTREAM selection of Salsa20\nSalsa20/12 has been selected as a Phase 3 design for Profile 1 (software) by the [eSTREAM](https://bliptext.com/articles/estream) project, receiving the highest weighted voting score of any Profile 1 algorithm at the end of Phase 2.\nSalsa20 had previously been selected as a Phase 2 Focus design for Profile 1 (software) and as a Phase 2 design for Profile 2 (hardware) by the eSTREAM project, but was not advanced to Phase 3 for Profile 2 because eSTREAM felt that it was probably not a good candidate for extremely resource-constrained hardware environments.\nThe eSTREAM committee recommends the use of Salsa20/12, the 12-round variant, for \"combining very good performance with a comfortable margin of security.\"\n\n# Cryptanalysis of Salsa20\n, there are no published attacks on Salsa20/12 or the full Salsa20/20; the best attack known breaks 8 of the 12 or 20 rounds.\nIn 2005, Paul Crowley reported an attack on Salsa20/5 with an estimated time complexity of 2165 and won Bernstein's US$1000 prize for \"most interesting Salsa20 cryptanalysis\".\nThis attack and all subsequent attacks are based on [truncated differential cryptanalysis](https://bliptext.com/articles/truncated-differential-cryptanalysis).\nIn 2006, Fischer, Meier, Berbain, Biasse, and Robshaw reported an attack on Salsa20/6 with estimated time complexity of 2177, and a related-key attack on Salsa20/7 with estimated time complexity of 2217.\nIn 2007, Tsunoo et al. announced a cryptanalysis of Salsa20 which breaks 8 out of 20 rounds to recover the 256-bit secret key in 2255 operations, using 211.37 keystream pairs.\nHowever, this attack does not seem to be competitive with the brute force attack.\nIn 2008, Aumasson, Fischer, Khazaei, Meier, and Rechberger reported a cryptanalytic attack against Salsa20/7 with a time complexity of 2151, and they reported an attack against Salsa20/8 with an estimated time complexity of 2251.\nThis attack makes use of the new concept of probabilistic neutral key bits for probabilistic detection of a truncated differential.\nThe attack can be adapted to break Salsa20/7 with a 128-bit key.\nIn 2012, the attack by Aumasson et al. was improved by Shi et al. against Salsa20/7 (128-bit key) to a time complexity of 2109 and Salsa20/8 (256-bit key) to 2250.\nIn 2013, Mouha and Preneel published a proof that 15 rounds of Salsa20 was 128-bit secure against [differential cryptanalysis](https://bliptext.com/articles/differential-cryptanalysis).\n(Specifically, it has no differential characteristic with higher probability than 2−130, so differential cryptanalysis would be more difficult than 128-bit key exhaustion.)\n\n# ChaCha variant\nIn 2008, Bernstein published the closely related **ChaCha** family of ciphers, which aim to increase the diffusion per round while achieving the same or slightly better performance.\nThe Aumasson et al. paper also attacks ChaCha, achieving one round fewer (for 256-bit ChaCha6 with complexity 2139, ChaCha7 with complexity 2248, and 128-bit ChaCha6 within 2107) but claims that the attack fails to break 128-bit ChaCha7.\nLike Salsa20, ChaCha's initial state includes a 128-bit constant, a 256-bit key, a 64-bit counter, and a 64-bit nonce (in the original version; as described later, a version of ChaCha from is slightly different), arranged as a 4×4 matrix of 32-bit words.\nBut ChaCha re-arranges some of the words in the initial state:\nThe constant is the same as Salsa20 (\"expand 32-byte k\").\nChaCha replaces the Salsa20 quarter-round with:\na += b; d ^= a; d <<<= 16;\nc += d; b ^= c; b <<<= 12;\na += b; d ^= a; d <<<= 8;\nc += d; b ^= c; b <<<= 7;\nNotice that this version updates each word twice, while Salsa20's quarter round updates each word only once.\nIn addition, the ChaCha quarter-round diffuses changes more quickly.\nOn average, after changing 1 input bit the Salsa20 quarter-round will change 8 output bits while ChaCha will change 12.5 output bits.\nThe ChaCha quarter round has the same number of adds, xors, and bit rotates as the Salsa20 quarter-round, but the fact that two of the rotates are multiples of 8 allows for a small optimization on some architectures including x86.\nAdditionally, the input formatting has been rearranged to support an efficient [SSE](https://bliptext.com/articles/streaming-simd-extensions) implementation optimization discovered for Salsa20.\nRather than alternating rounds down columns and across rows, they are performed down columns and along diagonals.\nLike Salsa20, ChaCha arranges the sixteen 32-bit words in a 4×4 matrix.\nIf we index the matrix elements from 0 to 15\nthen a double round in ChaCha is:\n// Odd round\nQR(0, 4, 8, 12) // column 1\nQR(1, 5, 9, 13) // column 2\nQR(2, 6, 10, 14) // column 3\nQR(3, 7, 11, 15) // column 4\n// Even round\nQR(0, 5, 10, 15) // diagonal 1 (main diagonal)\nQR(1, 6, 11, 12) // diagonal 2\nQR(2, 7, 8, 13) // diagonal 3\nQR(3, 4, 9, 14) // diagonal 4\nChaCha20 uses 10 iterations of the double round.\nAn implementation in C/C++ appears below.\nChaCha is the basis of the [BLAKE hash function](https://bliptext.com/articles/blake-hash-function), a finalist in the [NIST hash function competition](https://bliptext.com/articles/nist-hash-function-competition), and its faster successors BLAKE2 and BLAKE3.\nIt also defines a variant using sixteen 64-bit words (1024 bits of state), with correspondingly adjusted rotation constants.\n\n## XChaCha\nAlthough not announced by Bernstein, the security proof of XSalsa20 extends straightforwardly to an analogous XChaCha cipher.\nUse the key and the first 128 bits of the nonce (in input words 12 through 15) to form a ChaCha input block, then perform the block operation (omitting the final addition).\nOutput words 0–3 and 12–15 (those words corresponding to non-key words of the input) then form the key used for ordinary ChaCha (with the last 64 bits of nonce and 64 bits of block counter).\n\n## Reduced-round ChaCha\nAumasson argues in 2020 that 8 rounds of ChaCha (ChaCha8) probably provides enough resistance to future cryptanalysis for the same [security level](https://bliptext.com/articles/security-level), yielding a 2.5× speedup.\nA compromise ChaCha12 (based on the eSTREAM recommendation of a 12-round Salsa) also sees some use.\nThe eSTREAM benchmarking suite includes ChaCha8 and ChaCha12.\n\n## ChaCha20 adoption\n[Google](https://bliptext.com/articles/google) had selected ChaCha20 along with Bernstein's [Poly1305](https://bliptext.com/articles/poly1305) message authentication code in [SPDY](https://bliptext.com/articles/spdy), which was intended as a replacement for [TLS](https://bliptext.com/articles/transport-layer-security) over [TCP](https://bliptext.com/articles/transmission-control-protocol).\nIn the process, they proposed a new [authenticated encryption](https://bliptext.com/articles/authenticated-encryption) construction combining both algorithms, which is called [ChaCha20-Poly1305](https://bliptext.com/articles/chacha20-poly1305).\nChaCha20 and Poly1305 are now used in the [QUIC](https://bliptext.com/articles/quic) protocol, which replaces [SPDY](https://bliptext.com/articles/spdy) and is used by [HTTP/3](https://bliptext.com/articles/http-3).\nShortly after Google's adoption for TLS, both the ChaCha20 and Poly1305 algorithms were also used for a new cipher in [OpenSSH](https://bliptext.com/articles/openssh).\nSubsequently, this made it possible for OpenSSH to avoid any dependency on [OpenSSL](https://bliptext.com/articles/openssl), via a compile-time option.\nChaCha20 is also used for the random number generator in [FreeBSD](https://bliptext.com/articles/freebsd), [OpenBSD](https://bliptext.com/articles/openbsd), and [NetBSD](https://bliptext.com/articles/netbsd) operating systems, instead of the broken [RC4](https://bliptext.com/articles/rc4), and in [DragonFly BSD](https://bliptext.com/articles/dragonfly-bsd) for the [CSPRNG](https://bliptext.com/articles/csprng) subroutine of the kernel.\nStarting from version 4.8, the Linux kernel uses the ChaCha20 algorithm to generate data for the nonblocking [/dev/urandom](https://bliptext.com/articles/dev-random) device.\nChaCha8 is used for the default PRNG in [Golang](https://bliptext.com/articles/golang).\nRust's CSPRNG uses ChaCha12.\nChaCha20 usually offers better performance than the more prevalent [Advanced Encryption Standard](https://bliptext.com/articles/advanced-encryption-standard) (AES) algorithm on systems where the CPU does not feature AES acceleration (such as the [AES instruction set](https://bliptext.com/articles/aes-instruction-set) for x86 processors).\nAs a result, ChaCha20 is sometimes preferred over AES in certain use cases involving [mobile devices](https://bliptext.com/articles/mobile-device), which mostly use [ARM](https://bliptext.com/articles/arm-architecture)-based CPUs.\nSpecialized hardware accelerators for ChaCha20 are also less complex compared to AES accelerators.\nChaCha20-Poly1305 (IETF version; see below) is the exclusive algorithm used by the [WireGuard](https://bliptext.com/articles/wireguard) VPN system, as of protocol version 1.\n\n## Internet standards\nAn implementation reference for ChaCha20 has been published in.\nThe [IETF](https://bliptext.com/articles/ietf)'s implementation modified Bernstein's published algorithm by changing the 64-bit nonce and 64-bit block counter to a 96-bit nonce and 32-bit block counter.\nThe name was not changed when the algorithm was modified, as it is cryptographically insignificant (both form what a cryptographer would recognize as a 128-bit nonce), but the interface change could be a source of confusion for developers.\nBecause of the reduced block counter, the maximum message length that can be safely encrypted by the IETF's variant is 232 blocks of 64 bytes (256 [GiB](https://bliptext.com/articles/gibibyte)).\nFor applications where this is not enough, such as file or disk encryption, proposes using the original algorithm with 64-bit nonce.\nUse of ChaCha20 in [IKE](https://bliptext.com/articles/internet-key-exchange) and [IPsec](https://bliptext.com/articles/ipsec) has been standardized in.\nStandardization of its use in TLS is published in.\nIn 2018, RFC 7539 was obsoleted by.\nRFC 8439 merges in some errata and adds additional security considerations.","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-25T22:22:52.375Z","updated_at":"2025-01-25T22:22:52.375Z","search_vector":"'salsa20':1","search_content":" \n \n**Name:** Salsa20 \n**Designers:** [Daniel J. Bernstein](https://bliptext.com/articles/daniel-j-bernstein) \n**Publish Date:** 2007 (designed 2005) \n**Derived To:** ChaCha \n**Related To:** Rumba20 \n**Certification:** [eSTREAM](https://bliptext.com/articles/estream) portfolio \n**Key Size:** 128 or 256 bits \n**State Size:** 512 bits \n**Structure:** ARX \n**Rounds:** 20 \n**Speed:** 3.91 [cpb](https://bliptext.com/articles/cycles-per-byte) on an Intel Core 2 Duo \n**Cryptanalysis:** 2008 cryptanalysis breaks 8 out of 20 rounds to recover the 256-bit secret key in 2251 operations, using 231 keystream pairs. \n \n\n# \n**Salsa20** and the closely related **ChaCha** are [stream ciphers](https://bliptext.com/articles/stream-cipher) developed by [Daniel J. Bernstein](https://bliptext.com/articles/daniel-j-bernstein).\nSalsa20, the original cipher, was designed in 2005, then later submitted to the [eSTREAM](https://bliptext.com/articles/estream) European Union cryptographic validation process by Bernstein.\nChaCha is a modification of Salsa20 published in 2008.\nIt uses a new round function that increases diffusion and increases performance on some architectures.\nBoth ciphers are built on a [pseudorandom function](https://bliptext.com/articles/pseudorandom-function) based on [add–rotate–XOR](https://bliptext.com/articles/block-cipher) (ARX) operations — 32-bit addition, bitwise addition (XOR) and [rotation](https://bliptext.com/articles/bit-rotation) operations.\nThe core function maps a [256-bit](https://bliptext.com/articles/256-bit) [key](https://bliptext.com/articles/key-size), a 64-bit [nonce](https://bliptext.com/articles/cryptographic-nonce), and a 64-bit counter to a 512-bit block of the [key](https://bliptext.com/articles/key-size) stream (a Salsa version with a 128-bit [key](https://bliptext.com/articles/key-size) also exists).\nThis gives Salsa20 and ChaCha the unusual advantage that the user can efficiently seek to any position in the key stream in constant time.\nSalsa20 offers speeds of around 4–14 [cycles per byte](https://bliptext.com/articles/cycles-per-byte) in software on modern [x86](https://bliptext.com/articles/x86) processors, and reasonable hardware performance.\nIt is not patented, and Bernstein has written several [public domain](https://bliptext.com/articles/public-domain) implementations optimized for common architectures.\n\n# Structure\nInternally, the cipher uses bitwise addition ⊕ ([exclusive OR](https://bliptext.com/articles/exclusive-or)), 32-bit addition [mod](https://bliptext.com/articles/modular-arithmetic) 232 ⊞, and constant-distance rotation operations <<< on an internal state of sixteen 32-bit words.\nUsing only [add-rotate-xor operations](https://bliptext.com/articles/block-cipher) avoids the possibility of [timing attacks](https://bliptext.com/articles/timing-attack) in software implementations.\nThe internal state is made of sixteen 32-bit words arranged as a 4×4 matrix.\nThe initial state is made up of eight words of key, two words of stream position , two words of nonce (essentially additional stream position bits) , and four fixed words :\nThe constant words spell \"expand 32-byte k\" in ASCII (i.e. the 4 words are \"expa\", \"nd 3\", \"2-by\", and \"te k\").\nThis is an example of a [nothing-up-my-sleeve number](https://bliptext.com/articles/nothing-up-my-sleeve-number).\nThe core operation in Salsa20 is the quarter-round that takes a four-word input and produces a four-word output:\nb ^= (a + d) <<< 7;\nc ^= (b + a) <<< 9;\nd ^= (c + b) <<< 13;\na ^= (d + c) <<< 18;\nOdd-numbered rounds apply to each of the four columns in the 4×4 matrix, and even-numbered rounds apply it to each of the four rows.\nTwo consecutive rounds (column-round and row-round) together are called a double-round:\n// Odd round\nQR( 0, 4, 8, 12) // column 1\nQR( 5, 9, 13, 1) // column 2\nQR(10, 14, 2, 6) // column 3\nQR(15, 3, 7, 11) // column 4\n// Even round\nQR( 0, 1, 2, 3) // row 1\nQR( 5, 6, 7, 4) // row 2\nQR(10, 11, 8, 9) // row 3\nQR(15, 12, 13, 14) // row 4\nAn implementation in C/C++ appears below.\nIn the last line, the mixed array is added, word by word, to the original array to obtain its 64-byte key stream block.\nThis is important because the mixing rounds on their own are invertible.\nIn other words, applying the reverse operations would produce the original 4×4 matrix, including the key.\nAdding the mixed array to the original makes it impossible to recover the input.\n(This same technique is widely used in hash functions from [MD4](https://bliptext.com/articles/md4) through [SHA-2](https://bliptext.com/articles/sha-2).)\nSalsa20 performs 20 rounds of mixing on its input.\nHowever, reduced-round variants Salsa20/8 and Salsa20/12 using 8 and 12 rounds respectively have also been introduced.\nThese variants were introduced to complement the original Salsa20, not to replace it, and perform better in the eSTREAM benchmarks than Salsa20, though with a correspondingly lower security margin.\n\n## XSalsa20 with 192-bit nonce\nIn 2008, Bernstein proposed a variant of Salsa20 with 192-bit nonces called XSalsa20.\nXSalsa20 is [provably secure](https://bliptext.com/articles/provably-secure) if Salsa20 is secure, but is more suitable for applications where longer nonces are desired.\nXSalsa20 feeds the key and the first 128 bits of the nonce into one block of Salsa20 (without the final addition, which may either be omitted, or subtracted after a standard Salsa20 block), and uses 256 bits of the output as the key for standard Salsa20 using the last 64 bits of the nonce and the stream position.\nSpecifically, the 256 bits of output used are those corresponding to the non-secret portions of the input: indexes 0, 5, 10, 15, 6, 7, 8 and 9.\n\n# eSTREAM selection of Salsa20\nSalsa20/12 has been selected as a Phase 3 design for Profile 1 (software) by the [eSTREAM](https://bliptext.com/articles/estream) project, receiving the highest weighted voting score of any Profile 1 algorithm at the end of Phase 2.\nSalsa20 had previously been selected as a Phase 2 Focus design for Profile 1 (software) and as a Phase 2 design for Profile 2 (hardware) by the eSTREAM project, but was not advanced to Phase 3 for Profile 2 because eSTREAM felt that it was probably not a good candidate for extremely resource-constrained hardware environments.\nThe eSTREAM committee recommends the use of Salsa20/12, the 12-round variant, for \"combining very good performance with a comfortable margin of security.\"\n\n# Cryptanalysis of Salsa20\n, there are no published attacks on Salsa20/12 or the full Salsa20/20; the best attack known breaks 8 of the 12 or 20 rounds.\nIn 2005, Paul Crowley reported an attack on Salsa20/5 with an estimated time complexity of 2165 and won Bernstein's US$1000 prize for \"most interesting Salsa20 cryptanalysis\".\nThis attack and all subsequent attacks are based on [truncated differential cryptanalysis](https://bliptext.com/articles/truncated-differential-cryptanalysis).\nIn 2006, Fischer, Meier, Berbain, Biasse, and Robshaw reported an attack on Salsa20/6 with estimated time complexity of 2177, and a related-key attack on Salsa20/7 with estimated time complexity of 2217.\nIn 2007, Tsunoo et al. announced a cryptanalysis of Salsa20 which breaks 8 out of 20 rounds to recover the 256-bit secret key in 2255 operations, using 211.37 keystream pairs.\nHowever, this attack does not seem to be competitive with the brute force attack.\nIn 2008, Aumasson, Fischer, Khazaei, Meier, and Rechberger reported a cryptanalytic attack against Salsa20/7 with a time complexity of 2151, and they reported an attack against Salsa20/8 with an estimated time complexity of 2251.\nThis attack makes use of the new concept of probabilistic neutral key bits for probabilistic detection of a truncated differential.\nThe attack can be adapted to break Salsa20/7 with a 128-bit key.\nIn 2012, the attack by Aumasson et al. was improved by Shi et al. against Salsa20/7 (128-bit key) to a time complexity of 2109 and Salsa20/8 (256-bit key) to 2250.\nIn 2013, Mouha and Preneel published a proof that 15 rounds of Salsa20 was 128-bit secure against [differential cryptanalysis](https://bliptext.com/articles/differential-cryptanalysis).\n(Specifically, it has no differential characteristic with higher probability than 2−130, so differential cryptanalysis would be more difficult than 128-bit key exhaustion.)\n\n# ChaCha variant\nIn 2008, Bernstein published the closely related **ChaCha** family of ciphers, which aim to increase the diffusion per round while achieving the same or slightly better performance.\nThe Aumasson et al. paper also attacks ChaCha, achieving one round fewer (for 256-bit ChaCha6 with complexity 2139, ChaCha7 with complexity 2248, and 128-bit ChaCha6 within 2107) but claims that the attack fails to break 128-bit ChaCha7.\nLike Salsa20, ChaCha's initial state includes a 128-bit constant, a 256-bit key, a 64-bit counter, and a 64-bit nonce (in the original version; as described later, a version of ChaCha from is slightly different), arranged as a 4×4 matrix of 32-bit words.\nBut ChaCha re-arranges some of the words in the initial state:\nThe constant is the same as Salsa20 (\"expand 32-byte k\").\nChaCha replaces the Salsa20 quarter-round with:\na += b; d ^= a; d <<<= 16;\nc += d; b ^= c; b <<<= 12;\na += b; d ^= a; d <<<= 8;\nc += d; b ^= c; b <<<= 7;\nNotice that this version updates each word twice, while Salsa20's quarter round updates each word only once.\nIn addition, the ChaCha quarter-round diffuses changes more quickly.\nOn average, after changing 1 input bit the Salsa20 quarter-round will change 8 output bits while ChaCha will change 12.5 output bits.\nThe ChaCha quarter round has the same number of adds, xors, and bit rotates as the Salsa20 quarter-round, but the fact that two of the rotates are multiples of 8 allows for a small optimization on some architectures including x86.\nAdditionally, the input formatting has been rearranged to support an efficient [SSE](https://bliptext.com/articles/streaming-simd-extensions) implementation optimization discovered for Salsa20.\nRather than alternating rounds down columns and across rows, they are performed down columns and along diagonals.\nLike Salsa20, ChaCha arranges the sixteen 32-bit words in a 4×4 matrix.\nIf we index the matrix elements from 0 to 15\nthen a double round in ChaCha is:\n// Odd round\nQR(0, 4, 8, 12) // column 1\nQR(1, 5, 9, 13) // column 2\nQR(2, 6, 10, 14) // column 3\nQR(3, 7, 11, 15) // column 4\n// Even round\nQR(0, 5, 10, 15) // diagonal 1 (main diagonal)\nQR(1, 6, 11, 12) // diagonal 2\nQR(2, 7, 8, 13) // diagonal 3\nQR(3, 4, 9, 14) // diagonal 4\nChaCha20 uses 10 iterations of the double round.\nAn implementation in C/C++ appears below.\nChaCha is the basis of the [BLAKE hash function](https://bliptext.com/articles/blake-hash-function), a finalist in the [NIST hash function competition](https://bliptext.com/articles/nist-hash-function-competition), and its faster successors BLAKE2 and BLAKE3.\nIt also defines a variant using sixteen 64-bit words (1024 bits of state), with correspondingly adjusted rotation constants.\n\n## XChaCha\nAlthough not announced by Bernstein, the security proof of XSalsa20 extends straightforwardly to an analogous XChaCha cipher.\nUse the key and the first 128 bits of the nonce (in input words 12 through 15) to form a ChaCha input block, then perform the block operation (omitting the final addition).\nOutput words 0–3 and 12–15 (those words corresponding to non-key words of the input) then form the key used for ordinary ChaCha (with the last 64 bits of nonce and 64 bits of block counter).\n\n## Reduced-round ChaCha\nAumasson argues in 2020 that 8 rounds of ChaCha (ChaCha8) probably provides enough resistance to future cryptanalysis for the same [security level](https://bliptext.com/articles/security-level), yielding a 2.5× speedup.\nA compromise ChaCha12 (based on the eSTREAM recommendation of a 12-round Salsa) also sees some use.\nThe eSTREAM benchmarking suite includes ChaCha8 and ChaCha12.\n\n## ChaCha20 adoption\n[Google](https://bliptext.com/articles/google) had selected ChaCha20 along with Bernstein's [Poly1305](https://bliptext.com/articles/poly1305) message authentication code in [SPDY](https://bliptext.com/articles/spdy), which was intended as a replacement for [TLS](https://bliptext.com/articles/transport-layer-security) over [TCP](https://bliptext.com/articles/transmission-control-protocol).\nIn the process, they proposed a new [authenticated encryption](https://bliptext.com/articles/authenticated-encryption) construction combining both algorithms, which is called [ChaCha20-Poly1305](https://bliptext.com/articles/chacha20-poly1305).\nChaCha20 and Poly1305 are now used in the [QUIC](https://bliptext.com/articles/quic) protocol, which replaces [SPDY](https://bliptext.com/articles/spdy) and is used by [HTTP/3](https://bliptext.com/articles/http-3).\nShortly after Google's adoption for TLS, both the ChaCha20 and Poly1305 algorithms were also used for a new cipher in [OpenSSH](https://bliptext.com/articles/openssh).\nSubsequently, this made it possible for OpenSSH to avoid any dependency on [OpenSSL](https://bliptext.com/articles/openssl), via a compile-time option.\nChaCha20 is also used for the random number generator in [FreeBSD](https://bliptext.com/articles/freebsd), [OpenBSD](https://bliptext.com/articles/openbsd), and [NetBSD](https://bliptext.com/articles/netbsd) operating systems, instead of the broken [RC4](https://bliptext.com/articles/rc4), and in [DragonFly BSD](https://bliptext.com/articles/dragonfly-bsd) for the [CSPRNG](https://bliptext.com/articles/csprng) subroutine of the kernel.\nStarting from version 4.8, the Linux kernel uses the ChaCha20 algorithm to generate data for the nonblocking [/dev/urandom](https://bliptext.com/articles/dev-random) device.\nChaCha8 is used for the default PRNG in [Golang](https://bliptext.com/articles/golang).\nRust's CSPRNG uses ChaCha12.\nChaCha20 usually offers better performance than the more prevalent [Advanced Encryption Standard](https://bliptext.com/articles/advanced-encryption-standard) (AES) algorithm on systems where the CPU does not feature AES acceleration (such as the [AES instruction set](https://bliptext.com/articles/aes-instruction-set) for x86 processors).\nAs a result, ChaCha20 is sometimes preferred over AES in certain use cases involving [mobile devices](https://bliptext.com/articles/mobile-device), which mostly use [ARM](https://bliptext.com/articles/arm-architecture)-based CPUs.\nSpecialized hardware accelerators for ChaCha20 are also less complex compared to AES accelerators.\nChaCha20-Poly1305 (IETF version; see below) is the exclusive algorithm used by the [WireGuard](https://bliptext.com/articles/wireguard) VPN system, as of protocol version 1.\n\n## Internet standards\nAn implementation reference for ChaCha20 has been published in.\nThe [IETF](https://bliptext.com/articles/ietf)'s implementation modified Bernstein's published algorithm by changing the 64-bit nonce and 64-bit block counter to a 96-bit nonce and 32-bit block counter.\nThe name was not changed when the algorithm was modified, as it is cryptographically insignificant (both form what a cryptographer would recognize as a 128-bit nonce), but the interface change could be a source of confusion for developers.\nBecause of the reduced block counter, the maximum message length that can be safely encrypted by the IETF's variant is 232 blocks of 64 bytes (256 [GiB](https://bliptext.com/articles/gibibyte)).\nFor applications where this is not enough, such as file or disk encryption, proposes using the original algorithm with 64-bit nonce.\nUse of ChaCha20 in [IKE](https://bliptext.com/articles/internet-key-exchange) and [IPsec](https://bliptext.com/articles/ipsec) has been standardized in.\nStandardization of its use in TLS is published in.\nIn 2018, RFC 7539 was obsoleted by.\nRFC 8439 merges in some errata and adds additional security considerations.","revisionCount":0},"hasMore":false,"nextCursor":null}

History