The security space can be a strange and confusing place for newcomers. In this series of posts, we aim to shed light on the security lingo you may encounter when reading the latest security specifications and scanning your favorite Duende documentation. By the end of this post, you’ll have added one more security phrase to your growing lexicon of security jargon with which to impress your fellow security professionals.

Today’s security lingo terms are Encode, Encrypt, and Hash. Each term is used in software and security to describe converting a string into a different representation. Each function is used for different scenarios. At a glance, these functions may seem interchangeable, and it’s easy to mistake one for the other. Not knowing the differences among options can lead to confusion or even security incidents. Let’s discuss what each term stands for and where you can see and hear it used.

Encode

To encode a string is to convert from one format to another. The encoding process is reversible by anyone who knows the format. From a security perspective, encoded data is not obfuscated, and sharing an encoded string is just like sharing a plain text string.

Think of encoding as a different way to express the same information. Hello, Hola, Bonjour, and Nuqneh are all the same word and can be translated from one language to another. An encoded string can be translated from one format to another, no matter which format it’s currently in.

The plain text string “Duende Rocks” can be encoded to the following values:

We encode data when a receiving system requires it. For example, a URL parameter cannot contain spaces, so we URL Encode the value to replace all spaces with %20, like in the example above.

Encrypt

Encrypting data differs in that converting data into an opaque format can be decrypted back into its original form, but only if you have the key required to decrypt it. A key is used during encryption, so the resulting data can appear wildly different even when a key is only slightly different.

The following C# code uses Symmetric encryption on the string “Duende Rocks” with the key “Encryption Key 1”. Because the data is encrypted at the byte level, the result is not human readable. Let’s look at some boilerplate C# code to encrypt a string using the AES algorithm.

using System.Security.Cryptography;
using System.Text;

var keyBytes = Encoding.UTF8.GetBytes("Encryption Key 1");
using var writeStream = new MemoryStream();
using Aes aes = Aes.Create();
aes.Key = keyBytes;
aes.IV = new byte[16]; // Zero IV so results are reproducable for demonstration

using var cryptoWriter = new CryptoStream(
    writeStream, aes.CreateEncryptor(), CryptoStreamMode.Write);
using var encryptWriter = new StreamWriter(cryptoWriter);
encryptWriter.WriteLine("Duende Rocks");
encryptWriter.Close();
cryptoWriter.Close();

var encryptedBytes = writeStream.ToArray();
Console.WriteLine(string.Join(", ", encryptedBytes.Select(x => x.ToString())));

The table below shows the original string and the encrypted bytes produced using different keys.

We encrypt data so an unauthorized party can’t read our secrets if they get a copy. It’s possible for someone on the same network as you to intercept and view all network traces. So if you’re using the public Wi-Fi at your local bowling alley, someone could see all requests/responses between your web browser and the Duende documentation site you frequently visit. Since the Duende documentation site is hosted over a secure HTTPS connection, the data is encrypted between you and the website. Copies of those network calls can’t be decrypted without the encryption key.

Hash

Finally, hashing is a one-way process that ensures no one can ever reconstruct the original value. Unlike encryption, hashing algorithms do not require a key. The same input will always create the same output. For example, the SHA1 hashing algorithm converts the string “Duende Rocks” to 4993fbc3044a88f062e772f4a9caaa05a4f99c29.

We hash when we don’t need the original value, but need an artifact of it. When a system stores a user’s password in a database, no human should ever need the original value, not even the people working on that system. When a user signs in, the system hashes the input password (and can combine it with a known random piece of information, or salt, stored when the user was created), and compares it against a hash stored in the database. If the hashes match, then the user supplied the correct password.

Conclusion

Hopefully, this gave you a better understanding of these three common security terms. We covered only the basic definitions, and there’s much more to learn about each.

As always, thanks for reading. We look forward to your comments. Please feel free to ask any questions in the Duende community discussions.