DAEAD: Deterministic Authenticated Encryption with Associated Data

DAEAD: Deterministic Authenticated Encryption with Associated Data

Overcoming Nonce Reuse/Misuse: SIV Mode

There is a core principle in cryptography, and where an output can either be deterministic or non-deterministic. With a deterministic output, we always get the same output for the same inputs. For example, we can create a cipher from plaintext, and where the output will always be the same ciphertext. With non-deterministic, we cannot predict what the output will be used, as some form of randomisation has been used in the process. With signatures, ECDSA is non-deterministic, and EdDSA is deterministic.

When it comes to symmetric key methods, the deterministic nature can be useful in searching for data, but it will be weaker from a security point of view, as an adversary can map the inputs to the output. In this case, we will combine the deterministic nature with Authenticated Encryption with Associated Data (Deterministic AEAD), and use the AES-SIV mode.

SIV — Synthetic Initialization Vector

We give away a little too much of our secrets, and often fail to protect one of our most important secret … our encryption keys. To overcome this, we can use a method called key wrapping, and which protects the key. This is especially important where we transmit the key over untrusted channels or store it in places without strong access control. For a key wrapping, Rogaway et al proposed the SIV (Synthetic Initialisation Vector) method [here] and which authenticates and encrypts, along with authenticating any additional data related to the key:

The method is now standardised with RFC 5297 [here]. With enhanced encryption methods, we can both authenticate the cipher and prove its integrity. This is known as Authenticated Encryption with Associated Data (AEAD). For this, we provide additional data to authenticate the encryption process, and we can identify where the ciphertext has been modified, so that it cannot be decrypted. With most conventional AEAD methods, we create a nonce value and add additional data (AD) that is authenticated but not encrypted. With a nonce-less approach, we can use a key wrapping method, and which has often been used to protect encryption keys. The additional data can include [here]:

addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext or ciphertext should be handled, forwarded, or processed

In this way, we can bind network packets to the encrypted data and provide integrity so that an intruder cannot copy and paste valid ciphertext from other transmissions. For example, if we bind to a packet sequence number and the port, the authentication would fail for another sequence number or another port.

In the following code, we will use the additional information of ”101112131415161718191a1b1c1d1e1f2021222324252627", but in practice, this can be of any length. Within SIV, too, we can have multiple sources of this additional data (known as a vector of strings). This information could be spread across multiple sources and is likely to be difficult for an intruder to capture and replicate. This is one of the special features of SIV and allows multiple strings to be used for the authentication, rather than having to merge these into a single string for additional information:

byte[] plaintext = pl.getBytes();
	      
String additional="101112131415161718191a1b1c1d1e1f2021222324252627";
byte[] ciphertext = daead.encryptDeterministically(plaintext, Hex.decode(additional));

Traditional AEAD methods can be weak in terms of nonce reuse and also nonce misuse. In many systems, we use a non-deterministic method of generating a nonce, so there is no way of knowing if previously generated values have not been used before. Another weakness is where a nonce can be “played back” by rolling back a virtual machine and discovering the nonce value used. Thus, most AEAD methods are secure with a unique nonce, but where there is no guarantee of security if the nonce is not unique. As the nonce value is limited in size, there will always be a chance to reuse it with the same key, and thus, we might have to change our keys on a regular basis. SIV provides more protection for nonce reuse/misuse, and where an attacker can only determine that a given plaintext value and a given set of associated data was protected using the defined key and nonce value.

Coding

In the following code, we create an SIV key, and then create ciphertext values, and which should both be the same [here]:

package main

import (
       "fmt"
 "os"

 "github.com/tink-crypto/tink-go/v2/daead"
 "github.com/tink-crypto/tink-go/v2/keyset"


)

func main() {

 msg:="Hello"
 associated:="Hello"

 argCount := len(os.Args[1:])
 if (argCount>0) {msg = os.Args[1]}
 if (argCount>1) {associated =os.Args[2]}

 handle, _ := keyset.NewHandle(daead.AESSIVKeyTemplate())

 primitive, _ := daead.New(handle)

 plaintext := []byte(msg)
 associatedData := []byte(associated)


 ciphertext1, _:= primitive.EncryptDeterministically(plaintext, associatedData)
 ciphertext2, _:= primitive.EncryptDeterministically(plaintext, associatedData)

 res, _ := primitive.DecryptDeterministically(ciphertext1, associatedData)

 fmt.Printf("Plaintext is %s\n",msg)
 fmt.Printf("Associated data is %s\n\n",associated)

 fmt.Printf("Key is %s\n\n",handle)

 fmt.Printf("Cipher1 is %x\n\n",ciphertext1)
 fmt.Printf("Cipher2 is %x\n\n",ciphertext2)
 fmt.Printf("Decrypted is %s",res)


}

A sample run shows that we have the same cipher when we encrypt deterministically [here]:

Plaintext is Testing 123
Associated data is qwerty123

Key is primary_key_id:1537855825 key_info:{type_url:"type.googleapis.com/google.crypto.tink.AesSivKey" status:ENABLED key_id:1537855825 output_prefix_type:TINK}

Cipher1 is 015ba9d1518f3a5d213ce9630294f87af76ce86011c8631842aa96571d0dee03

Cipher2 is 015ba9d1518f3a5d213ce9630294f87af76ce86011c8631842aa96571d0dee03

Decrypted is Testing 123