Chapter VII – Ubreakable. Yeah, right! Brut-force attacks.

The aim of this chapter is to explain why it is important to create reasonable passwords for your email accounts and encryption key. We’ll do it through a description of how a (simplistic) attack on passwords is conducted.

But before…

How your private key is protected

A private PGP key (PGP is the name of the technology used to encrypt emails) is a string of 2048 or 4096 bits, that is 0’s and 1’s. To make is more reasonable for presentation you usually see it as a string of characters (which are 8-bit) so the key when printed on screen is not extremely long. If you haven’t looked at your encryption keys yet, they look much like the picture on top of this site.

A brut-force attack is by definition an attempt to to create all possible combinations of these 0’s and 1’s and then apply them to decrypt your email. Creating all possible combination of such number of bits would take a very long time, unreasonable even, so this is not really done.

What’s done then? Your private (decryption) key is protected with a password. Here’s how it’s applied. The password you set is first processed by a hashing function in order to create a 128 or 256 encryption/decryption key, because the most popular key-encryption algorithms require a fixed-length key to do their job. And passwords by their nature can be anything, therefore can have any length. You decide how long your password is.

So the key-encryption key is much shorter than the one used for decrypting email. Therefore, for a brut-force attack it is a lot more reasonable to try all combinations of this key to decrypt (some people say unlock) your private key and then decrypt the email. Complicated? Nope, just three steps. Bear with me a bit longer.

In essence this is what a brut-force attack is. But hackers are clever people and they would not stop here.

In fact, before a plain brut-force search is executed, a hacker uses the biggest lie in the world to make their job quicker – statistics. In other words, before starting heavy lifting, we’re going to check whether you were lazy setting up your password.

Dictionary attacks

In one of previous chapter we told you that your email server admins know your passwords. Indeed they do if they want to. Fear not, not for straight away evil purpose. What many companies do is create statistics of most popular passwords though. I know what you’re going to say: everybody sets a different password and such statistics do not make sense. Oh really?

A quick thinking hacker would google “most popular passwords” and for example arrive at a site like this: http://www.passwordrandom.com/most-popular-passwords. What this page publishes is the image of idiocy of Internet users, or for our purpose here a handy dictionary.

When we talk about a dictionary, we’re not thinking about Collins. We are thinking about the result of statistical analysis of passwords submitted to email providers to secure your email account.

So what we do is download such a dictionary, load it to our brut-force attack program and try the first 1000, 10000, maybe more passwords. We take a password, generate key-encryption key, decrypt the private key and decrypt the email.

These statistics don’t lie. There’s a fat chance one of these will just work. This procedure frees us from generating countless 0-1 combinations and we’ve saved a lot of time.

Yet another approach at attacking lazy people

I had a pleasure to work with workstations to which in order to have access (well, to gain it quickly without messing with settings) I asked a user to let me know the password. In a trusted (or not) environment there is nothing extraordinary about it, happens every day. It was not a huge surprise when some of the passwords I received were two-letters long and only letters. What is interesting about it is that one of them was the computer access password of a CEO.

Considering the length of the English alphabet we can almost instantly generate all 2-letter combinations of letters and digits. We do not need too much more to generate 3 or 4 symbol long combinations.  We mostly use only English letters for passwords, because often enough the keyboards we use do not allow us to enter special diacritic symbols that exist in languages like French, German, Polish, not to mention symbols characteristic to Asian tongues.

When we generate those, we create our own dictionary and then proceed according to the method described in the previous section here.

 

As an exercise I’d advise you to look again at the listing here: http://www.passwordrandom.com/most-popular-passwords and find out how high in the list your passwords are.  The higher they are, the less sense it makes to set them up at all.

You know nothing, there’s a lot more to it

What we’ve described above is an extremely simplistic attack. There’s a lot more to it indeed. For instance, when an attack is aimed at a specific person, the dictionaries are tailored  by entering dates of birth, marriage, husband, wife, children and pet names, favorite radio station, foot size, etc. All this information is now available online, so a dictionary is rather simple to compile.

End of Chapter VII

Chapter VI – Key servers, certificates and authorities

There is an element of our configuration we have not talked about yet.

We’ve mentioned, that in order to facilitate sending encrypted email one needs to hold the peer’s public key. This is always true. However, we have only mentioned one way of receiving this key, that is, receiving it through an email from the peer.

What we would like to achieve at this point is the ability to announce to the world that our encrypted communication is online. We want to achieve it without explicitly sending the public key to everyone who wants to use it.

Here’s a confusing concept. In order for everybody, whom we know, or whom we don’t, to use our public key for encrypting emails (to us), we need to send our public key to one place only, a key server.

Key servers

A key server is in fact a repository, a database of public keys. Those are typically identified by their ID and by the email address to which they relate. This relation is quite simple. To encrypt an email to a given email address, encrypt it with the key identified by this email address.

Now, this database is in fact a website (from our point of view that is), like this one: https://sks-keyservers.net/ . One can access it with a web browser and interact with it to send their own public key or to extract one. But a web browser access is not that practical for us. We would like something more handy.

Good news it that we already have everything in place. When you installed Enigmail plugin to your Thunderbird, you’ve equipped your system with a tool that allows to extract public keys (and send yours) from a key server. In Key management section of the plugin configuration you can see a menu entry called Keyserver

When you click on it you can see a few options, one of them being Find a key. The system will ask you for an email address (of a person you want to send an email to) or the key ID and will search its database for it. If found, you’ll be able to download and import this key into your encryption system.

By default Enigmail comes with a short list of key servers already configured for you. These are public key servers, where anybody can upload their key. For private use you do not need anything else.

In a professional environment the local IT policy might lead to a creation of a private key server that holds the keys for the employees only. In such case, such a key server needs to find its way into this configuration.

Certificates and Authorities

When talking about authorities we’re not going to think about government. In fact we’re flying above those now. A Certificate Authority (CA) is an Internet entity (you can loosely call it a company) whose job is to confirm an identity. You interact with those if you want to buy a certificate for a HTTPS site or when you want to have a global confirmation of your identity that is related your private and public encryption keys.

One thing wort mentioning… again. These entities exist above any governments. The authentication they provide is independent. They are also a fantastic source of revenue. In other words, it’s not all that good-for-the-people initiative. It’s business. And they work hard to keep the business going.  Sometimes when visiting HTTPS websites, your browser warns you about the inability to identify the website. The reason is that your browser can not find an identity related to a key used in creating the encrypted channel between your browser and the web server, in any of the known CA’s. You can ignore this warning. But again, it’s business, so these days, modern browsers make it harder and harder for you to do this. Mostly through unclear and intentionally overblown statements about a danger of visiting such a site. Then a button or a link allowing you to ignore them is tiny and named with something confusing, like “I’m suicidal, I want to go ahead and visit this site”.

You come across this subject in encrypted email communication, too. When you receive a signed email, your Thunderbird will tell you that a signature is Bad or Unauthenticated. The reason is described above. But here again you can ignore the warning and authenticate the signature yourself using a button on the right-hand side of the information about the signature.

The notion we’re talking about here is called self-signing. This site’s certificate and encryption key are both self-signed. This means, that I generated them, installed and never requested a CA to confirm my identity or the one of the igauga.net domain.

Instead of using Enigmail to generate your encryption keys, you can use one of the CA’s like DigiCert to create them for you. They’ll come with a certificate. Your identity will first undergo confirmation. Most likely you will be contacted to provide some additional information, like the tax id. Once this process is finished DigiCert will generate the keys for you and allow you to download them and import to Engimail. You’ll have an annual fee to pay for the certification to be maintained. The upside of using keys generated this way is that when you sign an email, your identity is considered true and authenticated on the receiving end automatically.

 

End of Chapter VI

Chapter V – Encrypting email on a smartphone

This chapter is short for the following reasons:

  • your smartphone is nothing more than a computer with additional feature that is the connection to GSM network
  • the concept behind using a smarthphone for out purpose is exactly the same as using a computer, we have
    • a standalone email client
    • a package handling our encryption keys and encryption processes

To make a short chapter short, here’s what one need to do to work with email encryption on the smartphone.

We already have an email client, every Android, Apple or Windows phone comes with one. We’re only missing the key management software.

One that comes first in search is called APG. It does the same as Enigmail, Enigma or Mailvelope. It allows us to generateour private and public key, allows for importing a public key we received in an email and allows to import our set of private and public keys we’d generated using any of the aforementioned packages.

The package integrates with our email client adding switches to it that allow for encrypting, signing and attaching the public key.

The one problem we have is how to transfer the keys we already use on another device.

There are a few options:

  • usb transfer
  • bluetooth file transfer
  • sending an email to yourself holding the keys. This one we should consider as the last resort, as such email and its contents will go through the mailbox stored at your email provider’s disks and therefore the data can be compromised.

We need to export our set of keys from one of the packages we use to a file, transfer it and import back to the mobile system. We’re ready to go.

 

Beyond adding the encryption capabilities, adding a smartphone to the set up gives us another advantage. We create a copy of our private key. And as it goes with a smartphone these days, we pretty much always know where it is.

However… Mobile phones are a popular target for all sorts of attacks, eve from authorities. Perhaps, keeping them away from the protected environment we’re trying to maintain could be a good idea.

 

End of Chapter V

Chapter IV – Admin sees everything – web-based tools

Modern web email clients are convenient, fast, functional and look good. For this reason many users do not even consider using standalone tools for working with their email.

What most users do not understand is that while the Internet privacy, in general, exists only as a discussion subject, using web tools for email strips one off the last defense in holding on to any secrets.

So why use them? Well, these tools are still very convenient and centrally managed. Changing a computer does not change your address book, email box content, the looks of the system, etc. It also allows you to access your email from a work computer on which you are not allowed to install any software. Although, these days our mobile phones successfully took away the need from doing this (smartphones and email encryption will be discussed in another chapter).

Having said all that, does it make sense to discuss these tools? I guess it certainly make sense to talk about the conditions when they are both convenient and secure (for the user). We’ll talk about two types of tools allowing email encryption when using a web client – web-only and hybrid – the latter, allowing to use the web access while holding the encryption keys and running the encryption locally, on your computer.

At the end of the chapter we’ll explain how it is possible that the admin sees everything… well, everything that matters. Later… for now take it for granted.

Web-only tools

Before presenting an example system let’s define when using encryption on a web-only email client is safe and protects you from eavesdropping.

  • when you manage your email client. Remember, the website presenting your email is only a client, it is not the email server. So what one can do is to build a private web-service – on a server at home, on a server rented from one of the cloud providers, or in a virtual machine on your computer, or simply a background process. Of course, the installation of such a tool, implies a number of pre-requisites, like a web server, the OS behind it, security systems, firewalls, etc. So in general let’s consider it an advanced subject. (You can also request the set up from an experienced IT professional and then take over, change all access routes and manage the system yourself from now on.)
  • when you trust your admin. Hahahaha! No, seriously. This is the Internet, you don’t have any friends. A trusted administrator in a company network, will dutifully keep your email safe and make sure you’re the only one that reads it until they’re told otherwise. A public email provider like Google or Yahoo! won’t even be located close to the word “trusted”.

Without unnecessary details, one web-based email client that provides encryption and key handling capabilities is  Roundcube – https://roundcube.net/. It is a free, lightweight and simple to configure software package that allows you to connect to any email service through IMAP and SMTP just like Thunderbird.

Someone that goes on installing it will most likely do that along their own email server. But that comes with another set of complications and is not always possible, when using a private, home Internet connections.

Hybrid systems

Yet, web email users are not all lost. One software package that provides email encryption for this case is called Maivelope – https://www.mailvelope.com/en/. It comes in a form of a web-browser plugin.

It is a package that enriches your browser with a toolkit that processes encryption on your local computer, while presenting the results embedded in the user interface provided by your webmail provider.

The downside of this system is that it ties the configuration to your installation of the web browser, therefore, taking away all the goodies related to accessing your webmail from anywhere. It won’t work with all webmail systems, nor with all web browsers. However, the main players are covered.

The upside is that the encryption and decryption does not reach the email, or webmail server, so you’re data is protected.

As for the configuration, it is similar to Enigmail in Thunderbird and requires the same encryption engine to be present on your computer.

Admin sees everything

Let’s go back to the web only systems. Even though the communication channel between your browser and the web server is encrypted, there are two places where the data flying through this channel is accessible.

  • just before your browser sends or receives the data
  • just before the web server sends or receives the data

The data, we’re concerned about is your password and the your email cipher.

Passwords

When you send your password to log in it is received by the server, processed (hashed) and then compared to the entry present in the database to confirm your identity.

Yes, it is first received and then processed. An admin can have the web server store the password before processing. We do not worry about it that much, because an admin does not really need your password to access any information. But think of this: How is it possible that Internet service providers periodically produce statistics of trivial passwords if those are only stored in a safe, encrypted, hashed or whatever else form?

Encrypted email

When you use encryption in a web-only service you need to understand what the web server really does.

Everything presented in your browser window (a system with Mailvelope installed is indeed an exception to that) has first been generated by the web server. So when you see your email cipher, it means that the server read it, placed it withing the website interface and sent to your browser. When in next step you request the decryption, the server performs the calculations, generates the text and again sends it to your browser.

The  admin can request the server to store anything that it generates before sending to you. It’s one of reasons for which web-only email encryption is not considered safe.

There are plenty more, like JavaScript attacks. These happen often when using a web browser at a random Internet shop or a computer infected with a virus or malware. JavaScript is a programming language that historically was designed to execute code within your browser. When unauthorized, hidden code is executed inside a dodgy browser, it can do a lot of harm to (or with) the content that the browser is presenting.

 

 

End of Chapter IV

Chapter III – Configuring Thunderbird

In this chapter we’ll configure an email client that will allow you to encrypt your email regardless of your email provider. To save space and reduce unnecessary copy-pasting, this chapter includes a few links to the basic installation guides provided by service providers and software developers.

The choice of Thunderbird as the go-to email client in this discussion is dictated by its availability to pretty much every popular operating system and consistency in usage. The configuration is exactly the same on Windows, Linux or Mac OS.

One condition required for this set up to work is that your email provider allows you to read your email using IMAP and send using SMTP. Most email providers allow this by default, so no action is needed from your side. But there are some exceptions.

We might write a chapter related to connecting to Microsoft Exchange servers. However, those typically exist in companies, managed by the internal IT team. It’s better to ask them.

Gmail users should follow this guide to allow the IMAP connection:

https://support.google.com/mail/answer/7126229?hl=en

Yahoo users could follow this:

https://help.yahoo.com/kb/SLN4075.html

 

Thunderbird, basic configuration

Thunderbird is a free and powerful email client. You can download it here:

https://www.mozilla.org/en-US/thunderbird/

or if you’re a Linux user, you can install it using your distribution’s repository.

Due to some legal issues, some distributions (like Debian) offer Thunderbird under the name Icedove.

 

When starting the program for the first time, the program will trigger your account configuration wizard. These days going through it may be as simple as typing in your email address and the password and the rest is automatically detected and configured for you. This is certainly the case for Gmail accounts – be it private or work accounts that exist under a different domain than @gmail.com, but are still effectively handled by Gmail.

 

If your account settings are not detected automatically, you need to google “IMAP configuration your email provider” or contact support. The information you need to find is:

  • IMAP server name – you use this address to receive email
  • IMAP login format – sometimes it’s just the username, sometimes username@email.domain, sometimes username+email.domain. Most of the time it will be username@email.com.
  • SMTP server name – you use this address to send email
  • SMTP login format – usually the same as for IMAP

Click on Manual configuration and the following dialog box appears:

 

 

Remember Chapter I when we talked about existing encrypted channels o communication? At this moment you have to opportunity to make sure your channel is encrypted.

The column SSL, offering two drop downs is here for that, when you open them, four options appear:

  • autodetect – Thunderbird will chose the best offered from the server – if possible, Thunderbird will choose an encrypted channel (one of two last in this list)
  • NONE – clear, unencrypted, if at the end of configuration this is what is available for you, change your email provider
  • STARTTLS – encrypted
  • SSL/TLS – encrypted

The last two are good. They differ in the detailed implementation, time of publishing and the people behind their design, but from our point of view they are both good.

Once this is configured, Firefox verifies the connection. It may ask you to accept a security certificate. Agree, add exception if necessary and we’re done. This certificate is necessary for the encrypted channel to be established.

The dialog box will close and Thunderbird will go on downloading your email.

The first time you try to send an email, Thunderbird will show two pop up windows. One saying, that sending failed and one offering you (again) an opportunity to accept a security certificate. Accept the failure message, accept the certificate and send again. Thunderbird won’t ask you about it again and sending any following email will work.

You have to accept two certificates because in fact you have connected your Thunderbird to two separate services – IMAP and SMTP. These two do not have to reside on the same server, or continent, so Thunderbird treats the security-related information separately.

IMAP and POP. Most email services offer IMAP and POP connection for incoming email. IMAP is the kind of connection that keeps the server (your account) content and your Thunderbird synchronized. Namely, what you delete in Thunderbird, is deleted on the server. What you keep, is kept in both places. POP is (was originally) a connect-download-and-your-prolem-now protocol. Thunderbird would connect to the server and download your messages. Once downloaded the messaged would be deleted from the server. Only your local copy would exist. It’s convenient if you work with an email service offering limited disk space. I’m not sure what the latest version of the protocol offers, so I’ll stop now and ask the interested reader to google away.

 

Enigmail – the encryption toolkit

Someone has written this part already, please follow this guide.

Do not skip GnuPG installation. This is the actual encryption engine.

https://enigmail.wiki/Quick_start

A note for Linux users. Your encryption engine is installed separately. Before installing Enigmail, you need to install gnupg2 and pgp-agent packages.

The installation of Enigmail should trigger the configuration of your encryption keys. If that does not happen open the Thunderbird menu and in the section Enigmail, select Key management. This will open a new window, where you need to find a menu entry called Generate and follow the wizard.

When generating keys you will be presented with an option to create a 2048 or 4096 bit keys. The 2048 bit option is typically sufficient for a non-paranoid user. However it’s worthwhile to note that longer keys are better. Althought their generation can take a very long time. It is dependent on your computer’s computational abilities and the computer’s activity at the time of generation.

You will be asked to create a password for your keys. This password is independent from the one you use to log in to your email account. It is generally advised not to set up the same one and to be inventive. Note that in view of email encryption discussed here, it would be a pity to ruin the whole set up with a password that is easy to guess. Be inventive., exercise your memory. In one of the following chapters we’ll discuss a bit brut-force attacks on passwords, so you have an understanding how really easy it is to get access to your data when you’re lazy.

We Are Ready… kinda-sorta

OK, so we’ve set up our email client and our email encryption environment. We’ve created our encryption/decryption keys and we’re ready to go.

Can we receive an encrypted email? Yes, we can. No one can send one to us yet. That’s a bit of a bugger.

Can we send an encrypted email? Yes, but to ourselves only. We do not have enough information to do more.

Will make this happen in a minute.

But for now you can do an exercise. Compose an email to yourself. Your Write  window (either hit Ctrl-N or click Write button in Thunderbird main window to show it) has a new menu now called Enigmail. Hover the mouse pointer over the buttons to see what they offer.

You’ll see three options:

  • encrypt
  • sign
  • attach public key

Select them all. The first option will trigger the email encryption. The second option creates a signature from your private key and attaches is to the email. The third option attaches your public key to the email.

When you click Send, you will be asked for your private key password. Thunderbird needs this password to access your private key and use it to calculate your signature.

Once you’ve sent it, the email will appear in your email list. Once opened you will see the email cipher (the encrypted version of the email), the information about a bad signature and in the menu, a few buttons to handle the email.

Why is the signature bad? When you created your encryption keys they have not yet been registered in one of the formal Internet authorities (another chapter). In such case, it is up to you to approve this signature and accept it as valid for any emails coming later from this sender. In this particular case you can do it right away, after all you’ve just sent an email to yourself. My guess is you trust the identity of this sender.

Your public key, that has been attached, will figure in the list of attachments. When you double-click on it, Thunderbird will offer you to save this key in your system. No need to do it now, it’s your key, and if you go to save it, Thunderbird will tell you this key is already in.

Click on the button to decrypt the email. Thunderbird should ask you  for your private key password. Sometimes it won’t. You might want to dig in your Enigmail settings to find a Timeout option. This option allows you to tell Thunderbird how long it should remember your password. Say you’ve set it for 5 minutes. Once you entered your password to decrypt an email, or sign an outgoing one, you are able to repeat any of these two for next 5 minutes without typing the password in again.

Now We Are Ready

All checked, let’s bring our encryption system alive.

If you want your peers to encrypt email sent to you, send them an  email that holds attached your signature and your public key, but don’t encrypt it. They need to read it easily first. It is their work now to accept your public key and store it in their repository or key-list.  It is not necessary that they accept the signature.

Ask them to send back their public keys (and possibly signatures). Once you’ve accepted the keys, you’re good to go.

Remember, you can only encrypt an email to a person, whose public key is present in your system.

 

Happy sailing!

 

End of Chapter III

Chapter II – Public-key cryptography, an overview

This is the second theoretical chapter in the discussion of email encryption. The understanding of the notions described below is paramount for the correct, practical application of email cryptography.

We will begin constructing our secure email system in Chapter III

When discussing the application of cryptography in email communication one should understand well its two functions:

  • assurance that an email sent from person A to person B can only be read by person B
  • verification that an email arriving presented as coming from person A has indeed been sent by person A

Both function are in practice executed through the application of a pair of cryptographic keys – a private and a public key. This chapter describes in layman’s terms what this means, and how it works exactly.

The public-key cryptography is often called the asymmetric cryptography because both processes mentioned above are executed using a private key on one end an the public key on the other.

Public and private encryption key

In computer based communication a cryptographic key is a set of letters, digits and punctuations signs forming a long, often fixed length “word” (although for a cryptographer this is understood as a set of 1/0 bits, which for practical reasons is only presented as letters, numbers, etc.)

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.6
Comment: Hostname: keys2.kfwebs.net

mQENBFiS2roBCADS8n/3eN4LIWIoZOSvS8Hl6hoPzIzDDnDrysYk7bVQOsGaQQhUSGrupF4z
bg1P7Shf3piLsoCqG2XMGBQ+xaInitdWCjk/erVXz7ZtLcTUGfKQzfpo2uk1pzNArOIvrjBG
FCMu3LyWUHA/tKK4DQW8MQvadpYezkEIy43Kj7gRrw/q97QgVFiKLWalo6fUhnRYS8ZXY4ag
LtZzFVXZqSBaNpUrTpNaAGLxUOhXwOCEgB7FZzYO/VHkTHZq3CEwYuvcFkpe+dmKAfNNPHTo
FXj8C9ALISoUxa2dxi7HcZK9txaWXcPYzW0FZamgIeKZgZJ0TDkq2i9L5vcoO1QujZJLABEB
AAG0Jk1hcmVrIFN1bGlnYSA8bWFyZWsuc3VsaWdhQGlnYXVnYS5uZXQ+iQEyBBABCAAmBQJY
ktq6BgsJCAcDAgkQTbwOFPfCfa4EFQgCCgMWAgECGwMCHgEAAKADB/4nBpZj0yIMr9z1xrSz
NiAenhfd98bJtizxcUsJi9hAVnnXW5WAnTxkUSUz7HqutPquf7GuZECGs/w+FjYRw5GoEzfW
K0gy9tdNx2zCA6k9rjPcsfwcTtBZFNTpUIvXmNKHBdXhSOEV6SxWd8BwhiA6FaTv3Lkkt32u
YEheZ0aUKUNjIuicc1Omcyp5rcFn4BVy8V1yN7DKPxOBhZiuVmjH8GJC3c6K3zmEMXGapU4l
D60Q1ZoXLBcQ/YQS7rlSYW2pEO18yMnk8lPxvp3zTCP+XFEl+IFVK1Id3oXDK7PNlaCLZXMV
UvL30rEvygqQ87ywrJVeC/SOPrl+0k7Na5I/uQENBFiS2roBCADNfdWbaVFdqq0o/4o4HP+0
9fVf7W161XdHeZmXp1+ISPjwB3/kPTvi+132rqYIv381/WHVnazY8gqWu8zC2AI9tyhwQAbE
LGSZE0MgCBP2fjJU58zEaqGHeHechEGYNZCitGV2T8pKPLDQv20a7Je47KIPYy5/IZeun/Ky
NMivmtvNcvaZztauEE6/0rQc0uAa8YnwFzSePgFjEJ3W8vMwDZZ5DefMH5PbO7qtmWfplBdL
sZ/9ItBcnO/icEcx0nh4NCi22lBsva0IHMsjRbTHzMaB4vmYhB0z9mrpW2+9yT/bt6iL5o/P
a7RFape7RFpfF1qPS2IIO5H0bRJD9A8TABEBAAGJAR8EGAEIABMFAliS2rsJEE28DhT3wn2u
AhsMAAAuzggA0eNZTB7Cv/6oh8hoSPR7cePFJYmYv/e/hNGCnDG0vA+4O143m3uko3gp21+m
9WvaVFkisban/TlLnbYD17ivj8paqRmQ6U7PntjN1Y5h6FE3KgzKwif8csLQSO5WWytezWqB
vCFzThaRR6IAvqlLFsEeym8ian9jdOJUA14dpIn1Gj33kYPukzAthoJOsQObMutv9VD3SGVO
eC2eZ2S7innJdiym9fAgbYvgKhtwurPd//q+eG9zWl7FNy1EkB8SSTKBYs/uo5xWtHP6yiVA
wzxECRN0C+HIp8owcs2GIq1va6n+GUynvYMxuIj+dTUyqjVN43Ow18bZGpO3fmENgQ==
=bdqR
-----END PGP PUBLIC KEY BLOCK----

When setting up your encrypted email, your system will generate two such keys 1) a private key which only you will (should) have access to, and 2) a public key that everyone you want to communicate with will (should) have access to.

The two keys always work together to complete whichever process (encryption/decryption or signing/identification).

Encrypting and decrypting an email

When person A sends an encrypted email to person B the following steps take place:

  • once the content is ready, before sending, the email is encrypted at person A’s end with person B’s PUBLIC key. This key could be retrieved from a key-server (another chapter) or delivered in an email from person B or delivered as a file on a usb stick….. Bottom line is that in order for person A to send an encrypted message to person B, A has to have B’s PUBLIC key to encrypt en email to person B.
  • Once the email has arrived, person B uses their PRIVATE key to decrypt and read the email.

Since only person B holds their private key, only person B can decrypt and consecutively read the email.

A worthwhile note on the private key. All tools available today will only allow you to create your private key protected with a password. Why is it so? This protects you against anybody who may sit at your computer while you’re brewing your coffee and read your communication.  The password on your private key is independent from the password you use to log in to your email service.

Signing an email

The purpose of signing en email is the identification, or the verification of identity of the person who sent the email. The following processes happen:

  • person A signs an email with their PRIVATE key and sends it to person B. This signature it NOT the private key. It is calculated through an irreversible formula, namely, one can calculate the signature using the private key, but it is impossible to calculate the private key using the signature
  • person B’s email system matches (again through a mathematical formula) this signature to person A’s PUBLIC key and therefore verifies the senders identity.

There’s only one signature that matches person A’s PUBLIC key. And to create it, person A uses their private key. Therefore, person A is the only one that can create the correct signature.

 

Until now it should be clear that we will operate with a private and public key that work in unison. None of the processes described below can be completed using only one of these keys.

It should also be clear that the PRIVATE key has to be kept secret and protected from unauthorized access .

It should also be clear that the PUBLIC key has to be distributed to everybody who we want to communicate with.

The last thing that should be clear is that the PRIVATE key should be kept save from loosing. Once gone, we will not be able to read our email or to verify our identity when sending one.

We can replace our set of keys with a new one at any time but we have to keep in mind that 1) the content of old emails won’t be accessible any more and 2) we have to make sure we redistribute our new public key to all entities we communicate with.

 

End of Chapter II

 

 

 

Chapter I – Encrypted channels of communication

This is the first of series of articles that will explain how email encryption works and what steps one must take to successfully apply it to their daily email communication.

The articles will talk about a few facts worth noting. We will describe what is already encrypted and what is not in your daily communication. We will then go on delivering a very non-scientific description of what public-key cryptography is and what that means to you as an email user.  We’ll present a few configuration options that you can use to enable encryption of your email. Finally, we’ll present the conditions necessary for encryption to function and a basic scenario leading to sending and receiving an encrypted email.

Encrypted channels of communication

For most of us the daily interaction with the Internet is defined by visiting websites. These may be news portals, blogs, email, video libraries, galleries, shops, …. the list goes on and on. But one common denominator is that the majority of these interactions go about the same scenario – your web browser sends a request to a web server to show a site and in response the server creates a page that is then sent back and presented on your screen.

One specific type of a page that we are going to look at is an email client.  An email client is effectively a graphical interface that allows you to read and send your daily dose of email messages.  This leads to the first statement worth a note. When you log in to a site like gmail, you are NOT connected to your email server. What you are logged into is an email client in a form of a web site.  The actual emails do no reside at the same place. Logging in to Google mail is in its logic the same process as starting Outlook or Apple Mail on your computer.

Let’s look closer at the process of logging in. Typically you type your user name or email address which shows on screen and then the password that shows on screen as a series of dots or asterisks. Finally you hit the sign in  button and you’re in (two-factor authentication falls beyond the scope of these articles).

Until this point nothing was encrypted. Presenting your password as a series of asterisks only protected your password against a random bystander who might be looking at your screen. So, was there any true protection of this sensitive data in all this?

Yes, you’ve just gone through an encrypted channel. When you look at the address bar of your browser before typing in your user name or email address you see the address shown as:

https://accounts.google.com/…

In some browsers, like Firefox there will be a green padlock picture to the left of this address line. The padlock and the first part of the address tells you that the communication between your browser and the google mail service is in fact encrypted and authenticated. But mind you, your email address and password are not! They were send as clear text, much like the page you are seeing, but the communication channel through which all this is sent is globally hidden, through encryption, from eavesdropping.

Google mail waits at the other end of the channel, so when they receive the data, it’s no longer encrypted. There are a few steps taken later that lead to protecting the passwords from theft (like hashing),but we as users have no control over them, or effectively are not informed what they exactly are.

For large majority of home computer users the list of encrypted channels in daily usage ends here.  But there are a few more that either operate for us behind the scenes or are used by people to perform specific tasks. Again, this and the following articles focus on  email so we’re not going to talk about services like SSH or LDAPS.

What happens behind the scenes.

When you click on Send on you email page two things happen:

  1. the service running the page you’re looking at communicates with the actual email server sending it the content of your email with a request to send it to your peer, this server is the source
  2. the email server connects with the target server, that holds the email account of the addressee and sends it the content of the email

In many cases (certainly not all) point 1 happens through an unencrypted channel, which often is not  a big deal since the web server and the email server are managed by one entity and it’s an internal process. One reason justifying clear communication at this stage is speed. Encryption requires computations and when numbers of processed emails reach millions, limiting required power to process makes sense.

Point 1 is pretty much always encrypted when the email client you use is not a website but a standalone program like Outlook or Thunderbird. Modern email providers offer only encrypted connections for these. We will talk about details pertinent to configuration of these programs in another chapter, as we will need them build your email encryption.

Until not very long ago point 2 happened also on a clear channel. That is our emails were flying through the Internet clear, therefore  easily eavesdropped on. Fortunately while an eavesdropping entity could read the content of the email they had no access to the credentials used when logging in to an email service, as those had been processed earlier and they’re not sent with a message.

This has changed. All big players encrypt their sending and receiving end now using the same technology that secures the communication between your browser and the email service.

 

So at this point it seems like everything we do with our email messages is protected by encryption. No, it’s not! When using a public email service like Google mail one has to be aware that Google can read all your messages. The reason for that is that much like your user name (or email address) and password, the content of your email arrives in clear form – being at the receiving end of an encrypted channel means that, when received, the information is decrypted back to its original form for further processing (analysis, flagging, making adverts a real pain in the back, etc.). That easily triggers lack of trust, which in fact is (should be) inherent to most of the things we do on the Internet. Knowing this what we want to achieve is complete discretion. Google is our courier and we do not want our courier to see what’s in the package.

This is where we enter the world of email encryption. From this moment on we will be looking into making sure that only I can read emails sent to me and only my addressee can read an email sent to them.

End of Chapter I