Live data from Hacker News

The design of Chacha20

loup-vaillant.fr

41–50 of 76 posts

Re: The design of Chacha20

#41
post #8

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?

AES is hard to implement on a general purpose computer in a way that is both fast and doesn't leak through cache timing attacks. The safe way to use AES is by using a hardware implementation, like modern x86 and some ARM CPUs. The best software implementations use bitslicing and SSE, but are still slow. The best I saw is an Emilia Kasper and Peter Schwabe paper[1] from 2009 on bitsliced AES-GCM has 21.99 cycles/byte…

Basic Chacha C implementations do not get auto-vectorized down to ultra-efficient code. The most efficient implementations are intrinsic/assembler that process 4 (SSE2/AVX/NEON) or 8 (AVX2) Chacha20 blocks at once. This is due to layout of variables and operations being designed for efficient SIMD use and the blocks being independent of each other. (Shay's Chacha20 implementation is also not the fastest!)

Re: The design of Chacha20

#42
post #22

This is solid but might miss the forest for the trees. If you want to understand Chacha/Salsa, the best way to start is that it's an ARX-based hash function , keyed , running in counter mode . ARX stands for addition, rotation, and XOR, which are the three operations ARX designs are composed of. Addition is nonlinear in the context of ARX, which eliminates the need for S-boxes (or complex alternatives to S-boxes) and…

> A good place to start understanding why you want rotation and nonlinearity is the Wikipedia page for SP Networks: I guess the real story requires knowing a little bit about linear and differential cryptanalysis, which are conceptually quite simple in their genesis, from a mathematical perspective. XOR and n-bit addition are both forms of addition over different finite fields, GF(2) and GF(2^n). Multiplication in GF…

Such a great comment! Thanks!

Re: The design of Chacha20

#43
If you are looking for a professional Hacker that specialized in school grade change… contact me ASAP, I do several School grades hack everyday. My jobs are secured and without trace. I have worked for students in Asia, America, Europe,Africa and Australia.

I ALSO do Facebook Hacking, Whatsapp Hacking, Instagram, Mobile Hacking, Increase credit score, removal of name from criminal record, removal of links from website. Recover Your email passwords, Hack into Bank/Company web site, etc

Re: The design of Chacha20

#44

Earlier quoted context omitted.

Under the hood ChaCha is a 128 bit -> 512 bit hash function with a 128 bit key, running in CTR mode to get a stream cipher. It is most assuredly NOT a block cipher under the hood.

Err, the key can be 256-bits. This is the preferred key size these days.

Oops, that should indeed be 256 bits (8 * 32 = 256). The rest of the comment stands though.

Re: The design of Chacha20

#45
post #15

Earlier quoted context omitted.

AES is a block cipher, Salsa/ChaCha are streams. This makes them very useful for, say, file encryption with random access.

Chacha20 can do random access. See the end of my article, when I talk about counter mode. To get the part of the stream you want, you just generate the block you need (they're all the same, only the counter changes), then encrypt it. No need to generate all previous blocks. Indeed, one reason for using AES in counter mode is this random access, which among other things enables parallel encryption. The same strategy w…

I'm probably stating the obvious here, but whatever your strategy for decrypting is you still must verify the ciphertext integrity, which unfortunately for you is calculated on the whole ciphertext. You may win some time by not reading the stuff before the block you're interested, but you will have to read the whole stuff anyway if you want to be safe.

I'm no expert of course so I don't even know if there's an AEAD that can bring you integrity on parts of the input; at least I know that minilock (https://github.com/kaepora/miniLock/blob/master/README.md#-m...) builds some kind of counter mode where each chunk is properly encrypted and has everything needed to check its integrity.

Re: The design of Chacha20

#46
post #45

Earlier quoted context omitted.

Chacha20 can do random access. See the end of my article, when I talk about counter mode. To get the part of the stream you want, you just generate the block you need (they're all the same, only the counter changes), then encrypt it. No need to generate all previous blocks. Indeed, one reason for using AES in counter mode is this random access, which among other things enables parallel encryption. The same strategy w…

I'm probably stating the obvious here, but whatever your strategy for decrypting is you still must verify the ciphertext integrity, which unfortunately for you is calculated on the whole ciphertext. You may win some time by not reading the stuff before the block you're interested, but you will have to read the whole stuff anyway if you want to be safe. I'm no expert of course so I don't even know if there's an AEAD t…

The most widespread way of using Salsa/ChaCha is in the "Chapoly" construction, which combines ChaCha20 with DJB's Poly1305 polynomial MAC; this is an authenticated construction. Pretty much every mainstream application of Salsa20 is in fact a Salsa/Poly1305 construction.

You can also just combine Salsa and HMAC.

It's true that you need to authenticate your data, but this is true for any cipher that you use.

It's a bad idea to implement your own cipher code, no matter what you're doing. If you're looking to include Salsa/ChaCha in an application, use Nacl, which refuses to give you unauthenticated ciphertext.

Re: The design of Chacha20

#47
post #42

Earlier quoted context omitted.

> A good place to start understanding why you want rotation and nonlinearity is the Wikipedia page for SP Networks: I guess the real story requires knowing a little bit about linear and differential cryptanalysis, which are conceptually quite simple in their genesis, from a mathematical perspective. XOR and n-bit addition are both forms of addition over different finite fields, GF(2) and GF(2^n). Multiplication in GF…

Such a great comment! Thanks!

Hopefully someone finds it helpful!

I should also note that the picture I painted is most applicable to block ciphers, but it does apply mutatis mutandis to hash functions and pseudo-random generators.

With hashing, you have an inherent loss of information and hence the linear functions in question are non-invertible. Linear hash functions can be expressed as a factorization into two parts, an invertible function followed by a projection onto the first n bits (for a hash function producing n bits of output). With hash functions you're typically trying to find collisions or first and second preimages. Both of these are simple for linear functions. Let me just paint the picture for collisions. If f is linear then its kernel ker(f) = {x | f(x) = 0} can be efficiently calculated by Gaussian elimination. Then you can crank out collisions like no-one's business: if k is in ker(f) then f(x + k) = f(x) + f(k) = f(x). In practice, you're not going to find perfectly linear hash functions in the wild, but if you can detect an approximate linearity on some subspace, you can calculate the kernel of the linear approximation and use that to generate perturbations (the k from earlier) for a randomized collision search with a much higher likelihood of success per perturbation than random chance.

For pseudo-random generators, you're usually trying to solve for the PRG's internal state from a sequence of outputs. The generator function for a PRG takes its current internal state and produces the new internal state and an output. Incidentally, this is a nice completion of the triangle of cryptographic primitives. With block ciphers, you had invertible (injective and surjective) functions. With hash functions, you had non-injective functions (fewer output bits than input bits). With pseudo-random generators, you now have non-surjective functions (more output bits than input bits). While we cannot see the private state output from the generator, we do have multiple examples of the public output. So if (x_n, s_n) = g(s_(n-1)) is the generator equation, then in an ideal case we have the sequence of equations (x_1, s_1) = g(s_0), (x_2, s_2) = g(s_1), ..., (x_n, s_n) = g(s_(n-1)), where x_1, ..., x_n are known to us. If we assume g is a linear function that is known to us as well (no security through obscurity), then this is just a system of linear equations. For a generator with a maximal period, if we have as many bits of output as there are bits of internal state, we may solve uniquely for the initial state s_0, and from there we can calculate s_1, s_2, etc, by just replaying g starting with s_0. As in our previous examples, things in the wild aren't perfectly linear, but it's enough for PRGs to be approximately linear to leak bits of internal state, though we usually need far more example bits of output than there are bits of internal state to make a dent.

Re: The design of Chacha20

#48
post #22

This is solid but might miss the forest for the trees. If you want to understand Chacha/Salsa, the best way to start is that it's an ARX-based hash function , keyed , running in counter mode . ARX stands for addition, rotation, and XOR, which are the three operations ARX designs are composed of. Addition is nonlinear in the context of ARX, which eliminates the need for S-boxes (or complex alternatives to S-boxes) and…

> A good place to start understanding why you want rotation and nonlinearity is the Wikipedia page for SP Networks: I guess the real story requires knowing a little bit about linear and differential cryptanalysis, which are conceptually quite simple in their genesis, from a mathematical perspective. XOR and n-bit addition are both forms of addition over different finite fields, GF(2) and GF(2^n). Multiplication in GF…

Are there any concrete, simple examples showing linear and differential cryptanalysis (simple, breakable cipher + example cracking program)? As much as I've studied the theory and perused the design decisions of modern ciphers to avoid such attacks, I've never taken the time to sit down and actually crack a simple cipher using them. Would be neat to do so.

Re: The design of Chacha20

#49
post #38

If you enjoyed the style of this article, I would also recommend you have a look at the brilliant explanation of Earley parsing by the same author: http://loup-vaillant.fr/tutorials/earley-parsing/

There have also been some good AES vs ChaCha performance tests: 1) Speedify's AES vs ChaCha in VPN: http://speedify.com/blog/a-new-kind-of-vpn/ 2) Cloudflare's AES vs ChaCha in browser: https://blog.cloudflare.com/do-the-chacha-better-mobile-perf...

Re: The design of Chacha20

#50
post #22

This is solid but might miss the forest for the trees. If you want to understand Chacha/Salsa, the best way to start is that it's an ARX-based hash function , keyed , running in counter mode . ARX stands for addition, rotation, and XOR, which are the three operations ARX designs are composed of. Addition is nonlinear in the context of ARX, which eliminates the need for S-boxes (or complex alternatives to S-boxes) and…

If you're interested in some reading about ARX systems, a good paper is Rotational Cryptanalysis of ARX[1]. It's quite readable. If you follow the citations of that paper [2], you can find some interesting stuff.

[1] https://www.iacr.org/archive/fse2010/61470339/61470339.pdf

[2] https://scholar.google.com/scholar?um=1&ie=UTF-8&lr&cites=38...

Post reply on HN