51–60 of 76 posts
a += b; d ^= a; d I'm curious: could a C compiler look at the quarter-round function above and determine that a+b (or the other terms) might overflow a 32-bit integer, and thus invoke undefined behaviour to eliminate the loop entirely?
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…
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.
The starter exercise labeled 6.2 is a good way to get your feet wet with the ideas I described. 12-round DES without any S-boxes consists of P-boxes (permutations) and XORs, which are both linear over GF(2) vector spaces, so it's a linear block cipher and hence trivially breakable with any linear algebra package. RC5 without rotations is not exactly linear over either GF(2^n) or GF(2) since it mixes XORs and (mod 2^n) additions, but the combination is only very weakly nonlinear (there's not enough avalanching from the carries to entangle entries that are far apart), and therefore a good demonstration of why you need rotations in ARX to introduce rapid long-range bit entanglement. And in case it wasn't already obvious, the exercise about RC5 with rotations by a round number will show you why the rotation amount in ARX should be relatively prime to the bit width. Otherwise you end up with disconnected rotation orbits where the round function only mixes within a given orbit. In the extreme case where the rotation amount is half the bit width, each orbit contains at most two elements, so it's hardly any better than no rotation at all.
I bet there are also modern textbooks in cryptanalysis with exercises and a more hand-holding approach. Maybe any cryptographers reading this could recommend something.
a += b; d ^= a; d I'm curious: could a C compiler look at the quarter-round function above and determine that a+b (or the other terms) might overflow a 32-bit integer, and thus invoke undefined behaviour to eliminate the loop entirely?
block'[ 0]: "expa" block'[ 8]: kcolb[12]
block'[ 1]: "nd 3" block'[ 9]: kcolb[13]
block'[ 2]: "2-by" block'[10]: kcolb[14]
block'[ 3]: "te k" block'[11]: kcolb[15]
block'[ 4]: kcolb[0] block'[12]: nonce[4] the nonce and counter state words seem to be swapped in the 3rd figure of the "A much bigger nonce: XChacha20" section: block'[ 0]: "expa" block'[ 8]: kcolb[12] block'[ 1]: "nd 3" block'[ 9]: kcolb[13] block'[ 2]: "2-by" block'[10]: kcolb[14] block'[ 3]: "te k" block'[11]: kcolb[15] block'[ 4]: kcolb[0] block'[12]: nonce[4]
Earlier quoted context omitted.
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.
That's coming soon: https://github.com/jedisct1/libsodium/blob/master/src/libsod...
why can't we get our shit together...
Earlier quoted context omitted.
Chacha/Salsa is: * Intrinsically simpler than AES * Easier to implement * As an ARX design, doesn't need S-boxes, and so doesn't leave a cache footprint * Has free key setup AES is: * A global standard * Available in hardware on most platforms (extremely important) * A conventional block cipher for which a bunch of modes (in particular: wide-block and AEAD) are already defined But unlike Salsa, AES: * Has relatively…
> * A global standard ChaCha is standard enough to make it into TLS and IPSec
So now there's three variants of ChaCha20
* ChaCha20 (256-bit key, 64-bit nonce, 64-bit counter)
* IETF ChaCha20 (256-bit key, 96-bit nonce, 32-bit counter)
* XChaCha20 (256-bit key, 192-bit nonce, 64-bit counter)the nonce and counter state words seem to be swapped in the 3rd figure of the "A much bigger nonce: XChacha20" section: block'[ 0]: "expa" block'[ 8]: kcolb[12] block'[ 1]: "nd 3" block'[ 9]: kcolb[13] block'[ 2]: "2-by" block'[10]: kcolb[14] block'[ 3]: "te k" block'[11]: kcolb[15] block'[ 4]: kcolb[0] block'[12]: nonce[4]
Corrected, thanks.
a += b; d ^= a; d I'm curious: could a C compiler look at the quarter-round function above and determine that a+b (or the other terms) might overflow a 32-bit integer, and thus invoke undefined behaviour to eliminate the loop entirely?
In C, unsigned overflow is defined as wrapping, and all these numbers are unsigned. It's signed overflow that's undefined in C.
Notable I think the NaCl crypto library implements a compare as follows
uint32_t diff_bits = 0;
diff_bits |= x[0] ^ y[0];
...
diff_bits |= x[31] ^ y[31];
return (1 & ((diff_bits - 1) >> 8)) - 1;
Longer term worry is the optimizer will figure the above out as well.
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?
Chacha/Salsa is: * Intrinsically simpler than AES * Easier to implement * As an ARX design, doesn't need S-boxes, and so doesn't leave a cache footprint * Has free key setup AES is: * A global standard * Available in hardware on most platforms (extremely important) * A conventional block cipher for which a bunch of modes (in particular: wide-block and AEAD) are already defined But unlike Salsa, AES: * Has relatively…
Without hardware support timing attack resistant AES is not so fast.
(and then there is the adventure of many motherboards shipping with hardware AES disabled in the bios...)