Skip to content

Cyberchef Crypto - OPTIONAL

Make sure you read and understood the Cyberchef page in this web site.

Data representation in Cyberchef

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

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.

Encryption

  • 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?

Decryption

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

WARNING

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

HMAC

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

Encryption

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

Decryption

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