Using Fernet Ciphers to Secure Your Content
00:00 In the previous lesson, I gave you a brief introduction to cryptography and showed you some frequency analysis used to break that cryptography. In this lesson, I’m going to talk about far stronger ciphers and how to truly secure your content.
The one I’m going to be showing you is Python’s
cryptography. You can install that using
pip install cryptography. Because it’s going to be so strong, I’m also going to need to write a client that can read the messages from the server. The
requests library is an excellent way of talking to a web server.
There’s a method in the module that will generate a key for you, and here it is. Notice that this is binary data. Once you have that key, you can create a cipher by instantiating a
Fernet object, passing in that key.
01:31 The enciphered text is that easy-to-read mess. Using the same cipher object and the encrypted text, you can decrypt. And there it is—the original data. Getting encryption right is difficult. You should never implement it yourself.
01:48 You should always be using a library. You’ve already seen how frequency analysis can cause problems for someone using a cipher. Block ciphers get around this by grouping chunks of text together.
02:00 This makes frequency analysis far more difficult. AES encryption is a strong industry standard. It uses 128-bit keys and blocks. You can use longer keys with it by cycling through the algorithm multiple times.
02:27 This is a modified version of the Flask server from earlier. This time, taking advantage of Fernet enciphering. Lines 9 and 10 create the Fernet cipher based on a secret key passed in as an environment variable. Lines 14 and 15 replace the previous response of the cleartext message with an encrypted one. Here it is on the command line.
This is a client program that will talk to the server using
requests, and then decrypt based on a key. Lines 10 and 11 is where the
requests library hits the server on port
5684 and gets the response. Lines 13 and 14 uses the
fernet library to decrypt the response.
15 prints the decrypted response to the screen. Let’s see that in action. Once again—environment variable, pasting in the key, run the client, and you get back the decrypted response
shhhh, this is a secret. To demonstrate this is truly secure, I’m going to pass in a bad key. Give me a second.
Here it is. And an exception. The
cryptography library raises an
InvalidToken exception, denoting that the key passed in could not be used to decrypt the message. Without the right key, you can’t view the message. Your message is secure.
04:49 but the response has. The body of the response is the encrypted text. If someone were using Wireshark to eavesdrop on your connection, they wouldn’t be able to see your message. They’d only see the encrypted content.
05:05 Using a Fernet cipher has given you a strong encryption on your server. The problem you now have is managing keys. Anytime you add a member to your club, someone who you want to be able to read the message, you have to distribute the keys.
05:19 What happens if you suspect a key has been leaked and you need to change the key? Or, what happens if someone leaves your group? You’ll need to issue new keys for all the remaining members in order to keep it private.
05:31 This key management problem is difficult and it’s why asymmetric encryption has become so popular. Next up in the continued journey towards understanding HTTPS—how asymmetric key exchange works.
Become a Member to join the conversation.