# How does a key actually work in symmetric ciphers

My sky-high level understanding of modern cryptography is as follows: There is an algorithm and a key. The key or key pair is a randomly generated number (I think). The algorithm describes transformations to be applied to the plain text in order to encrypt it. The key is a specific piece of information that is needed by the algorithm to complete this process of encrypting the plain text. What I do not understand is how, precisely, do the algorithm and key interrelate. One can look at a schematic for, i.e. Serpent and see lots of arrows, boxes, feedback loops and so on. To an interested lay person such as myself, I cannot see:

1. What the key does to that set of processes or even where it fits in
2. How it is employed such that it's uniqueness effectively 'locks' the ciphertext.

I apologize for the preposterously rudimentary nature of this question. I do appreciate this board is populated by those with a sophisticated understanding of this subject. However, this has been bugging me for ages and here is an obvious place to ask.

Finally, I understand there isn't a single response to this inquiry given there are different types of keys used for different purposes. In the interest of addressing this, please assume I am referring to the encryption of plain text using a symmetric key algorithm that was fit-for-purpose in 2001 or later.

My sky-high level understanding of modern cryptography is as follows: there is an algorithm and a key.

Sure, a key is generally generated for a specific cryptographic algorithm that takes a key.

The key or key pair is a randomly generated number (I think).

Not necessarily. AES and Serpent just take a key consisting of random bits. RSA uses two random primes that are used to create the key pair, where the keys consist of multiple parts, at least an exponent and modulus generated from these primes. Or it could be a random in a specific range for the private key of ECDSA or ECDH, where the public key is actually a point on the curve. That private key is probably closest to "a number".

The algorithm describes transformations to be applied to the plain text in order to encrypt it.

If that algorithm is a cipher, then yes.

The key is a specific piece of information that is needed by the algorithm to complete this process of encrypting the plain text.

Not sure about the emphasis in that description of the key, as there are other possible pieces like an IV that are required. It's a bit more than that; it is the piece of information that is at least required to complete the process.

What I do not understand is how, precisely, do the algorithm and key interrelate.

That depends on the algorithm, the algorithm specifies what kind of keys are acceptable, and how large they may be (if there even is a maximum).

One can look at a schematic for, say, Serpent and see lots of arrows, boxes, feedback loops and so on. To an interested lay person such as myself, I cannot see what the key (i) does to that set of processes or even where it fits in; (ii) how it is employed such that its uniqueness effectively 'locks' the cipher text.

That depends entirely on the algorithm. In block ciphers such as serpent there is a lot of transposition and diffusion going on, generally trying to create an avalanche effect so that many bits is affected even within a single round.

However, with the asymmetric RSA cipher the private key is used for modular exponentiation during decryption and in ECDSA for point multiplication during signature generation. Exponentiation and point multiplication are more mathematical constructs than the bit operations that are common in symmetric ciphers.

Finally, I understand there isn't a single response to this inquiry given there are different types of keys used for different purposes. In the interests of addressing this, please assume I am referring to the encryption of plain text using a symmetric key algorithm that was fit-for-purpose in 2001 or later.

I've tried to explain it in the simplest way possible, also showing that it matters quite a bit what kind of algorithm we are talking about.

I'd study a bit more about block ciphers and try and e.g. implement S-AES (or SimpleAES, I'm not sure if there is an official name) if you're more of a developer type that learns by acting.

• The OP might benefit from Crypto101 (.io) – Legorooj Nov 29 '19 at 11:10
• Very helpful and a great illustration of how few generalizations are possible. Your precise description of the key is, perhaps, a generalization one can make: whatever the algorithm or system etc, it's the 'sine qua non'. – Adam Gold Nov 29 '19 at 21:44

How does a key actually work

Well, it's just a normal piece of data that CPUs can operate on. And the algorithm is just a collection of instructions on how to operate on those data.

# Take Caesar shift cipher as an example

Let's assume an alphabet of 26 characters (automatically case-preserving, and with whitespaces and punctuations presented unmodified), a key is a number between $$[0, 25] \cap \mathbb{Z}$$. The encryption algorithm treats a letter as a number and adds the value of the key to it, and subtract 26 from it if it overflows. Here, the key and the letters are abstractly represented with integers between 0 and 25 inclusive.

# What operations can CPUs do?

A lot. CPUs can operate on integers, and specially-encoded subset of rational numbers. For a medium-sized list of operations CPUs can do, you can refer to this Wikipedia page, which lists operators in C and C++, two of the languages that often compiles directly to assembly and machine codes.

• Thanks for the speedy response! I was actually thinking about the Caesar cipher when I wrote the post. Of course that's far easier to understand but basically you're saying 'same principle plus CPUs and sophisticated mathematics'. – Adam Gold Nov 29 '19 at 4:33
• But note that there may not be a CPU involved, e.g. memory cards such as DESFire are capable of performing DES or even AES without a central processing unit. – Maarten Bodewes Nov 29 '19 at 6:13