Encrypting files with the Simon Cipher in CBC

Until last week, there was a single problem from the PWL generation side with simontool, and it is that it does not make assumptions of how the initial state of the keys is set. Well, now I can add how the XOR for CBC stream encryption is done.
If you want to use simontool to encrypt a file, you should first look at my post of encrypting files with the simon cipher because of the quirks with the keys. The default behavior is ECB, but the -m flag now allows CBC behavior. The CBC mode is included in the file header. An example of the encryption is:
Encrypt the file, testfile.txt:

simontool -e -m cbc -b 128 -k 128 -s 0f0e0d0c0b0a09080706050403020100 -i testfile.txt -o testfile.simon

Decrypt the file testfile.simon, use the expanded key:

simontool.elf -d -b 128 -k 128 -s 6413494fda72360d1cb8547cd58c4df9 -i testfile.simon -o testfile.txt

Encrypting files with simontool and the Simon Cipher

Outside of the authors of the simon cipher, I probably know more about the cipher than anyone else. I've written the tools for hardware implementation (one day, the IEEE will approve the paper). I've spent a lot of time encrypting multiple blocks and looking at the strobe outputs. The simontool program can encrypt a file as EBC. I do not support CBC yet because I cannot make assumptions about the hardware chaining.

Let's use simontool to encrypt a file with the simon cipher. It helps to start with the manual file, but here's the summary. I do not give you a way to generate a key from text at this point, so you will need a key. Let's assume SIMON128/128 and pick the test key from the 0f0e0d0c0b0a09080706050403020100. This key is the encryption key, so we first need to also generate a decryption key.

simontool -e -b 128 -k 128 -s 0f0e0d0c0b0a09080706050403020100 -t 0 -y

This will print out the complete key expansion, and the key we want is the "final key" entry. The -t flag is generally used to encrypt a single block and the -y flag dumps the key expansion to stdout.

key[65]: e4eaaf3ba3196adfd49c399343c9c09a 
key[66]: 29b0397872648490e4eaaf3ba3196adf 
key[67]: 1cb8547cd58c4df929b0397872648490 
final key: 6413494fda72360d1cb8547cd58c4df9 
data: 13914e4e9aec8f25bb849374e01139aa 

Encrypt the file, testfile.txt:

simontool -e -b 128 -k 128 -s 0f0e0d0c0b0a09080706050403020100 -i testfile.txt -o testfile.simon

Decrypt the file testfile.simon, use the expanded key:

simontool.elf -d -b 128 -k 128 -s 6413494fda72360d1cb8547cd58c4df9 -i testfile.simon -o testfile.txt

Now, what if you forget you key? I cannot help you, but if you forget the format, the header of the encrypted file has some information:

SIMON                 11 128 128

The format from the manual:

 header is 32-bytes in total:    
          8 for the word SIMON
          8 for nothing
          4 for nothing
          4 for offset padding (most likely a value < 8)
          4 for key size information 
          4 for block size information 

Numbers larger than 64-bits in BASH

Necessity is the mother of invention. When dealing with number theory, particularly cryptography, you have large numbers. I have many tools that I have written to support my semiconductor work, and many of these output "large numbers". BASH has limitations to numbers size. I have created a BASH library that allows me to do arbitrary bit-width operations on binary representations of strings.

The first thing that is required is my "bashbignumbers.sh" function library. You then can do simple arithmetic. In the following example, I create a 4096 bit number that is full of "0"s. I then increment the number, negate it, and convert it back into hex.

source "bashbignumbers.sh"
RESULT=$(bashUTILzerowidth 4096)
RESULT=$(bashINCbinstring $RESULT)
RESULT=$(bashNEGbinstring $RESULT)
RESULT=$(bashUTILbin2hex $RESULT)
echo "$RESULT"

The result is:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
And that is the 2's compliment representation of -1