Time for a Cha-cha or a Salsa?

Time for a Cha-cha or a Salsa?

WEP (as used in wi-fi) gave stream ciphers a bad name, where it broke virtually every rule in the crypto book, and could be cracked, for the whole network, within just a few hours. But stream ciphers work just as well a block ones and are often much faster. Let’s do some Cha-Cha!

AES … great … but … not perfect!

AES has been shown to be relatively free from any vulnerabilities in its operation, but it does suffer from timing attacks. By listening to the power supply (and using the Keysight capture device), we have shown here that we can crack AES in less than 30 minutes [paper]:

This is because AES has a tell-tail signature in its operation.

Along with this, Google worry that AES has a virtual monopoly on secret key encryption, so what would happen it is was cracked? They thus, in an RFC, propose the usage of a stream cipher known as ChaCha20:

ChaCha20 takes a 256-bit key and a 32-bit nonce and then creates a key stream, which is then XORed with the plaintext stream. In software, it is three times faster than AES, and is well suited to lower-powered devices and in real time communications. Here is my testing page for ChaCha:

and where the define the following cipher suites:

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256   = {0xCC, 0xA8}
   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA9}
   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAA}

   TLS_PSK_WITH_CHACHA20_POLY1305_SHA256         = {0xCC, 0xAB}
   TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256   = {0xCC, 0xAC}
   TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAD}
   TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAE}

Implementation

ChaCha20 and Salsa take a 256-bit key (or a 128-bit version) and a 32-bit nonce This creates a key stream, which is then XORed with the plaintext stream. In software, it is more than three times faster than AES, and is well suited to lower-powered devices and in real-time communications.

ChaCha operates on 32-bit bits with a key of 256 bits (K=(k0, k1, k2, k3, k4, k5, k6, k7). This output blocks of 512-bits for the key stream (Z), and which is EX-ORed with the plaintext stream.

The state of the encryption is stored with 16 32-bit word values within a 4x4 matrix:

The initial state contains 16 32-bit values with constant values (0x61707865, 0x3320646e, 0x79622d32, 0x6b206574) the key (k0, k1, k2, k3, k4, k5, k6, k7), the counter (c0c0) and the nonce (n0,n1,n2,n3):

The counter thus has 32-bits (1 ⅹ 32 bits), and the nonce has 96-bits (3 x 32 bits). ChaCha then defines a quarter round as:

QR(a,b,c,d)

and where this is defined as:

a = a + b
d = d ⊕ a
d = (d)<<16
c = c + d
b = b ⊕ c
b = (b)<<12
a = a + b
d = d ⊕ a
d = (d)<<8
c = c + d
b = b ⊕ c
b = (b)<<7

There are then 20 rounds (10 for column rounds and 10 for diagonal rounds):

X is created with K, c and n
y ← X
for i ← 0 to 9 do
/* Column Round */
 (x0, x4, x8, x12) ← QR(x0, x4, x8, x12)
 (x5, x9, x13, x1) ← QR(x5, x9, x13, x1)
 (x10, x14, x2, x6) ← QR(x10, x14, x2, x6)
 (x15, x3, x7, x11) ← QR(x15, x3, x7, x11)
 /* Diagonal Round */
 (x0, x5, x10, x15) ← QR(x0, x5, x10, x15)
 (x1, x6, x11, x12) ← QR(x1, x6, x11, x12)
 (x2, x7, x8, x13) ← QR(x2, x7, x8, x13)
 (x3, x4, x9, x14) ← QR(x3, x4, x9, x14)
end for
Z ← X + y

Z is the resultant key stream.

Here is my ChaCha20 tester [here] and here is Salsa20 [here].

Conclusions

As far as Google is concerned, AES isn’t the only show in town. A large scale vulnerability on AES would cause much of the secure Internet to be exposed, so Google wants a fall-back, and they now use it on live systems.

Remember … here’s the best practice for your Web site:

• Redirect from HTTP to HTTPs. We need to phase out HTTP, as it is insecure, and has nothing in the way of identity checking for the remote site.
• Test under Chrome for certificate validity. Many of the sites I’ve tested over the past few days will not load on my iPad, Mac book, or Windows machine for a wide range of browsers.
• Support for TLS 1.2 (and in the future TLS 1.3).
• Do NOT support any version of SSL or TLS 1.0. If you see SSL v2 or SSL v3, disable them immediately, as they will expose a range of vulnerabilities including Freak and Poodle.
• Do NOT support MD5, RC4, and DES in cipher suites. MD5 cannot be trusted as it hash signatures can cause collisions. RC4 has cipher weaknesses, and DES only has 56-bit keys, and which can be easily brute forced.
• Do NOT support 1,024-bit (or less) RSA keys.
• Do NOT support the export of 512-bit export suites, as 512-bit Diffie-Hellman keys have been long cracked.
• Only support AEAD ciphers.