<blockquote>
  <p>What is so special about chacha20 stream cipher along with poly1305 for message authentication codes?</p>
</blockquote>

<p>There is nothing special about the combination. It's just a combination of two constructions (ChaCha20 for the stream cipher, Poly1305 for MAC) that are designed with similar goals in mind:</p>

<ul>
<li>Easy to write a correct implementation in software</li>
<li>Optimized for performance of software implementations running on general purpose hardware. This is in contrast to many cryptographic primitives which are optimized for hardware implementation, but are suboptimal in software. This is mainly due to the use of integer addition operations in ChaCha20.</li>
<li>128-bit security level.</li>
</ul>

<p>Furthermore the key derivation is informally standardized, allowing using a single key for both encryption and authentication. Having real-world constructions (for example OpenSSH) use this constructions gives confidence about security.</p>

<blockquote>
  <p>What does it mean that one can efficiently seek to any position in the key stream in constant time?</p>
</blockquote>

<p>Assume you're given n GiB of incoming encrypted data, but for some reason you're only interested in the last 1 MiB. With some ciphers, you'd need to do O(n) work to "skip" the first n GiB. ChaCha20, like most stream ciphers, permits decrypting any one MiB with same amount of work regardless of its position - essentially deriving the cipher output for arbitrary positions (aligned to a 64 byte boundary at least) with as much work as decoding sequentially.</p>

CC BY-SA 4.0
2019-02-27T21:59:56.940Z
"permits decrypting the last", perhaps worth mentioning that this is a generic property of stream ciphers-- also encoding and decoding in parallel and being able to decode data that has some lost chunks without totally desyncing.
G. Maxwell
CC BY-SA 4.0
2019-02-28T03:29:32.687Z
@G. Maxwell Good point, fixed.
Pieter Wuille
CC BY-SA 4.0
2019-02-28T04:39:21.503Z
What do you mean with encoding and decoding in parallel? Am I correct that being able to decode data that has lost chunks comes from the property that any data chunk can be decoded independent of the rest of the data stream?
Rene Pickhardt
CC BY-SA 4.0
2019-02-27T20:17:51.993Z
2019-02-28T03:29:16.677Z
2019-02-28T03:29:16.677Z
Pieter Wuille
<p>I am currently trying to dissect the low level cryptography protocols of the lightning network and I realize that in many places chacha20 is being used. I tried <a href="https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant" rel="nofollow noreferrer">reading about it in the Wikipedia Article</a> there it says: </p>

<blockquote>
  <p>This gives Salsa20 and ChaCha the unusual advantage that the user can efficiently seek to any position in the key stream in constant time. Salsa20 offers speeds of around 4–14 cycles per byte in software on modern x86 processors, and reasonable hardware performance. It is not patented, and Bernstein has written several public domain implementations optimized for common architectures.</p>
</blockquote>

<p>While I see the later parts about not being patented and optimzed for many architectures is nice I don't get the first sentence of the Quote. What does it mean that one can efficiently seek to any position in the key stream in constant time?</p>

<lightning-network><cryptography><random>
What is so special about chacha20 stream cipher along with poly1305 for message authentication codes?
Rene Pickhardt
# What is so special about chacha20 stream cipher along with poly1305 for message authentication codes?

(Asked by: username_0 on 2019-02-27)

I am currently trying to dissect the low level cryptography protocols of the lightning network and I realize that in many places chacha20 is being used. I tried [reading about it in the Wikipedia Article](https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant) there it says:

> This gives Salsa20 and ChaCha the unusual advantage that the user can efficiently seek to any position in the key stream in constant time. Salsa20 offers speeds of around 4–14 cycles per byte in software on modern x86 processors, and reasonable hardware performance. It is not patented, and Bernstein has written several public domain implementations optimized for common architectures.

While I see the later parts about not being patented and optimzed for many architectures is nice I don't get the first sentence of the Quote. What does it mean that one can efficiently seek to any position in the key stream in constant time?

**Tags:** lightning-network, cryptography, random


---

## 1 answers

### Answer by username_1 on 2019-02-27. Score: 5 | Accepted answer

> What is so special about chacha20 stream cipher along with poly1305 for message authentication codes?

There is nothing special about the combination. It's just a combination of two constructions (ChaCha20 for the stream cipher, Poly1305 for MAC) that are designed with similar goals in mind:

* Easy to write a correct implementation in software
* Optimized for performance of software implementations running on general purpose hardware. This is in contrast to many cryptographic primitives which are optimized for hardware implementation, but are suboptimal in software. This is mainly due to the use of integer addition operations in ChaCha20.
* 128-bit security level.

Furthermore the key derivation is informally standardized, allowing using a single key for both encryption and authentication. Having real-world constructions (for example OpenSSH) use this constructions gives confidence about security.

> What does it mean that one can efficiently seek to any position in the key stream in constant time?

Assume you're given n GiB of incoming encrypted data, but for some reason you're only interested in the last 1 MiB. With some ciphers, you'd need to do O(n) work to "skip" the first n GiB. ChaCha20, like most stream ciphers, permits decrypting any one MiB with same amount of work regardless of its position - essentially deriving the cipher output for arbitrary positions (aligned to a 64 byte boundary at least) with as much work as decoding sequentially.

> **Comments:**
> **username_2**: "permits decrypting the last", perhaps worth mentioning that this is a generic property of stream ciphers-- also encoding and decoding in parallel and being able to decode data that has some lost chunks without totally desyncing.  
> **username_1**: @username_2 Good point, fixed.  
> **username_0**: What do you mean with encoding and decoding in parallel? Am I correct that being able to decode data that has lost chunks comes from the property that any data chunk can be decoded independent of the rest of the data stream?  

---

