Introduction to applied cryptography for non-IT folks

Last updated 21/06/2022

As our lives become more and more dependent on computer apps, it becomes more and more critical to know how to use them securely. In order to do so, few basic cryptographic concepts need to be understood. While there are many great in-depth detailed articles about each of the subjects described below, I couldn't find any single text that would give a good high-level overview of all of them. Hence this article.

The information provided below is very brief and sometimes simplified comparing to actual security practices for readability purposes. In such cases a more detailed technical note can be shown using button. Readers who are new to the matter should rather omit these notes at first reading and may return to them later if they are interested enough in the subject.
For the most curious readers, there are also links provided to related Wikipedia articles and other sources marked with symbol.

Contents:

  1. Intro
  2. Symmetric algorithms
  3. Asymmetric algorithms
    1. Encrypting
    2. Digital signatures
    3. 3 state lock analogy
    4. Contemporary algorithms
  4. Man-in-the-middle attacks
  5. Authentication using asymmetric algorithms
  6. Public key infrastructure
  7. Phishing attacks

Cryptography is a branch of math and computer science that among others, studies data encryption/decryption, entity identification and data authentication (an entity is anything that can send&receive messages, for example a person, a company, a website, a web browser, an email app etc).

Algorithms (methods) of data encryption/decryption are divided into 2 main categories: symmetric key algorithms and asymmetric key algorithms (also called public key algorithms).


In case of symmetric algorithms, entities that wish to exchange encrypted messages must share a common secret key, that will be used both to encrypt and decrypt messages.


Example:
One of the earliest known symmetric algorithms described in history is Caesar's Cipher, that was used (and probably invented) by Julius Caesar. A key is an integer number, usually between 1 and the number of letters in a given alphabet (let's call this number k). Encrypting works by replacing each letter in the message by a letter that is k positions further in the alphabet than the original one. For example if k=2 and the message to be encrypted is "bite" and English alphabet is used, then we need to replace 'b' with 'd', 'i' with 'k', 't' with 'v' etc, so the whole resulting encrypted message (called a cryptogram or ciphertext) is "dkvg".


If adding k positions to a given original letter results beyond the last letter in the alphabet, we start counting "cyclically" from the start of the alphabet, so for k=2, 'z' is encrypted as 'b' and 'y' as 'a'.

Caesar's cipher can be easily broken using many various methods and is considered completely insecure these days. Contemporary systems use much more complex algorithms than that. Most people will not ever need to manually choose which symmetric algorithm to use as this is done automatically by software, so that's not something you need to worry about.


The main disadvantage of symmetric algorithms is that it is quite hard to securely exchange a shared key: it requires a communication channel, that cannot be wiretapped by any 3rd party. Unless some other encryption method is already in place, neither internet nor phone lines meet this requirement and the only ways are to directly whisper to someone's ear or directly hand them a pendrive/piece of paper etc.


In case of asymmetric algorithms, everyone has their own key pair consisting of related public key and private key. Entities usually advertise their public keys publicly (hence the name) and must keep their private keys a well guarded secret known only to themselves. Entities A&B that wish to exchange secret messages using asymmetric algorithms, must first fetch each other's public key. After that, when entity A wants to send a secret message to entity B, it needs to encrypt it using B's public key. Resulting cryptogram can then be decrypted only using B's private key.


Asymmetric algorithms are generally way more complex than symmetric ones and thus also waaay slower. Therefore, in practice asymmetric algorithms are only used at the beginning of a given session (such as a single internet connection, a single email message, a single chat conversation etc) to exchange a newly created symmetric key (called a session key) that will be used for the remaining of the given session and then discarded.

Asymmetric algorithms are fairly new: first invented in 1970s. Their main advantage is that it is much easier to securely exchange keys: other 3rd parties may listen to A&B's public key exchange and it will not compromise security in any way. The only requirement is to verify that the public keys were not modified by any adversary during the exchange: if an adversary replaces some entity's public key for his own, he will then be able to read secret messages sent to this entity. Replacing someone's key may be quite easy in several situations: see "Man-in-the-middle" chapter for more details.


Some asymmetric algorithms (also) work the other way around: if a message is "encrypted" using someone's private key, it can later be "decrypted" only using their public key. This can be used to create digital signatures: if it's possible to "decrypt" a message using some entity's (the signer) public key, this means that this message was created by someone who has this signer's private key (which should only be this signer unless their private key was stolen). Therefore we will from now on refer to "encrypting" with a private key as signing and "decrypting" with a public key as verifying [a signed message].


Signatures are usually sent/published along their original messages as a separate files/messages called detached signatures.

In practice signing whole messages would be often inconvenient: first, it would be very slow as mentioned before, second, signatures would be of sizes comparable to their corresponding messages, which in case of big files would take a lot of space. Therefore in practice a signer first calculates a cryptographic hash of the message that is about to be signed: a short sequence of bytes derived from the content of the message. A cryptographic hash is a one-way function: it is very fast to calculate a cryptographic hash for a given message, but it's extremely difficult to find another message that has the same hash. After that, only the hash of the message is signed and sent/published along the original message as its detached signature.
If someone wants to check validity of such a signature, they first need to calculate the hash of the orignal message themselves and then "decrypt" (verify) the detached signature with the public key of the signer. If the result of "decryption" and the previously calculated hash are the same, then the signature is valid: only someone who has this signer's private key could have created it.

As it is very difficult to find another message that would have the same hash as some given message, it is virtually impossible for any adversary to use such a signature for another inauthentic message. To make it even harder, some meta-data may be added and signed into the signature along the hash: for example message length, date and time when the signature was made etc.


Asymmetric algorithms can be quite confusing at first. Fortunately some smart people came up with a very good analogy to a lock that has 3 positions: left, middle, right and is unlocked only in the middle position. Now there are also 2 types of keys to this lock: 1 key that can turn the lock only to the right (so from position left to middle and from middle to right) and the other that can only turn left. You keep the right-turning key private to yourself and make multiple copies of the left-turning one and distribute them publicly.
Now if you have an open box with such a lock, anyone can put a message there for you and lock it with one of your public keys that turn the lock to the left. Only you can now open this box with your right-turning private key. The message is effectively encrypted with your public key.
On the other hand, if you put some document into such a box, lock it to the right with your private key and send it to someone, they will know for sure that the document came from you, because only you have the right-turning private key. The message is effectively signed with your private key (and anyone can retrieve it with one of the copies of your left-turning public key).


Currently the most popular asymmetric algorithms are older RSA and newer Ed25519 (sometimes imprecisely referred to as ec25519, X25519 or Curve25519). When possible, Ed25519 is more recommended, but RSA is also ok. RSA can use keys of different lengths, usually indicated in bits next to its name, like RSA-4096. The bigger the number, the harder it is to break it. These days 2048 bits is an absolute bare minimum, if possible use longer than this.
There are also 3 algorithms developed by NIST: P-256, P-384 and P-521, but while independent researchers were not able to point any weaknesses in them, many people distrust NIST due to its connections with NSA.
Some older example that you may still see sometimes, but should generally avoid is DSA, which while not inherently bad, is prone to be implemented incorrectly and thus was mostly decommissioned.


Man-in-the-middle (MITM) is a type of cracker (evil hacker) attack that tries to wiretap and/or alter (encrypted) communication between entities A&B, ideally in a way that keeps A&B unaware that they are being attacked.

The first, non-cryptographic step for an attacker to perform a MITM attack is to make sure that messages exchanged by A&B physically go through him. There are several ways to achieve this:

In case of unencrypted communication, the above methods are sufficient to wiretap and modify A&B's communication without them even realizing this.
Furthermore if an attacker M is able to catch the moment when A&B exchange their public keys and replace them with his own, then he will be able to continue the attack even after A&B start to use encryption.

After replacing the keys, M needs to intercept every subsequent message transmitted between A&B, decrypt it with his own private key, read and optionally modify if he wishes, encrypt it with intended recipient's public key and forward it on to him. This way A will think it encrypts messages the way only B can read them, while the messages that B will receive will be indeed properly encrypted with his public key (and vice-versa).

If A additionally signs messages with its private key, M can still modify them and sign with his own private key: as the public key that B received was also replaced with M's key, B will properly verify M's signatures thinking he did it using A's public key.

Diagram showing man-in-the-middle attack in case A attaches detached signature of her message:

To avoid MITM attacks entities need to exchange their public keys using few independent channels, so that it's very difficult for any potential attacker to control all of them. For example simultaneously by email, SMS and some communicator app. The exact set of channels depends on specific situation: for most people any 2 separate channels are usually sufficient, however folks that are likely to be targeted by powerful adversaries (like big corporations, mafia, government agencies) or folks that live in particularly oppressed territories, should be more careful. Ultimately verifying keys face to face when possible, is always the most secure way.

Public keys may be long, so in practice only 1 channel is used to transfer the whole public key (or even just a link to it), while on the other channels only its fingerprint is transferred: a cryptographic hash of the public key together with some meta-data. As explained before it would be extremely hard to find another message (key) with the same cryptographic hash, so verifying just the fingerprint is sufficiently secure.

In case A&B have securely exchanged their keys, attackers may still try to primitively trick them with "Hey, this is B, a dog ate my private key, so I needed to create a new key pair. Here is my new public key: ...". More experienced crackers will use various social engineering methods to trick you into believing this is indeed true, so be wary: if your peer's public key changes, the new key must be again verified using several independent channels. Until this is done, you should assume you are talking to an attacker. Even if your peer seems to know things only he should be able to know, it may still be an attacker who is simultaneously talking to your peer and tricking him to reveal these things.


Entities who previously have securely exchanged their public keys, can use a form of a challenge-response authentication to verify each other's identity any time later. When entity A needs to prove its identity (authenticate itself) to entity B, it must answer a question, that only someone who knows A's private key can answer. To do so, first B sends to A a short, randomly generated challenge message. A signs this message with its private key and sends the resulting cryptogram (response) back to B. B then verifies the cryptogram with A's public key and checks if the result is the same as the original challenge message.



To prevent a replay attack in which an adversary snatches a response from A and presents it itself to B to impersonate A, a secure channel should be used.
To prevent B from reusing a response from A and presenting it to some other entity C to impersonate A, A may sign a message that combines the challenge and some identification of the entity for which the response is intended (for example B's public key).
There may be many other corner cases depending on specific situation and the exact protocol and algorithms being used, so preventing all sorts of possible attacks may get very tricky. You can see for example (but better don't ;-] ) how insanely complicated CertificateVerify message structure needs to be in TLS protocol.


Public key infrastructure (PKI) is a centralized system designed among others, to securely distribute public keys. This can decrease the risk of man-in-the-middle attacks.


Example:
When a web browser tries to fetch some website over HTTPS (HTTP + TLS), one of the first thing that the website does is presenting its certificate. The browser checks if the certificate was issued by a CA that it trusts and if so, verifies the certificate using CA's public key as described above. Additionally, the browser checks if a special field of the certificate called Subject Alt[ernative] Name (SAN) matches website's domain name in the navigation bar. After that, all further data sent by the browser will be encrypted using website's public key from its certificate.

As mentioned before, the browser will actually use website's public key only to send encrypted symmetric session key, that the browser and the website will use for the remaining of this connection to encrypt their communication.

You can view the current website's certificate by clicking the padlock icon in the navigation bar, then 'connection [is] secure' link, then on Firefox 'More information' and 'View Certificate' button, while on Chrome 'Certificate is valid' and optionally 'Details' tab:

 

In practice most websites don't have their certificates issued directly by one of browsers' built-in CAs. Usually it's some intermediary CA, that in turn has its certificate issued by a built-in CA. For example in the screenshots above, we can see that Wikipedia's certificate was issued by "DigiCert TLS Hybrid ECC SHA384 2020 CA1", which in turn has its certificate issued by the built-in "DigiCert Global Root CA". This is called a certificate chain. In such cases browsers need to validate all certificates in the chain starting from the bottom website's certificate all the way up until they reach a self-signed certificate of a built-in CA (or a manually imported CA that the user trusts, like his company's CA).


If a PKI is done right and its CAs are indeed trustworthy, then it may provide quite solid security. Nevertheless even the most secure systems are still prone due to human factor and can be exploited with phishing and domain spoofing (see "Phishing" chapter). Furthermore, the PKI system used across the internet has some serious issues and to make things even worse, whether all WWW's CAs are trustworthy is a questionable matter.


Phishing is a type of attack that, while not specific to WWW, can be used to bypass WWW's PKI and perform a MITM attack on a communication over HTTPS. Generally speaking, phishing uses social engineering techniques to trick a victim to think he is interacting with someone else than he really is and obtain his confidential information along the way. Phishing usually starts with a message (email, chat, phone call) that seems to come from some legitimate entity that the victim tends to interact with at least sometimes (like victim's bank, building management, popular website etc). For example a victim may receive an email similar to this:

From:LinkedIn <noreply@lińkedin.com>
To:Victim Name <victim-email-box@victim.email.provider>
Subject:You have a new message on LinkedIn!
Hi,
You have a new message on LinkedIn!
To view your inbox click here.

The body of such an email will look very similar or even exactly identical to legitimate emails from LinkedIn: the same formatting, graphics etc. The only difference will be the domain in the link and in the From header (if security settings of the victim's email provider are weak, then From header can be completely spoofed also). In the above example, the attacker additionally uses domain spoofing: he registered a domain with the name very similar to the targeted one (lińkedin vs linkedin), so it's even harder for the victim to notice that something is wrong. Since the attacker is in control of this domain (regardless if it's similar to the target or not), he can easily obtain a valid certificate for it (for example an automatic one from letsencrypt). As a result, if the victim clicks the link, the browser may report the connection as totally secure. Next, lińkedin.com website will display a login form that is identical to the real LinkedIn's one to trick the victim to reveal his login credentials.

Most modern browsers have black-lists of domains notoriously used by crackers and may display a warning, but this is a cat&mouse game: crackers keep registering new domains on and on.


From then on everything goes like in a classical MITM attack: the victim is using LińkedIn's public key from the certificate, thinking that this is LinkedIn's key. The attacker (LińkedIn) forwards everything from the victim to the real LinkedIn and also forwards back the responses from LinkedIn to the victim.

If a phishing is done right, it's extremely hard for a victim to notice that he is being attacked: while some very wary users may notice lińkedin.com is not the same as linkedin.com, gооgle.com seems legit, right? Well, it's not ;-] The 'о' characters in gооgle are not the ones you are used to: these are characters from the Cyrillic alphabet that just happen to look the same as 'o' from the Latin alphabet ;-] If you press Ctrl+F and search for google, the previous 2 will not match.
If you use your browser's password-manager/auto-password-fill-in, then there may be one small hint at the spoofed login page: unlike a human eye, the browser will notice that the spoofed domain does not match any of those that you have a password stored for. Therefore the browser will not automatically fill the password field, forcing you to type it manually and thus hinting that this may not be the website you are looking for.
Regardless, the proper way to avoid phishing attacks is to generally avoid clicking links from messages. Apart from links to spoofed websites, crackers also send links that try to exploit vulnerabilities in popular email/chat/web-browser programs and can sometimes take full control of your device (in a way that you won't probably even notice).

Speaking of which, it is critical to use bookmarks to navigate to websites that are important for you, instead of typing their domain names manually: crackers tend to register domains that are common misspellings of popular domains (for example linkdIn.com, gooogle.com), so that you may literally phish yourself ;-]

Both companies and browsers try to prevent it by adding such misspellings to black-lists or buying them along their real domain names (for example gooogle.com is owned by Google), but this is again cat&mouse game.


Copyright Piotr Morgwai Kotarbiński except 3-state-lock.png copyright and courtesy of Bui Thuy An.
This site is 100% static and does NOT use cookies.