Modern cryptography and its applications can be easily understood at a high level by understanding its three main mechanisms: symmetric encryption, asymmetric encryption and hashing.

Symmetric cryptography

Let's start with symmetric-key cryptography, symmetric cryptography, or simply symmetric encryption, as this is what most of us will think of when talking about encryption. The term symmetric comes from the fact that the same key is used in order to encrypt and decrypt data.

Let's say you have a piece of sensitive information you want to keep safe. You can encrypt this information using a cipher, which is an algorithm used to perform encryption and decryption. In addition to your data you must also provide a secret key, and the cipher will process your data and output it in an encrypted format. Note: the key used in the diagram is a silly example, please avoid this type of patterns.

The data provided as input is said to be in plain text, and the output of the cipher is commonly known as ciphertext. Don't be misled by these terms, as this doesn't mean you can only encrypt text files. You can encrypt any file type you can think of.

If you have the ciphertext and the key, you can revert the process and get your data back. This process is known as decryption.

The most widely used symmetric-key cipher used nowadays is named AES, which stands for the Advanced Encryption Standard.

Don't lose or expose your key!

If you lose your key, you lose your data. You could try to brute force decryption, that is, trying out every possible combination for the key, but... for AES 256 it would take you roughly 13,689 trillion trillion trillion trillion years using 2 billion high-end computers.

This is how ransomware works: it encrypts your data and then asks you to pay for the key. If you don't pay, your data is pretty much gone.

Also, remember that anyone in possession of your key will be able to decrypt your data.

Ace, Beatrix, and Evo

Let's say Ace wants to send Beatrix a message over an insecure channel like the Internet, but Evo has successfully performed a Man In The Middle attack and is eavesdropping on their communication.

If the message is in plain text and Evo manages to intercept it, he will be able to read it. However, if Ace and Beatrix had previously agreed on a key, they could encrypt their messages using AES and Evo wouldn't be able to read them.

But what if they haven't performed this key exchange beforehand but they still need to achieve secrecy and privacy despite communicating over an insecure channel?

Asymmetric-key or public-key cryptography

This is where asymmetric cryptography will come in handy. It's called asymmetric-key cryptography or simply asymmetric cryptography because there are two complementary keys involved: whatever you encrypt with one can only be decrypted with the other, and vice-versa.

One is commonly referred to as a public key, while the other is known as a private key. As their names imply, the public key can be freely distributed, but the private key must remain unknown to everybody but its owner. This is also why asymmetric cryptography is also commonly known as public-key cryptography.

Anyone who knows your public key can send you encrypted data that only you will be able to decrypt.

The opposite is also true, that is, if you encrypt data with your private key, it can only be decrypted with your public key. This operation is known as signing and can be used as a form of authentication: since only you have access to your private key, only you could have encrypted that data, and your signature can be verified by decrypting it with your public key.

Back to ABE - privacy

Back to our example. If Ace wants to send a private message to Beatrix, she can now send him her public key. She could even publish it in an online forum she and Ace might frequent, or attach it to all of her emails, which is a very common practice.

The key with the green background is Beatrix's public key. Evo can also intercept it, but it doesn't matter, because well... It's public after all.

Ace can now use Beatrix's public key to encrypt the message and send it to her (red padlock).

Since Beatrix's got the matching private key (red), she can now decrypt the message.

Evo can also intercept this message, but he can't infer anything about Beatrix's private key using her public key or Ace's ciphertext, so he can't decrypt the latter.

An extremely common use case for public-key cryptography is to exchange a key that will be used for symmetric encryption, since the latter is far more efficient than the former and can make a difference, especially when having to encrypt large pieces of information. The most common way to perform this key exchange is using the Diffie-Hellman method.

The two most common variants of public-key cryptography used nowadays are the RSA algorithm and Elliptic-curve cryptography (ECC).

Don't expose or lose your private key!

Malicious users in possession of your private key will be able to decrypt anything encrypted with your public key, which was most likely private data meant for your eyes only.

They could also impersonate you since they can "forge" your digital signature, proving the ownership of the private key that only you are supposed to have access to.

If you think your private key might have been compromised, generate a new pair and spread the word so that everybody knows they should use your new public key and not the old one.

If you happen to lose access to your private key, naturally you will not be able to decrypt anything that was encrypted with your public key or use your digital signature anymore. This is the reason why many coins are lost forever in cryptocurrencies, and also why the first thing you're told to do when you create a software wallet or acquire a hardware wallet is to write down your seed phrase: a set of random words your private keys originate from. If you lose access to your wallet, you can recover it by using the seed phrase. Needless to say, you should keep these words somewhere safe, as anyone in possession of it will be able to steal all your funds.

ABE integrity

Ace and Beatrix can now keep their communication private thanks to encryption.

However, what if Evo decides to still intercept the message and mess around with it? Even worse, what if Evo knew about the format of specific messages Ace and Beatrix exchange frequently. For example, he might know that some messages start with a bank account number, and he could alter a few bytes so that it appears to be a different number once decrypted, just to mess around with Ace and Beatrix.

Ace and Beatrix now need a way to check the integrity of their messages.

Hashing

This is where hashing can help.

A hash function takes a piece of data of any size as input and outputs a fixed-length value called digest, hash value, hash code, or simply hash. The process is commonly known as hashing.

Hash functions are one-way functions, in other words, they are irreversible. This means you can infer nothing from the input using the output. This is why it is considered a best practice to store passwords digests in databases, instead of the passwords themselves (as always, there are pitfalls to be avoided, but we will discuss them in another post).

There are no keys involved in this case, although the input data is sometimes referred to as the key. The output only depends on the input, so the same input will always produce the same output.

The most widely used hash algorithm nowadays is SHA-2, which stands for secure hashing algorithm version 2. The length of the output of SHA-2 can be either 224, 256, 384, or 512 bits. SHA variants are commonly referenced by their length instead of the version, e.g. SHA-256, which is the most widespread.

An interesting property of hash functions is that any tiny change in the input will cause a dramatic change in the output.

Take a look at these two SHA-256 digests for two strings that only differ in 1 byte (1 bit actually).

0000000000000000000000000000000000000000000000000000000000000000
827d096d92f3deeaa0e8070d79f45beb176768e57a958a1cd325f5f4b754b048

0000000000000000000000000000000000000000000000000000000000000001
f774fbb3f4cc0777bc80b6e86e6bf5ab70e2875ecc4c8cf102840d801a9a74ab

This mechanism allows us to check if there's been any change in our data, which could be caused by an error, or by a malicious actor like Evo.

Back to ABE - integrity

Now that we have hashing, Ace can provide proof of integrity to Beatrix.

But is it enough with computing the hash of the message and sending it along? You might have already seen the problem with this approach: Evo can simply alter the message and recompute the hash, before forwarding it to Beatrix.

What Ace can do now, just like Beatrix did, is generating his own asymmetric key pair. Now, instead of just sending the digest of his message along, he can sign it, i.e. encrypt it with his private key. All Beatrix needs in order to verify this signature is Ace's public key.

You might also be thinking: anyone with access to the public key, including Evo, can still check the value of the hash now. Indeed, he could, and he could even recompute it, but he can't sign it, because he doesn't have Ace's private key. In other words, he can't break this authentication mechanism.

Evo could now start flipping bits like a maniac before forwarding the message to Beatrix, but thanks to these mechanisms she would realize that the channel has been compromised and would warn Ace.

Ace could have also signed the message itself by encrypting it with his private key, but it's a far more common practice to sign a digest instead, and there are two main reasons for this:

• As discussed, it provides proof of integrity.
• It's far more efficient, as it's much faster to compute a hash and then sign it than using asymmetric cryptography to encrypt a file or message that could be massive when compared to the short and fixed length of a hash.

Cryptography mechanisms and security properties - recap

• Thanks to symmetric and asymmetric encryption, Ace and Beatrix have achieved privacy.
• Thanks to hashing, they have achieved integrity.
• Thanks to public-key cryptography, in particular the signing and verifying operations, they have achieved authentication, i.e. the message is authentic and there's proof of its source or origin.
• They have also achieved non-repudiation (short for non-repudiation of origin). In this case, Ace won't be able to deny that he was the author of the message.

Picture the following scenario:

• A software project has reached the end of its lifecycle and you want to take it down, destroying all of the AWS infrastructure that you have provisioned using Terraform.
• This set of resources includes an RDS instance.
• You run terraform destroy and, after double checking the mass destruction plan, you push the red button.
• Destruction begins and you observe in ecstasy as the logs go by.
• Your hysterical evil laugh is abruptly interrupted by the following message:
  Error: DB Instance FinalSnapshotIdentifier is required when a final snapshot is required

To make things worse, the instance has prevented the destruction of all of the resources upon which it depended: the VPC and its subnets, security groups, etc.

Two things can happen now:

a) In a mix of cold sweat, extreme relief and silly laughter, you realize you actually needed a final snapshot... In this case you would add this to your aws_db_instance resource:
final_snapshot_identifier = "nyse_stonks_final_snapshot"

b) You don't care about the darn thing or you already have a proper backup, so instead:
skip_final_snapshot = true

No matter which path you choose, here comes the paradox: you now need to apply these changes in order to be able to destroy the remaining resources. But, of course, if you simply run terraform apply, you are going to create again all the resources you have already destroyed...

Good news is: you can actually apply changes to a single resource by first targetting it.

We can first check what resources are still there and identify the RDS instance by running terraform state list. Your list might look similar to this one:

aws_db_instance.nyse_stonks_db
aws_db_subnet_group.nyse_stonks_db
aws_security_group.nyse_stonks_db
module.vpc.aws_subnet.private[0]
module.vpc.aws_subnet.private[1]
module.vpc.aws_subnet.private[2]
module.vpc.aws_vpc.this[0]

Terraform allows us not only to save our plan into a file, but to target specific resources as well, so let's do both:
terraform plan -target aws_db_instance.nyse_stonks_db -out evil.plan

As expected, there will be a single change in this plan, e.g.

~ resource "aws_db_instance" "nyse_stonks_db" {
    ...
  ~ skip_final_snapshot                   = false -> true
    ...
}

Let's proceed to apply the plan by running:
terraform apply evil.plan

Don't forget to remove the plan unless you have a pattern under .gitignore, or it might accidentally end up under version control (it happened to a friend of mine).

And finally, if you are still 148% sure that you want to destroy everything:
terraform destroy -auto-approve

Observe with immense joy as you have finally managed to destroy all the things.

Another typical case where this approach can be useful is in case you forget to remove the deletion protection on EC2 instances, ALBs, etc.

Systemd is a Linux init system and software suite developed mainly as an effort to standardize the Linux init system. It has effectively replaced others like SysV init or upstart in most distros, although it keeps a very high degree of backwards compatibility with the former. It has been adopted by most Linux distributions since 2015.

What is an init system?

An init (short for initialization) system or process is the first process started by the Linux kernel during boot, bringing up and maintaining userspace services. Systemd shares a few traits with most init systems:

• Since it's the first process to start, it bears the process identifier (PID) 1.
• It has no parent process. This is denoted with a parent PID (PPID) of 0.
• It will continue to run until the system is shut down.
• It is the common ancestor for every process.
• It automatically adopts all orphaned processes.

The kernel thread daemon, kthreadd, has in most cases PID 2 and is usually the only process other than systemd that has no parent. All kernel threads are forked from this process.

Separate instances of systemd are started for logged-in users to start their services. That is why if you start going down the tree, i.e. towards the root (init) or looking for the parent of each process, you will most likely hit a process whose command looks something like /lib/systemd/systemd --user and in most cases this will be a direct child of the actual init process with PID 1.

The standard init process can actually be replaced with some other binary (e.g. /bin/bash) via the kernel init argument, but this is meant to be a temporary change in order to do some troubleshooting (or hacking ;) ) and of course it will deprive the user or sysadmin from every service offered by it.

Why is systemd so hated by many?

Even though to the eyes of most Linux users and system administrators it is essentially a new standardized init process, it provides utilities for a wide array of tasks including device management, login management, network connection management, and event logging (the init component is actually known as the system and service manager). This goes against one of the fundamental principles of the Unix philosophy: "Make each program do one thing well".

Despite the fact that systemd is actually a software suite rather than a single application, many consider it to be bloated. For example, systemd has its own UEFI boot manager called systemd-boot, but most distributions keep using GRUB instead and will most likely continue to do so.

In any case, usage of all the components of the suite is by no means mandatory and every Linux user can choose which ones to use.

Units

Units represent resources managed by systemd. Each unit can declare required or optional dependencies on other units in the system, ensuring that at least all of its required dependencies are up and running before starting it.

Units don't have to be exclusively services, and despite the core component of systemd being an init system, it's not mandatory for all units managed by systemd to be started at boot.

Unit files and their locations

In order to create a unit, you only need to create a text file describing its configuration. Unit files are commonly found under three different locations:

• /lib/systemd/system: units managed by packages or the OS.
• /etc/systemd/system: these are usually managed by the sysadmin and can override unit files under /lib (this is the most appropriate place for making changes).
• /run/systemd/system: non-persistent runtime modifications (remember a filesystem of type tmpfs is mounted under /run).

Naming convention

Unit files are named following a "name.type" convention, e.g.

• docker.service: the docker service unit.
• ssh.socket: a unit of type socket for accepting ssh connections.
• reboot.target: the reboot target-type unit (more on targets later).

These are the three most common types of units, but there are several others like device, mount, swap, path, timer, etc.

Anatomy of a unit file

Unit files are organized in sections denoted by square brackets, e.g. [Section]. The [Unit] section is common to every unit file, and others like [Service] are specific to a type of unit. Sections contain directives in the form Key=Value.

Let's analyze the sections and their directives in a standard unit file for the Nginx web server and reverse proxy:

[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/var/run/nginx.pid
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID

[Install]
WantedBy=multi-user.target

The Unit section is generally used for defining metadata for the unit and defining its relationship with other units.

• Description: a short description of the unit, usually including its name.
• Documentation: it can reference one or more man pages instead of a url if there are any available.
• After: this unit should be started after all the units referenced in this directive. This does not imply dependency and such must be defined through either the Requires, Wants or BindsTo directives.
• Wants: establishes a dependency on the units listed here. Unlike Requires, which is more strict, this unit will continue to function if its dependencies are not found or fail to start. Wants is recommended instead of Requires.

The Service section is unique and mandatory for all units of type service.

• Type: specifies the type of service according to the behavior of its process. In this case, forking means that the service forks into a child process, the parent exits and the child continues to run as the service main process.
• PIDFile: a path referring to the PID file of the service used in combination with Type=forking so that systemd can reliably identify the main process of the service (whose PID will be stored in the MAINPID environment variable and used later by ExecReload and ExecStop in this case).
• ExecStart: the command to be executed when the service starts. In this case we can see that it is of course the Nginx binary and that the default configuration file is provided with the -c option.
• ExecReload: commands to execute to trigger a configuration reload in the service. In this case, the unit is configured to send a SIGHUP signal, which by convention is often used to let know a process that it should re-read its configuration.
• ExecStop: as you've probably guessed, the command to execute in order to stop the service (by sending a SIGTERM to it).

The Install section is optional and is used to define the behavior or a unit if it is enabled or disabled. Enabling a unit marks it to be automatically started at boot. In essence, this is accomplished by latching the unit in question onto another unit to be started at boot (in this case referencing the multi-user target via the WantedBy directive).

• WantedBy: this can be seen as the Wants "reverse" directive. It causes a dependency of type Wants= to be added from the listed unit to the current unit. In this case, since Nginx service is enabled, it's "wanted by" the multi-user target.

Targets

As we have already seen, targets are a type of unit. According to systemd's man pages:

A unit configuration file whose name ends in ".target" encodes information about a target unit of systemd, which is used for grouping units and as well-known synchronization points during start-up.
Target units do not offer any additional functionality on top of the generic functionality provided by units. They exist merely to group units via dependencies (useful as boot targets), and to establish standardized names for synchronization points used in dependencies between units. Among other things, target units are a more flexible replacement for SysV runlevels in the classic SysV init system.

In other words, targets can be seen as groups of units, and they are "reached" when all of these units have started successfully. There is an equivalent target for every classic SysV runlevel. These are actually symlinks and can be examined by running
ls -l /lib/systemd/system | grep '.target$' | grep runlevel

runlevel0.target -> poweroff.target
runlevel1.target -> rescue.target
runlevel2.target -> multi-user.target
runlevel3.target -> multi-user.target
runlevel4.target -> multi-user.target
runlevel5.target -> graphical.target
runlevel6.target -> reboot.target

If you are developing your own service, you can even write your own target so that any other services relying on it can know when it's "online", i.e. when all of its dependencies have been fulfilled, e.g. it might depend on network-online.target and postgresql.service. The most common naming pattern for this would be myservice-online.target.

Systemctl

The final important piece of the puzzle is systemctl, the systemd system and service manager control. It can be seen as a CLI to interact with systemd.

As specified in its man pages, its syntax goes along
systemctl [OPTIONS...] COMMAND [UNIT...]

So if you want to check the overall status of the system, you can run:
systemctl status

If you want to check the status of the sshd service in particular:
systemctl status sshd.service

You can also check if targets have been reached:
systemctl status multi-user.target

As mentioned before, systemd keeps a high degree of compatibility with the classic SysV init. If you check the location of the init command under a system managed by systemd (/sbin/init), you will see that it is actually a symlink to /lib/systemd/systemd. If you want to enter runlevel 6, i.e. rebooting your machine, these four commands would be equivalent:

reboot            # /sbin/reboot -> /bin/systemctl*
init 6            # /sbin/init -> /lib/systemd/systemd*
systemctl reboot  # reboot is available as a systemctl command
systemctl isolate reboot.target  # targets can be "isolated"