A Humble Cipher Helped To Stop Prying Eyes on Email: Meet CAST5

We need to understand where we have been in order to clearly see where we are going

A Humble Cipher Helped To Stop Prying Eyes on Email: Meet CAST5

We need to understand where we have been in order to clearly see where we are going

There’s something about old ciphers that I love. So, while most security professionals avoid them, and where they are marked as being deprecated or unsafe, I love to dive into them and understand their mechanics. I suppose it is a bit like a car mechanic who works on the latest BMWs and Audis, working on an old Ford Cortina’s in their spare time — and where there’s nothing fundamentally wrong with the old cars, it is just that we have modernized them.

Overall, these “old” ciphers exist for a reason, and at one time, they had a core purpose, and where someone lovingly crafted and coded them — not for any financial reward, but for the sheer love of coding and to make the world a safer place. But, if we do one thing, it is that we document them as part of our shared history, and why they existed, and why they are possibly insecure in our modern world. And, so, just because Betamax was beaten by VHS, doesn’t mean that Betamax was an inferior product.

In fact, while many of the old ciphers, such as DES, are not used any more, their core methodology is still unbroken — it is only that a weak encryption key size and the block size that has caused problems. So, if you don’t trust our existing standard encryption methods and libraries, there’s nothing to say to stop you from using any other cipher for your symmetric key encryption — as long as Bob and Alice know the method that is being used (and that you can find a package which supports them):

And, so, while AES and ChaCha20 are the only show in town at the current time for symmetric key encryption, there’s no need to dismiss any cipher from the past — as they can still be relevant. And, so, meet CAST5, and which is still supported by the main cryptography library and which played a key role in the creation of PGP.

And, finally, like those in science and mathematics would look back at the work of Newton, Gauss and Galilou, in cybersecurity, we should look back to our history. I appreciate that it is only a few decades old as a discipline, but we need to understand where we have been in order to clearly see where we are going. Many old ciphers give us pointers to the types of vulnerabilities we need to guard against in the future.

Introduction

CAST5 (or CAST-128) was created by Carlisle Adams and Stafford Tavares in 1996. It defines a symmetric key method that has a 64-bit block size, and key sizes from 40 bits up to 128 bits (in jumps of 8 bits). Typically any key less than 80 bits would be seen as being insecure. It uses a 12- or 16-round Feistel cipher. The 16-round version is used for keys for 80 bits and above. It has been standardized in RFC2612 [here]:

PGP

Phil Zimmerman could not believe there was no real security or trust built into email. So, in 1991, he created PGP (Pretty Good Privacy). With this, Bob creates a random symmetric key, which is used to encrypt a message. Bob then encrypts this symmetric key with Alice’s public key. When she receives the email, she discovers the symmetric key with her private key and then decrypts the message:

But, Phil’s code then appeared outside the US, and in 1993 he was involved in a criminal investigation “munitions export without a license. While this was underway, his team released PGP 3, which improved the overall security of the software. With this, the team avoided RSA for the public key method, as it was protected under patent or royalty-free. For signatures, they went for DSA and ElGamal, and for the symmetric key method, they chose CAST5 (which is royalty-free). A 256-bit version is also available as CAST-256.

PGP has advanced to the GNU Privacy Guard (GPG) and is based on OpenPGP. It ow supports the public key methods of RSA, ELG, DSA, ECDH, ECDSA, and EDDSA. Also symmetric key ciphers of IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, and CAMELLIA256, along with SHA1, RIPEMD160, SHA256, SHA384, SHA512, and SHA224. The compression methods supported are ZIP, ZLIB, and BZIP2:

https://asecuritysite.com/pgp/pypgp

The code is [here]:

import os
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import padding
import sys
message="Hello"
associated_data=b"Hello"
tag=b"0123456789ABCDEF"
keysize=5
iv = os.urandom(8)
mode=0
if (len(sys.argv)>1):
message=str(sys.argv[1])
if (len(sys.argv)>2):
mode=int(sys.argv[2])
if (len(sys.argv)>3):
keysize=int(sys.argv[3])
key = os.urandom(keysize)
padder = padding.PKCS7(64).padder()
unpadder = padding.PKCS7(64).unpadder()
cipher=None

if (mode==0):
cipher = Cipher(algorithms.CAST5(key), modes.CBC(iv))
if (mode==1):
cipher = Cipher(algorithms.CAST5(key), modes.OFB(iv))
if (mode==2):
cipher = Cipher(algorithms.CAST5(key), modes.CFB(iv))
if (mode==3):
cipher = Cipher(algorithms.CAST5(key), modes.ECB())

encryptor = cipher.encryptor()
str=padder.update(message.encode())+padder.finalize()

ciphertext = encryptor.update(str ) + encryptor.finalize()
# Now decrypt
decryptor = cipher.decryptor()

rtn=unpadder.update(decryptor.update(ciphertext) + decryptor.finalize())+unpadder.finalize()
print("Type:\t\t\t",cipher.algorithm.name)
print("Mode:\t\t\t",cipher.mode.name)
print("Message:\t\t",message)
print("Message with padding:\t",str)
print("\nKey:\t\t\t",key.hex())
if (mode!=3): print("IV:\t\t\t",iv.hex())
print("\nCipher:\t\t\t",ciphertext.hex())
print("Decrypt:\t\t",rtn.decode())

and a sample run [here]:

Type:    CAST5
Mode: CBC
Message: Hello
Message with padding: b'Hello\x03\x03\x03'
Key: b1558e1272e5b6dc
IV: 4ce36ed28c8cd282
Cipher: cf8c21f475a58ac3
Decrypt: Hello

One weakness that is apprarent here is that we are using an 8 byte (64-bit) initialisation vector (IV), and which may cause a collision to happen, and where the same IV is used for data. When this happens, we can then just XOR the ciphertext streams together and reveal the plaintext.

The security of CAST5

For CAST5, the core method used is mostly unbroken. It uses a 16-round Feistel cipher, and where each round has four S-boxes with 8-bit inputs and 32-bit output. There are also 32-bit operations of XORs and addition/subtraction), and which use a part of the key each round.

Its main weakness is the size of its blocks, and where a 64-bit block size could encounter a collision and reveal something — but you would need a massive amount of data to do this. This is especially true when using a mode such as CFB, and where an IV could be repeated.

Along with this, it only supports a 128-bit key — and which is strong for security now but could be weak in future years, as we lose around 1 bit per year through improvements in processing performance. But, this worry goes with many other ciphers.

As with many ciphers, there can be the opportunity for a timing attack, too, but this is fairly low, as an attacker would have to get access to the low-level execution of the code which contained the secret key.

Conclusions

CAST5 is not used in most cases of symmetric key encryption and which has been mainly replaced by AES and ChaCha20. But, with PGP3, it showed a vision of how to secure email. Unfortunately, we still typically use unsecured methods for email, but, at least we have advanced the methods that PGP used. At its core was the use of symmetric key encryption to encrypt a message and public key encryption to protect the symmetric key.