AES Is Great … But We Need A Fall-back: Meet ChaCha and Poly1305

I have created a demonstrator here for ChaCha20 and Poly1305.

AES Is Great … But We Need A Fall-back: Meet ChaCha and Poly1305

I have created a demonstrator here for ChaCha20 and Poly1305.

Which encryption method just needs an EX-OR to encrypt? Well, that will be a stream encryption method, and where to EX-OR each bit of our plain text stream with our cipher key stream.

AES has become the gold standard for encryption, and will hopefully remain robust in a world of quantum computers. But what if someone finds a vulnerability in it? And surely it is rather complex for simple IoT devices to implement?

Well, for TLS 1.3, Google has been searching for a replacement for RC4 — and which has been shown to have flaws — and have settled on ChaCha20 for symmetric key encryption and Poly1305 for a message authentication code (MAC). Both were originally created by Daniel J. Bernstein, and focus on not relying on AES as a core method:

Google has been pushing for improved cryptography methods, and can move the market because of its predominance with Chrome.

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.

I have created a demonstrator here for ChaCha20 and Poly1305.

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. Cloudflare, too, have been pushing for better standards, and have also supported ChaCha20 and Poly1305. With companies pushing for improved standards for citizen privacy, you feel a whole lot more secure.