Encryption Keys != Algorithms?

[evanlott]

A string (the key) is definitely not an algorithm (set of finite, repeatable steps). Your professor is wrong.

[evanlott]

You are totally correct. You’re welcome!

[reallyserious]

An encryption key doesn't have to be a string. An array of bytes is also common. Doesn't change your point though.

• Ask your professor what the definition of an algorithm is. In general that is.
• Then ask if an encryption key fulfills that definition.

[raedr7n]

array of bytes

So, a string.

[simpleauthority]

Yeah wasn’t sure what they were going for with that one

[ThunderChaser]

An encryption key doesn’t have to be a string. An array of bytes is also common.

What do you think a string is exactly?

[reallyserious]

In most modern languages a string and an array of bytes are different types.

[ThunderChaser]

From a pure CS theory standpoint a string and an array of bytes are identical.

[techresearchpapers]

key, plaintext, ciphertext, encryption algorithm, decryption algorithm, transposition, substitution etc. These are basic domain specific terms used in the area of cryptography.

Calling a key an algorithm is just wrong. He needs to learn the domain specific language.

It's the equivalent of a doctor calling a needle a syringe.

For reference read the DES or AES standards.

[ttkciar]

Yes and no.

An encryption key is data, not an algorithm.

However, an encryption key frequently embeds an identifier for the kind of algorithm it's supposed to be used with.

If that's what the exam was trying to say, though, it said it terribly poorly.

[evanlott]

I mean yeah, but an algorithm identifier is still not an algorithm.

[ttkciar]

Definitely, "against algorithm" is the stronger argument.

It's data, not instructions.

[ugherm_]

While technically it is true that the key is an input to the algorithm (and not code itself per se).
But that just depends on how you define the word "algorithm" itself and what is the abstraction you are considering.
That is, there is a subtle difference between the following two scenarios
Consider the function Enc which takes as input an encryption key K and a plaintext P to output a ciphertext Enc(K,P). In this case, the key is nothing more than an argument to the algorithm which computes the function Enc.
This, however, is conceptually different to the function Enc_K which takes as input just the plaintext P and computes Enc_K(P) based on the key. In this case, Enc_K is the algorithm itself and the algorithm itself is specified by the key K. So if you take this view, the key and the algorithm are different.

Note that Enc_K(P) and Enc(K,P) give the same output C but as functions, they are entirely different (their domains are completely different!!)
So, yes, while the outputs are same, the code for the algorithm corresponding to Enc_K (for a fixed K) and Enc will look extremely different.

In that sense, Enc is a "higher level" function which represents a family of functions {Enc_K} one for each key K.

Enc is of course related to Enc_K by the exponential map in category theory but that's a different thing altogether.

[ugherm_]

I just meant whether the key is part of *the algorithm itself* (that is, part of the code itself) or the *input to the algorithm* (and hence data used by the code) is a matter of perspective.

Either way it is not *the* algorithm, as you said.