“Go” And Do Crypto

Google Tink now has Python and Golang support
Illustration by https://dribbble.com/clintkadera

“Go” And Do Crypto

Google Tink now has Python and Golang support

I like most programming languages, but Java is one that has passed me by. So I am so pleased to see that Google has released Tink in lots of different languages, and the Go version is one of the best to use (fast and robust) [here]:

On 19 March 2020, Google released Tink 1.3.0, and which included Golang, and, in the last few days, they have released Version 1.4.0 with the addition of Python. The library now supports Java and Android, C++, Obj-C, Go, and Python with JavaScript under development.

Introduction

It is over 40 years since the creation of the RSA method, and it has been a history of where cryptography methods have come and gone. New attack vectors have also surfaced, and where methods which looked invincible have crumbled. We now have a patch-work of cryptographic methods, and which often fail to properly secure data for confidentially, integrity and access rights.

And so we have DES, 3DES, RC4, RC4, RC5, MD5, SHA-1, SHA-2, SHA-3, RSA, … and so many others. Few software libraries have kept up with the development, and thus OpenSSL has been the de-facto place to look for the code which implements these methods. It is thus the place that developers have looked for methods which have been properly tested and known to work in a range of applications. But it’s creaking at the seams, and almost every month a new vulnerability is being found.

The Legacy of OpenSSL

OpenSSL is commonly used by Linux-based servers to implement the SSL/TLS connection, and bugs are common. It was started with Eric A Young and Tim Hudson, in Dec 1998, who created the first version of OpenSSL (SSLeay — SSL Eric AYoung), which then became Version 0.9.1. Eric finished his research and left to go off and do other things, and was involved with Cryptsoft (www.cryptsoft.com) before joining RSA Security, where he is currently a Distinguished Engineer. After Eric left, it was then left to Steve (from the US) and Stephen Henson (from the UK) to continue its development through the OpenSSL Software Foundation (OSF).

The code continued to grow with TLS support added to 1.0.1a on 14 March 2012. Unfortunately, a bug appeared on 1 Jan 2012 which implemented the Heartbeat protocol (RFC 6520), and which ended-up resulting in Heartbleed (Figure 1). The bug was actually introduced by the same person who wrote the RFC — Robin Seggleman, a German developer:

Figure 1: RFC 6520 led to Heartbleed

Every significant vulnerability gets a CVE number. Sometimes they are associated with a common name such as Heartbleed (CVE-2014–0160), BEAST (CVE-2011–3389), FREAK (CVE-2015–0204), and so on, but some, such as CVE-2016–2017, just doesn’t have a common name. This bug related to OpenSSL 1.0.1 and 1.0.2, and where an attacker could perform a MITM (Man-in-the-Middle) attack on AES encryption.

Anyone looking at the OpenSSL code will see that it has no real focus on creating a consistent approach to code integration, and needed a redesign, especially in a world which is focused on mobile devices. Google initially forked the OpenSSL code with BoringSSL, but have now formally released Google Tink.

Google Tink

Google released Tink Version 1.2.0 in August 2018, as a multi-language (Java, C++ and Objective C), cross-platform cryptographic library. Its main focus is to replace OpenSSL and where there are complex bindings and which were often focused on specific systems, such as for DLLs in Windows systems. While Google created Tink, it is open-source and has the aim to create simple APIs for cryptography functions and which should make the infrastructure more portable, secure and stable.

For Tink — based on BoringSSL and now at Version 1.2.0 — the adoption has been good and is already integrated into AdMob, Google Pay, Google Assistant, and Firebase. It also integrates AEAD (Authenticated Encryption with Associated Data) methods and which integrates encryption keys, a hash function, and a message authentication code (MAC). Google, too, has analysed many cryptography weaknesses and have created code which addresses many of these problems.

The minimal standards for AEAD include [RFC5116]:

  • The plaintext and associated data can have any length (from 0 to ²³² bytes).
  • Supports 80-bit authentication.
  • CCA2 security (adaptive chosen-ciphertext attack).

Google Tink: Symmetric key

A basic cryptography operation is to use symmetric key encryption, and where Bob and Alice use the same key to encrypt and also to decrypt. Either Bob creates the key, and then passes it securely to Alice, or they use a key exchange method to generate a shared key:

Tink aims to simplify encryption processing and use the best methods possible for encryption. In the following we encrypt a string (“This is a test”) and a password (“A bit of random”):

https://repl.it/@billbuchanan/goaesgcm

A sample run proves the process:

Message: This is a test
Associated data: A bit of random
Cipher text: 019322dabdc7bb460c7257820f953b1c8146bf56f2f38846ea3d1405dc6a3f56f8a0d25f0129c4a34cd12782accda5
Plain text: This is a test
Key: &{primary_key_id:2468534973 key:<key_data:<type_url:"type.googleapis.com/google.crypto.tink.AesGcmKey" value:"\032 \211\252J\2229\373\310\345\024\272\221K\272\257\351q2\265UXo\323M\201\210\320?\231\263\337\376\034" key_material_type:SYMMETRIC > status:ENABLED key_id:2468534973 output_prefix_type:TINK >  <nil>}

A demo of this is here:

https://asecuritysite.com/encryption/go_tink01

Google aims to focus the industry on strong encryption methods using AEAD and with integrated authentication: AES-GCM and AES-CTR-HMAC (Counter reset). The AeadKeyTemplates object has the following properties:

  • AES128_CTR_HMAC_SHA25. 16 byte AES key size. IV size: 16 bytes. HMAC key size: 32 bytes.HMAC tag size: 16 bytes. HMAC hash function: SHA256.
  • AES128_GCM Key size: 16 bytes.
  • AES256_CTR_HMAC_SHA25. AES key size: 32 bytes. AES IV size: 16 bytes. HMAC key size: 32 bytes. HMAC tag size: 32 bytes. HMAC hash function: SHA256.
  • AES256_GCM. Key size: 32 bytes.
  • CHACHA20_POLY1305. A stream cipher.
// Modes are: 128-bit and 256-bit AES CTR, 128-bit and 256-bit AES GCM, and ChaCha20/Poly1205
//  key,_ := keyset.NewHandle(aead.AES128CTRHMACSHA256KeyTemplate())
  key,_ := keyset.NewHandle(aead.AES128GCMKeyTemplate())
//  key,_ := keyset.NewHandle(aead.AES256CTRHMACSHA256KeyTemplate())
//  key,_ := keyset.NewHandle(aead.AES256GCMKeyTemplate())
//  key,_ := keyset.NewHandle(aead.ChaCha20Poly1305KeyTemplate())
//  key,_ := keyset.NewHandle(aead.XChaCha20Poly1305KeyTemplate())

Google Tink: Message Authentication Code

One of the standard methods that we use in cryptography is to sign a message. For this we generate a signing key, and which is kept secret for a range of messages. This could relate to a single conversation between Bob and Alice, or for long-term communications between them.

Either Bob or Alice (or both of them) create a shared private key, and then pass it securely. Only Bob and Alice will have this key, and Eve will not be able to discover it. Every time Bob sends a message to Alice he sends the message with a MAC (Message Authentication Code), and which is the message encrypted with the private key and then produced as a hash code (SHA-256). This method is known as HMAC (Hash-based Message Authentication Code). Alice takes the signing key and checks that she gets the same MAC. If she does, she has checked that it is still Bob who is signing the messages. If it doesn’t tie-up, she assumes that Eve is pretending to be Bob, and discards the message.

With the Message Authentication Code (MAC), we take a message and sign it with a secret key:

https://repl.it/@billbuchanan/gotink02

And a demo here:

https://asecuritysite.com/encryption/go_tink02

In this case Google Tink supports 128-bit, 256-bit and 512-bit HMAC SHA-256 signatures.

Google Tink: Public key signing

One of the standard methods that we use in cryptography is to sign a message with a private key, and to prove the signing with the public. Thus if Bob has a key pair, he uses his private key to sign the message, and then Alice will prove that it was Bob who signed it, using Bob’s public key. It will also prove that the message has not been changed by Eve.

We use this method is many applications. An example is in Bitcoin transfers and where Bob signs a transaction to pay Alice a given number of bitcoins. He signs this transaction with his private key (which is in his wallet), and then adds it, with his public key onto the blockchain. Anyone who wants to check the transfer will check the signature with Bob’s public key.

Now let’s look at how Google Tink generates digital signatures codes. The core method is to use ECDSA (Elliptic Curve Digital Signature Algorithm). For this we generate a new key pair. We can then use the private key of the key pair to sign a message with the sign() method:

https://repl.it/@billbuchanan/gotink03

and here is a demo:

https://asecuritysite.com/encryption/go_tink03

Ed25519 is named the EdDSA (Edwares Digital Signing Algorithm) signature scheme and uses Curve 25519:

https://repl.it/@billbuchanan/tink04

and here is a demo:

https://asecuritysite.com/encryption/go_tink04

Hybrid encryption (ECIES — Elliptic Curve Integrated Encryption Scheme)

With hybrid encryption we use the power of public key and symmetric key. It works by Alice sending her public key to Bob, and where Bob creates a random value (r) and then a public key (R=rG). This is then used to create a symmetric key, and which Alice is able to regenerate with Bob’s public key:

We thus use AES for the encryption. Here it is:

https://repl.it/@billbuchanan/tink05

and here is a demo:

https://asecuritysite.com/encryption/go_tink05

Conclusions

No excuses now for not doing crypto, it is there with Google Tink in Golang and Python.