Go and ChaCha

The demo of the code we will show is here.

So what encryption method is your browser using just now? AES? Well, there’s a good chance that it is ChaCha, and it is kinda taking over as a preferred method for symmetric key encryption within TLS connections. Why? Well, it’s much faster than AES. It is also well suited to IoT devices. And, well … it isn’t AES!

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, proposed 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.

Method

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):

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, but let’s “Go” and use Golang for the implementation. The following provides the code here:

package main
import (
"fmt"
"golang.org/x/crypto/chacha20poly1305"
    "crypto/sha256"
    "os"
)
func main() {
    pass:="Hello"
    msg:="Pass"
    argCount := len(os.Args[1:])
        if (argCount>0) {msg= string(os.Args[1])}
        if (argCount>1) {pass= string(os.Args[2])}
    key := sha256.Sum256([]byte(pass))
    aead, _ := chacha20poly1305.NewX(key[:])
    if (pass=="") {
        a:=make([]byte, 32)
        copy(key[:32],a[:32])
        aead, _ = chacha20poly1305.NewX(a)
    } 
    if (msg=="") {
        a:=make([]byte, 32)
        msg=string(a)
        
    } 
   nonce := make([]byte, chacha20poly1305.NonceSizeX)
   ciphertext := aead.Seal(nil, nonce, []byte(msg), nil)
   plaintext, _ := aead.Open(nil, nonce, ciphertext, nil)
    fmt.Printf("Message:\t%s\n", msg)
    fmt.Printf("Passphrase:\t%s\n", pass)
    fmt.Printf("\nKey:\t%x\n", key)
    fmt.Printf("Nonce:\t%x\n", nonce)
    fmt.Printf("\nCipher stream:\t%x\n", ciphertext)
        fmt.Printf("Plain text:\t%s\n", plaintext)
}

A sample run is here:

Message:    Testing 123
Passphrase: Bill
Key:    e51783b4d7688ffba51a35d8c9f04041606c0d6fb00bb306fba0f2dcb7e1f890
Nonce:  000000000000000000000000000000000000000000000000
Cipher stream:  ae3bea89fa24d4969e31d04457d1c13f7a033266d3a2d453bbd4ad
Plain text: Testing 123

If we use a key of “000…00” and a message of zero bytes, we can see the test key stream of zeros:

Message:    
Passphrase: 
Key:    0000000000000000000000000000000000000000000000000000000000000000
Nonce:  000000000000000000000000000000000000000000000000
Cipher stream:  789e9689e5208d7fd9e1f3c5b5341f48ef18a13e418998addadd97a3693a987f943da98353b75592311f4e23c0710078
Plain text:
```## 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. Don’t be fooled by those companies who tell you … “HTTPs is only used on our site when we pass sensitive information”. HTTPs does a whole lot more than just encrypt the data, it also verifies the site.

* Test under Chrome for certificate validity.

*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.