Skip to content

Cyberchef Crypto - OPTIONAL

Cyberchef is a simple, intuitive web app for carrying out all manner of "cyber" operations within a web browser. These operations include simple encoding like XOR and Base64, more complex encryption like AES, DES and Blowfish, creating binary and hexdumps, compression and decompression of data, calculating hashes and checksums, ..., changing character encodings, and much more (from the Github sources).

Make sure you read and understood the "How Cyberchef works" section.

Deselect the "autobake" cell in the bottom row (this way you have to click "BAKE!" in order to run the selected recipe on the inserted input, which is easier to understand).

Data representation in Cyberchef

The webapp expects (input) and displays (output) characters.

These characters may be a recipe input, a recipe output, a recipe parameters.

There are several representations available including:

  • RAW the ASCII representation of the character is passed to the code that implements the recipe.
  • HEX the byte value corresponding to each character pair (hexadecimal digits) is passed to the code that implements the recipe.

Use HEX for parameters and RAW for input/output.

Note that copying and pasting RAW data may not work as expected (the webapp may discard some characters and modify others). In that case you may want to add recipe To Hex or From Hex for converting between RAW and HEX (HEX may be copy and pasted easily).

Private key crypto

Cyberchef supports many different algorithms for private key cryptography. Usage of each algorithm usually requires specifying many more parameters in addition to the key. Below we will not discuss what these additional parameters are for.

Choice of the encryption key

The algorithms suggested below support keys of different lengths, e.g., 16, 24, 32 bytes (128, 192, 256 bits).

Which of these character sequences can be used as a 16-byte key? Why?

  • f6041f627864c7b6a2cc259ee7cce4c8
  • f6041f627864c7b6
  • f6041f62
  • f6041f627864c7b6a2cc259ee7cce4c8aabb5643

In many practical applications, keys for private key cryptography are derived from a password (see section "Practical considerations 1" of this Colab Notebook. Cyberchef provides two recipes for doing that, Derive EVP Key and Derive PBKDF2 key. One of the keys above (the only one that can be used) has been obtained with the default configuration of Derive PBKDF2 key and password 'kakashevchenko'.

Encryption and decryption - Easy

Copy the following string in the URL bar of your browser. You should see Cyberchef with a recipe composed of 3 chained recipes already configured:

  1. AES Encrypt (with HEX output)
  2. From Hex (with RAW output)
  3. AES Decrypt (with RAW output).

The meaning of each parameter is described in the next section. The key is the only correct one in the previous section.

What you write in the input tab should be reflected in the output tab as it is. You cannot see the ciphertext (output of AES Encrypt).

By executing "STEP" in the bottom part of the web app, you will step through the chained recipe and see the output of each individual recipe, including the output of AES Encryot.

https://gchq.github.io/CyberChef/#recipe=AES_Encrypt(%7B'option':'Hex','string':'f6041f627864c7b6a2cc259ee7cce4c8'%7D,%7B'option':'Hex','string':'12345678901234561234567890123456'%7D,'CBC','Raw','Hex',%7B'option':'Hex','string':''%7D)From_Hex('Auto')AES_Decrypt(%7B'option':'Hex','string':'f6041f627864c7b6a2cc259ee7cce4c8'%7D,%7B'option':'Hex','string':'12345678901234561234567890123456'%7D,'CBC','Raw','Raw',%7B'option':'Hex','string':''%7D,%7B'option':'Hex','string':''%7D)

Encryption and decryption - Trickier

For encryption:

  1. Select a recipe for encryption (left menu, drag to the middle). You can "play" with AES, Blowfish, DES. These are all block ciphers (see "Private key cryptography: Mode of operation" in Approfondimenti_Network_Security).
  2. Insert parameters in the recipe:
    • Mode of operation: select one different from GCM (see also the Warning section below).
    • Initialization vector (IV): All block ciphers require this parameter. It must be identical for encryption and decryption and need not be secret (unlike the key). In practice, it is often chosen by the sender and sent along with the ciphertext. You may want to copy this sequence as many times as necessary: 1234567890123456
    • Key: You know what it is. Not every key length is allowed. How many characters do you have to insert for specifying a key of the required length, e.g., a 16-byte key? Why?
  3. Encrypt a text of choice (input tab, up right).

Now copy encrypted text, IV and key somewhere (e.g., on a file).

For decryption:

  1. Select a recipe for decryption, with the same algorithm used above for encryption.
  2. Insert in this recipe the same parameters as above (mode of operation, IV, key).
  3. Decrypt the previously encrypted text and verify that you indeed obtained the original plaintext.

Now try to modify the decryption key: does decryption work?

Then insert again the correct key but modify the ciphertext: does decryption work?

What you see might be surprising...this is explained in section "Practical considerations 2" of this Colab Notebook.

Send an encrypted message

  • Generate a ciphertext as indicated above in the "Encryption" example.
  • You want to send this ciphertext by email to another student.

What information is necessary for the student to decrypt the ciphertext, in addition to the key?

Regarding the key, think carefully about these issues:

  • How can you give the key to that student?
  • What if the student was thousands of Kms away?
  • What if you had to communicate with thousands of different students?

A tricky warning

Each of the AES, Blowfish, DES encryption algorithms support several modes of operation. GCM is the only mode of operation that provides integrity.

The previous examples use a mode of operation different from GCM, and thus correspond to configurations that do not support integrity. However, they do seem to support integrity (i.e. changing the ciphertext or using the wrong key provokes a decryption error). The reason is subtle. Informally and oversimplifying, these modes do not support integrity in the sense that it is always possible to find some modification that does not lead to a decryption error; on the other hand, "most" modifications will be detected (for any given modification, the probability that this modification will not be detected is very, very small).

The previous examples use a different mode of operation to GCM

The reason I suggested not using GCM is that the decryption recipe requires an additional parameter (GCM tag) which I do not know how to extract automatically from the encryption recipe so that the two recipes (encryption and decryption) can be chained together. I am not even sure if they can be chained together in this Cyberchef implementation.

HMAC

  1. Select the recipe for HMAC.
  2. Configure the recipe with with one of the available "hashing functions" and with a key (in this case the key can be of any length, unlike in algorithms for private key cryptography).
  3. Insert a text snippet as input and have a look at the output.

Try to modify a single character in input: does the modification provoke a small and localized change in the output? Or is the new output completely different from the previous one?

Insert a much longer input: does the output length change?

Public key crypto

You can "play" with RSA and PGP (the examples below outline the usage of RSA, usage of PGP is analogous).

You always start by generating a keypair. Save the private key in a file and the public key in another file. You will keep the private key secret and you will distribute your public key to anyone who needs to communicate with you.

You may want to experiment with other students (in which case you will have to exchange the respective public keys) or alone (in which case you will have to generate two or more keypairs and pretend to impersonate multiple people).

Encryption

  1. Choose a recipient.
  2. Select the recipe for RSA encryption.
  3. Configure the recipe with the public key of the chosen recipient.
  4. Encrypt a text of choice (cleartext) and save it on a file (ciphertext).

Regarding the public key, think carefully about these issues:

  • How do you obtain the public key of the recipient?
  • What if the recipient was thousands of Kms away?
  • What if you had to communicate with thousands of different recipients?

Decryption

  1. Use the file constructed as above (ciphertext).
  2. Select the recipe for RSA decryption.
  3. Configure the recipe with the private key matching the public key used for constructing the ciphertext.
  4. Verify that you can decrypt the ciphertext.

Now try to modify the decryption key: does decryption work?

Then insert again the correct key but modify the ciphertext: does decryption work?

Identity in public key cryptography

(All the considerations below apply to private key cryptography with very little modifications; we refer to public key because it is simpler and more common in practice)

Note that in the above procedures for encryption and decryption there is no notion of identity whatsoever.

There is no specification of "who" sent the message nor of "who" can decrypt the ciphertext. This notion is not required by the mathematical procedures for encryption and decryption: such procedures work at the keypair level: you encrypt with a number called public key, you decrypt with another number called private key.

In practical applications of public key cryptography, one has to reason in terms of people, organizations, websites and alike, i.e., in terms of entities that are external to a computer. For this reason, keypairs have to be associated with a subject. A subject has a name in form of a string that identifies an entity external to the computer, e.g., a person, an organization, a DNS name and so on. The identification mechanism (what that entity actually "is" and how it is identified by that string) is completely independent of public key cryptography. The only requirements are that the private key must be really private (i.e., known only to the entity identified by the associated subject) and that the association be real (this is subtle and difficult to explain precisely: the entity identified by the subject string must be really the entity that everyone would associate with that subject string).

In some cases the string that acts as a name for the subject is also called a "subject", i.e., in some cases there is no explicit distinction between a subject and its name.

Associations between public keys and subjects are based on certificates and on certification authorities. These are complex notions discussed later in this course.