Skip to content


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).

How Cyberchef works

Open the web app. There are many "recipes" (i.e., predefined computations) available on the left part.

One can select a recipe by double-clicking on it or by drag-and-drop. Each recipe takes an input and, when executed, it produces an output. Deselect the "auto-bake" checkbox in the bottom-center part. This way, recipes will not run automatically but only when clicking the "bake" button. This configuration is simpler to handle, I think.

Each recipe also has a set of parameters. For example, recipes for encryption have the key as a parameter; the input is the cleartext while the output is the ciphertext.

Recipes can be chained together so that the output of one is the input of the next one and so on.

Input, output and parameters can be represented in several ways, including:

  • HEX each character represents an hexadecimal digit; thus, two characters represent one byte and characters different from 0-9,A-E (upper or lower case) are incorrect.
  • RAW each character is handled as it is, the internal representation of the character is passed to the code that implements the recipe.
  • UTF-8 the UTF-8 representation of each character is passed to the code that implements the recipe.

In practice, one will typically use either HEX or RAW, just make sure to use them coherently (e.g., if the encryption output is HEX then the decryption input must be HEX as well).

URL Encoding (FORM data)

Data inserted in an HTML Form and sent in an HTTP request is URL encoded.

In brief (and oversimplifying), this encoding format makes sure that the encoded text contains only characters that can be part of an URL (for example, spaces cannot be part of an URL).

Take a moment to realize the countless applications of HTML forms. For example, if you write an email on a webapp, the text of the email is part of an HTML form thus your text will be sent to the server URL encoded. If you buy something online, your home address for delivery is part of an HTML form thus it will be sent to the server URL encoded.

  • Select the 'URL encoding' recipe.
  • Write some text in the input field and have a look at the encoding.
  • Copy the encoding and save it somewhere.
  • Discard the recipe and select the 'URL decoding' recipe.
  • Insert the previously saved encoding as input and verify that the output is the expected one.


Base64 is an encoding format that represents every sequence of 6 bits as an ASCII character (thus the encoded form will be longer than the original: 6 bit unencoded, 8 bit encoded). The encoding table is a standard that be found in many places, e.g., on Wikipedia. Certain predefined padding rules allow handling byte sequences whose length is not a multiple of 6 bits.

This encoding format is widely used, in particular, when binary data have to be used in contexts where text data is expected. Important examples are given below (HTTP Basic Authentication credentials and email attachments).

Encoding and Decoding

  • Select the 'To Base64' recipe.
  • Encode an hypothetical username or mail address or password and have a look at the encoding.
  • Copy the encoding and save it somewhere.
  • Discard the recipe and select the 'From Base64' recipe.
  • Insert the previously saved encoding as input and verify that the output is the expected one.

HTTP Basic Authentication Credentials

Username and password in HTTP Basic authentication are sent Base64-encoded and separated by a colon (':').

  • Select some web site that requires HTTP Basic Authentication (e.g., the 'Intranet DIA' on the page).
  • Insert a random username/password pair in the authentication form, but keep track of what you inserted.
  • Capture the HTTP request carrying the credentials. On the website indicated above this cannot be done with the browser developer tools; it may be done, e.g., with Wireshark.
  • Identify the HTTP header that carries the credentials; copy the credentials somewhere.

If the above operations look too difficult, search "http basic authentication request example" or something similar in a search engine. Try to find somewhere an example of HTTP request carrying the credentials as above.

Once you have the Base64 encoding of some credentials: - Select a "From Base64" recipe. - Insert the saved credentials as input. - Verify that the output has the expected content, i.e., username:password.

Important observation: given a Base64-encoded snippet, the corresponding decoding is a mechanic operation that does not require the knowledge of any secret. In other words, anyone that observes a Base64-encoded snippet is able to reverse the encoding and obtain the original snippet. Encoding has thus nothing to do with "encryption".

Email attachments

This topic is out of scope, i.e., it is not part of the course.

Files sent as email attachments are Base64-encoded before sending and inserted in the body of the email.

The email must contain some information for: - enabling the receiver to realize that (part of) the email body is Base64-encoded, i.e., that it has to be Base64-decoded before being presented to the receiving user; - indicating the filename of the corresponding part; - indicating how the email body is to be split between attachments and normal text.

Such information is usually provided by means of dedicated email headers.

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.

You can "play" with AES, Blowfish, DES. These are all block ciphers (see "Private key cryptography: Mode of operation" in Approfondimenti_Network_Security). In all the examples below, select a mode of operation different from GCM (see also the Warning section below).

Block ciphers require a configuration parameter called initialization vector (IV). This parameter 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.


  • Select a recipe for encryption.
  • Choose a key and an IV.
  • Encrypt a text of choice.

Note that for a given encryption algorithm 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?


  • Copy on a file the encrypted text obtained as above.
  • Copy on other files the key and IV.
  • Select a recipe for decryption, with the same algorithm used above for encryption.
  • Configure this recipe with the same key and IV (that you saved on a file).
  • Verify that you can decrypt the ciphertext (that you also saved on a file) correctly.

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

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

Encryption and Decryption

  • Chain two recipes, one for encryption and another for decryption (make sure they use the same algorithm).
  • Configure the recipes in the same way (i.e., same key and same IV)
  • Verify that the input of the first recipe (encryption) is equal to the output of the second recipe (decryption).

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. The recipient need to know the key you used for encrypting (and the IV).

How can you give the key to that student? What could go wrong? What if the student was thousands of Kms away? What if you had to communicate with thousands of different students? Think carefully about these issues.


AES, Blowfish, DES support several modes of operation. GCM is the only one of those that provides integrity.

The reason why it is suggested here to not use GCM is because the decryption recipe requires an additional parameter (GCM Tag) that I do not know how to extract from the encryption recipe automatically, so that the two recipes (encryption and decryption) can be chained together. I am not even sure they can be chained together in this Cyberchef implementation.

The reason why the previous examples, made with modes of operation different from GCM and that do not support integrity, seem to support integrity (i.e., changing the ciphertext or using the wrong key provokes a decryption error) is for a subtle reason. Informally and oversimplifying, those modes of operation 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 be undetected is very, very small).


  • Select the recipe for HMAC.
  • Configure the recipe with a key (in this case the key can be of any length, unlike in algorithms for private key cryptography) and with one of the available "hashing functions".
  • 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).


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

How do you obtain the public key of the recipient? What could go wrong? What if the recipient was thousands of Kms away? What if you had to communicate with thousands of different recipients? Think carefully about these issues.


  • Use the file constructed as above (ciphertext).
  • Select the recipe for RSA decryption.
  • Configure the recipe with the private key matching the public key used for constructing the ciphertext.
  • 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.