Salsa20
Salsa20は、ダニエル・バーンスタインによって開発されたストリーム暗号である。32-bit addition、XORおよびキャリーなしローテートに基づく疑似乱数生成によって構成される。中心となる関数は、256ビットの鍵、64ビットのnonce、そして64ビットの（ストリームの位置を示す）カウンタを入力とし、512ビットの鍵ストリーム１ブロックを出力する（鍵長128ビットのバージョンも存在する）。これにより、Salsa20には、任意の位置のストリームを一定時間で探索することが可能となる。最近のx86プロセッサでは、ソフトウェア実装で4–14 cycles per byte程度の速度を示す。Salsa20は特許で保護されておらず、設計者であるバーンスタインによっていくつかのアーキテクチャ向けの最適化実装がパブリックドメインで公開されている。
Salsa20は、16ワード（１ワードは32ビット）からなる初期状態に対して、ビットごとのXOR、32-bitの加算 mod 2、固定移動距離のローテートを行なう。XOR、加算、ローテーションのみを用いることで、ソフトウェア実装におけるタイミング攻撃を回避することができる。
内部状態は16ワードからなり、4×4の行列で表現される。
初期状態は、8ワードの鍵(Key)、2ワードのストリーム位置(Pos)、2ワードのnonce、4つの固定のワード(Cons)から、次のように決まる。
固定ワードは、"expand 32-byte k"をASCIIコードで表したもの (つまり、４つのワードはそれぞれ、"expa", "nd 3", "2-by", "te k"）であり、nothing up my sleeve number の一例である。
Salsa20の演算の中心は、1/4ラウンド関数codice_1であり、これは４つの入力ワードから４つの出力ワードを以下のように生成する。
奇数ラウンドではcodice_1は4×4行列の４行それぞれに適用され、偶数ラウンドでは４つの列それぞれに適用される。連続した２ラウンド（行ラウンドと列ラウンド）はdouble-roundと呼ばれる。
C/C++ での実装は以下のとおり：
 b ^= ROTL(a + d, 7), \
void salsa20_block(uint32_t out[16], uint32_t const in[16])
最後の行で、かき混ぜられた配列codice_3を、ワードごとに元の配列codice_4に加えて、64バイトの出力ブロックcodice_5とする。この操作は重要である。なぜなら、かき混ぜ操作自体は可逆だからである。つまり、この最後の操作が無かった場合、出力である鍵ストリームブロックにかき混ぜ操作を逆に施すことで（鍵を知らなくても可能であることに注意）、鍵を含む初期状態を復元できてしまう。かき混ぜられた配列を元の配列に加えることで、このように入力を復元することが不可能となる。（これと同様のテクニックは、MD4からSHA-2にいたるハッシュ関数の中で広く使われている。）
Salsa20は、入力に対して20ラウンドのかき混ぜ操作を行う。
また、ラウンド数をそれぞれ8、12に削減したSalsa20/8 および Salsa20/12と呼ばれる変種も存在する。これらはSalsa20を補完するものであり、eSTREAMのベンチマークでは、オリジナルよりも良い性能を出しているが、 それに応じてセキュリティマージンは小さくなる。
Salsa20は、eStreamプロジェクトにおいて、Profile 1（ソフトウェア）のPhase 3デザインに選定された（Phase 2においては、他のどのアルゴリズムよりも高いスコアを得た）。Profile 2（ハードウェア）のPhase 2デザインにも選出されていたが、こちらはPhase 3には進めなかった。これは、制約の多いハードウェア環境では十分な性能を発揮できないと判断されたためである。
2013年現在、Salsa20/12およびSalsa20/20の解読に成功した例はない。最良の攻撃法では、12あるいは20ラウンド中8ラウンドまで解読されている。
2005年、Paul Crowleyはおおよそ2の試行でSalsa20/5を解読する方法を報告し、「Salsa20に対する最も興味深い攻撃法」としてBernsteinから1000ドルの賞金を獲得した。これは切詰差分解読法に基づいたものである。2006年、Fischer, Meier, Berbain, Biasse, and Robshawは、切詰差分解読法によって2の試行でSalsa20/6を、関連鍵攻撃によって2の試行でSalsa20/7を解読する方法を報告した。
2007年、Tsunooらは、2の鍵とストリームのペアを用いて、2の試行によってSalsa20の20ラウンド中8ラウンドまでの解読を報告したが、これは総当たり攻撃に近いものである。
2008年、 Aumasson, Fischer, Khazaei, Meier, and Rechbergerは2の試行によってSalsa20/7を解読し、2の試行によって初めてSalsa20/8を解読した
2012年、Aumassonらの手法はShiらによって改良され、128ビット鍵のSalsa20/7では2の試行で、256ビット鍵のSalsa20/8では2の試行となった。
2013年、MouhaとPreneelは、差分解読法に対してSalsa20は15ラウンド目まで128ビットの安全性を有していることを示した。差分解読法での確率は2より低く、これは128ビットの鍵を使い尽くすより困難である。
2008年、バーンスタインはChaChaと呼ばれる変種を発表した。これはラウンドごとの発散を大きくすることでパフォーマンスの向上を図ったものである。AumassonらはChaChaに対しても攻撃を試みたが、Salsa20よりも1ラウンド少ない結果となった（256ビットのChaCha6で2、ChaCha7で2の試行。128ビットのChaCha6で2の試行。128ビットのChaCha7では攻撃に失敗）。
Salsa20と同様に、ChaChaの初期状態は128ビットの定数、256ビットの鍵、64ビットのカウンタ、64ビットのnonceを含む32ビットワードの4×4の行列であるが、並び順が変更されている。
定数はSalsa20と同じ"expand 32-byte k"である。ChaChaでは、Salsa20の1/4ラウンド関数codice_1が
に置き換えられている。Salsa20の1/4ラウンド関数では各ワードが1回しか更新されないのに対し、ChaChaの関数では2回更新されることに注意。また、ChaChaの1/4ラウンド関数は、変化をよりすばやく拡散する。Salsa20の1/4ラウンド関数の入力の1ビットを変更すると、平均で出力の8ビットが変化するが、ChaChaの場合は12.5ビットが変化する。
さらに、ChaChaとSalsaとでは、1/4ラウンド関数中の加算、xor、ビットローテーションの数が同じであるが、
ローテートのうち2つが8の倍数であることから、x86を含むいくつかのアーキテクチャでは、最適化が可能となる
加えて、SSE向けに最適化することが可能であることがSalsa20において発見されており、ChaChaではこれを利用できるように入力フォーマットが変更されている。　ラウンドごとに列方向と行方向を交互に繰り返すのではなく、列方向と角線方向を繰り返す。
ChaCha20ではこのdouble-roundを10回繰り返す。
C/C++ での実装は以下のとおり：
 a += b, d ^= a, d = ROTL(d,16), \
void chacha_block(uint32_t out[16], uint32_t const in[16])
ChaChaはSHA-3選定の最終候補であったBLAKEの基礎となっている。
Googleは、共通鍵暗号としてChaCha20、メッセージ認証符号として同じくバーンスタインによるPoly1305を組み合わせたものを、RC4に代わるインターネットセキュリティで利用可能なストリーム暗号として提唱している。Google ChromeおよびGoogleのウェブサービスにおけるTLS/SSL通信 (https) においてChaCha20-Poly1305が実装されている。
GoogleによるTLSでの採用に続き、ChaCha20とPoly1305の組み合わせは chacha20-poly1305@openssh.com としてOpenSSHに採用された。これにより、OpenSSHがOpenSSLに依存する必要がなくなった。
ChaCha20は、脆弱性が指摘されているRC4に代わり、OpenBSD、NetBSD、Dragonfly BSDにおける乱数生成器 arc4random に利用されている。
ChaCha20そのものは、RFC 7539 として標準化されている。また、Internet Key Exchange (IKE) およびIPSecでの利用については RFC 7634 で標準化されており、TLS/SSLにおけるChaCha20/Poly1305の利用は、RFC 7905 として標準化された。