The design of Chacha20

#1

Post by loup-vaillant » Tue, Jan 10, 2017, 12:46 PM UTC

Re: The design of Chacha20

#2

Post by vog » Tue, Jan 10, 2017, 1:35 PM UTC

The author seems to favor XChaCha20 over ChaCha20, even though XChaCha20 is not part of any formal standard or any widely know paper. [1] It would be interesting to know what DJB (the author of ChaCha20) thinks about XChaCha20 and related variants.

[1] http://crypto.stackexchange.com/a/34605

Re: The design of Chacha20

#3

Post by marcosdumay » Tue, Jan 10, 2017, 1:43 PM UTC

vog wrote: post #2

The author seems to favor XChaCha20 over ChaCha20, even though XChaCha20 is not part of any formal standard or any widely know paper. [1] It would be interesting to know what DJB (the author of ChaCha20) thinks about XChaCha20 and related variants. [1] http://crypto.stackexchange.com/a/34605

Well, NaCl (DJB's encryption library) uses XChaCha20, doesn't it?

Edit: Nope, it's XSalsa20.

Re: The design of Chacha20

#4

Post by panic » Tue, Jan 10, 2017, 1:50 PM UTC

marcosdumay wrote: post #3

vog wrote: post #2

The author seems to favor XChaCha20 over ChaCha20, even though XChaCha20 is not part of any formal standard or any widely know paper. [1] It would be interesting to know what DJB (the author of ChaCha20) thinks about XChaCha20 and related variants. [1] http://crypto.stackexchange.com/a/34605

Well, NaCl (DJB's encryption library) uses XChaCha20, doesn't it? Edit: Nope, it's XSalsa20.

NaCl provides Salsa20 and XSalsa20 (https://nacl.cr.yp.to/stream.html).

libsodium adds ChaCha20 (https://download.libsodium.org/doc/advanced/chacha20.html) but not XChaCha20.

Re: The design of Chacha20

#5

Post by riffraff » Tue, Jan 10, 2017, 1:53 PM UTC

> [re magic "expand 32-byte k" string] And it's readable ASCII text, so you can be pretty sure there's no back door in there.

I am not sure this matters?

I mean, facebook managed to get a reasonably nice .onion routing id (facebookcorewwwi.onion) by bruteforcing stuff right?

I can imagine bruteforcing the "backdoor key space" to find something that looks good, am I insane?

Re: The design of Chacha20

#6

Post by JoachimS » Tue, Jan 10, 2017, 1:58 PM UTC

marcosdumay wrote: post #3

vog wrote: post #2

The author seems to favor XChaCha20 over ChaCha20, even though XChaCha20 is not part of any formal standard or any widely know paper. [1] It would be interesting to know what DJB (the author of ChaCha20) thinks about XChaCha20 and related variants. [1] http://crypto.stackexchange.com/a/34605

Well, NaCl (DJB's encryption library) uses XChaCha20, doesn't it? Edit: Nope, it's XSalsa20.

NaCl supports several secret key encryption algorithms: http://nacl.cr.yp.to/stream.html

aes-128 in counter mode, Salsa20 with 8, 12 and 20 rounds and XSalsa with 20 rounds.

Som other implementations of NaCl/Sodium have restricted the different algs. TweekNaCl only supports XSalsa20 and Salsa20.

Re: The design of Chacha20

#7

Post by JoachimS » Tue, Jan 10, 2017, 1:59 PM UTC

Fwiw, here is a HW-implementation of ChaCha. It is very fast due to the big block and four parallel quarterrounds. https://github.com/secworks/chacha

Re: The design of Chacha20

#8

Post by vog » Tue, Jan 10, 2017, 2:05 PM UTC

How does ChaCha20 compare to the established AES standard? Is it stronger? weaker? faster? slower? easier to implement correctly? harder to implement correctly? better for some other reason? worse for some other reason?

Re: The design of Chacha20

#9

Post by cwmma » Tue, Jan 10, 2017, 2:15 PM UTC

riffraff wrote: post #5

> [re magic "expand 32-byte k" string] And it's readable ASCII text, so you can be pretty sure there's no back door in there. I am not sure this matters? I mean, facebook managed to get a reasonably nice .onion routing id (facebookcorewwwi.onion) by bruteforcing stuff right? I can imagine bruteforcing the "backdoor key space" to find something that looks good, am I insane?

If backdoored constants are easy enough to find that you are able to find them AND they are appropriate English phrases then the cipher itself is likely broken doubly so as the origional version of chacha had 2 key sizes 16-byte and 32-byte and each used the applicable constant, so in this case you would have had to have found 2 matching back doored constants.

That being said you aren't crazy this is what the nsa was accused of doing with elliptical curves though they had started with inexplicable random seeds.

Re: The design of Chacha20

#10

Post by vog » Tue, Jan 10, 2017, 2:16 PM UTC

riffraff wrote: post #5

> [re magic "expand 32-byte k" string] And it's readable ASCII text, so you can be pretty sure there's no back door in there. I am not sure this matters? I mean, facebook managed to get a reasonably nice .onion routing id (facebookcorewwwi.onion) by bruteforcing stuff right? I can imagine bruteforcing the "backdoor key space" to find something that looks good, am I insane?

I was wondering about this, too. To put even more paranoia at the table:

Readable ASCII means that every byte is in a certain range. For example, bit 7 is 0 for every byte. Maybe this allone enables a backdoor.

That is, the mere fact that this is readable ASCII could enable a backdoor. Who knows?