Practical cryptography

Welcome and thanks for joining!

What we will cover

How cryptography makes the modern world go round and how you can practically utilize it.

This isn't a math course.

You won't become an expert cryptologist,
but hopefully a power-user!

Requires basic knowledge of...

• Linux shell scripting
• Python programming
• Networking
• Docker and Docker Compose

How we will do it

• Lectures and Q&A
• Individual and group presentations
• Lab exercises
• Continuous reflection
• Quizzes and scored tests

For detailed notes, glossary, labs and similar, see:
t.menacit.se/crypto.zip.

These resources should be seen as a complement to an instructor lead course, not a replacement.

Acknowledgements

Thanks to IT-Högskolan and Särimner for enabling development of the course.

Thanks to Yubico for providing YubiKeys to in-class students for labs!

Hats off to all FOSS developers and free culture contributors making it possible.

Free as in beer and speech

Is anything unclear? Got ideas for improvements? Don't fancy the animals in the slides?

Create an issue or submit a pull request to
the repository on Github!

Contributors <3

• Joel Rangsmo
• Kristin Karlsson
• Patrik Gäfvert

Let us dig in!

Historic usage and basics

How did we end up here?

URGHH - SUSSO! KEEF.
HAAAWER NE NE!
FEVA.

— Your average caveperson

Greetings! I'm an excellent hunter. See this fancy fireplace I got here? Let's make some babies!

— Your average caveperson

Neat things about the written word

Allows preservation of complex information.

Enables conversions and relaying of detailed information/instructions over vast distances.

(Kinda necessary for ruling an empire)

Perhaps you want to keep some things a secret?

Let's hide the information!

We call this practice steganography.

Other notable examples

• Lemon juice ink
• Image file EXIF data
• Printer tracking dots
• Songs by Aphex Twin

The downsides

Often requires trust in
courier(s) of the message.

Mayhaps someone is a bit mad
since you ruined their haircut?

Enter the "Caesar cipher":

F  T F I I  Y X H B  X  Z X H B

Plain-alphabet:
a b c d e f g h i j k l m →
n o p q r s t u v w x y z

Cipher-alphabet:
X Y Z A B C D E F G H I J →
K L M N O P Q R S T U V W

Plaintext:  i  w i l l  b a k e  a  c a k e
Ciphertext: F  T F I I  Y X H B  X  Z X H B

Plaintext:  m a k e  i t  s o o n  p l e a s e
Ciphertext: J X H B  F Q  P L L K  M I B X P B

Probably confusing at first,
but quite easily broken.

Largely security through obscurity.

Let's not just shift characters,
but substitute them in a random order!

Plain-alphabet:   a b c d e f
Cipher-alphabet:  9 4 7 1 2 5

Plaintext:   d e a d  b e e f
Ciphertext:  1 2 9 1  4 2 2 5

Plaintext:     f e e d  d a d 
Ciphertext:    5 2 2 1  1 9 1

The downsides

Every participant needs to
know the cipher-alphabet.

Languages are not random,
there are patterns and rules.

People who try to break
codes/ciphers are called
cryptanalysts.

> F  T F I I  Y X H B  X  Z X H B
< J X H B  F Q  P L L K  M I B X P B

F and X appear on their own,
probably a and i.

FQ is a two-letter word, limited options.

Four words begin with a different letter
but end with XHB.

B appears five times in the messages,
probably e, o or t.

Method is known as frequency analysis.

Introducing keywords

Everyone can remember the
secret word "bad", right?

Let's try using the Vigenère cipher
(anno 1553) to encrypt "cafebabe".

Plaintext:   c  a  f  e  b  a  b  e
Keyword:     B  A  D  B  A  D  B  A
Ciphertext:  ?  ?  ?  ?  ?  ?  ?  ?

Plaintext:  >c< a  f  e  b  a  b  e
Keyword:    >B< A  D  B  A  D  B  A
Ciphertext: >D< ?  ?  ?  ?  ?  ?  ?

Plaintext:   c >a< f  e  b  a  b  e
Keyword:     B >A< D  B  A  D  B  A
Ciphertext:  D >A< ?  ?  ?  ?  ?  ?

Plaintext:   c  a >f< e  b  a  b  e
Keyword:     B  A >D< B  A  D  B  A
Ciphertext:  D  A >C< ?  ?  ?  ?  ?

Plaintext:   c  a  f >e< b  a  b  e
Keyword:     B  A  D >B< A  D  B  A
Ciphertext:  D  A  C >F< ?  ?  ?  ?

Plaintext:   c  a  f  e >b< a  b  e
Keyword:     B  A  D  B >A< D  B  A
Ciphertext:  D  A  C  F >B< ?  ?  ?

Plaintext:   c  a  f  e  b >a< b  e
Keyword:     B  A  D  B  A >D< B  A
Ciphertext:  D  A  C  F  B >D< ?  ?

Plaintext:   c  a  f  e  b  a >b< e
Keyword:     B  A  D  B  A  D >B< A
Ciphertext:  D  A  C  F  B  D >C< ?

Plaintext:   c  a  f  e  b  a  b >e<
Keyword:     B  A  D  B  A  D  B >A<
Ciphertext:  D  A  C  F  B  D  C >E<

DACFBDCE!

How about decryption?

Plaintext:   ?  ?  ?  ?  ?  ?  ?  ?
Keyword:     B  A  D  B  A  D  B  A
Ciphertext:  D  A  C  F  B  D  C  E

Plaintext:  >c< ?  ?  ?  ?  ?  ?  ?
Keyword:    >B< A  D  B  A  D  B  A
Ciphertext: >D< A  C  F  B  D  C  E

Plaintext:   c >a< ?  ?  ?  ?  ?  ?
Keyword:     B >A< D  B  A  D  B  A
Ciphertext:  D >A< C  F  B  D  C  E

Plaintext:   c  a >f< ?  ?  ?  ?  ?
Keyword:     B  A >D< B  A  D  B  A
Ciphertext:  D  A >C< F  B  D  C  E

Plaintext:   c  a  f >e< ?  ?  ?  ?
Keyword:     B  A  D >B< A  D  B  A
Ciphertext:  D  A  C >F< B  D  C  E

Kerckhoffs' principle

The security of a cipher
must be based on the chosen key,
not keeping the algorithm secret
(AKA "security through obscurity")

The cat and mouse game went on,
more or less the same way...

Technologies such as the telegraph
and radio really shook things up.

Even commercial enterprises found
the need for encryption.

Even if the cipher can't be broken, a lot can still be learned.

From where was the message sent? By whom?

We call this metadata.

Cryptography became too
complex for most humans.

If machines maketh,
let machine breaketh.

While it had evolved significantly,
encryption algorithms worked more
or less the same until the 1970s.

Let me introduce you to
asymmetric cryptography.

Symmetric

Same key is used for encryption and decryption.

Asymmetric

Different keys are used for encryption and decryption
("public key" and "private key").

Everyone can encrypt messages to me, but only I can decrypt them.

Also enables "digital signatures".

That's right - cryptography can help us
protect the authenticity of messages from
an author, not only their confidentiality.

Did I mention "cryptographic hash functions"?

Wide range of use-cases, including:

• Integrity validation
• "One-way encryption"
• Proof-of-Work

+ a lot of other exciting things we
shall learn about throughout the course!

So, my dear modern human -
have you relied on cryptography today?

Cryptography helps us ensure
confidentiality and integrity
of information.

Should be infeasible to break,
but it's never impossible.

Modern cryptography operates
on bits, not letters.

Lab setup

What you need to know to get started

You'll need a YubiKey 5 for
some of the non-graded exercises.

To install/configure tools required for the
course labs, several options are available:

1. Native setup:
   Recommended for students running Ubuntu 24.04 LTS on a physical/virtual machine
2. Non-native setup:
   Recommend for students running Windows/MacOS on their physical machine
3. Manual setup:
   Available for students running other Linux distributions/operating systems

See "resources/labs/README.md" for details!

Symmetric encryption

An introduction to it's uses

Same key is used for encryption and decryption.

Used primarily for protecting confidentiality
of information at rest and in transit.

How does symmetric encryption of
binary data work?

XOR logical operator

Many symmetric algorithms relies on
the "Exclusive or logical operator"
to produce ciphertext by mixing a
derived key and plaintext data.

XOR plays the same role as
Vigenère alphabet table.

Let's have a look at the
operator's "truth table"!

Let's encrypt the byte 0 1 0 1 1 0 0 0 ("X")
with the key 0 1 0 0 1 1 0 1 ("M").

Plaintext:   0  1  0  1  1  0  0  0
Key:         0  1  0  0  1  1  0  1
Ciphertext:  ?  ?  ?  ?  ?  ?  ?  ?

Plaintext:  >0< 1  0  1  1  0  0  0
Key:        >0< 1  0  0  1  1  0  1
Ciphertext: >0< ?  ?  ?  ?  ?  ?  ?

Plaintext:   0 >1< 0  1  1  0  0  0
Key:         0 >1< 0  0  1  1  0  1
Ciphertext:  0 >0< ?  ?  ?  ?  ?  ?

Plaintext:   0  1 >0< 1  1  0  0  0
Key:         0  1 >0< 0  1  1  0  1
Ciphertext:  0  0 >0< ?  ?  ?  ?  ?

Plaintext:   0  1  0 >1< 1  0  0  0
Key:         0  1  0 >0< 1  1  0  1
Ciphertext:  0  0  0 >1< ?  ?  ?  ?

Plaintext:   0  1  0  1 >1< 0  0  0
Key:         0  1  0  0 >1< 1  0  1
Ciphertext:  0  0  0  1 >0< ?  ?  ?

Plaintext:   0  1  0  1  1 >0< 0  0
Key:         0  1  0  0  1 >1< 0  1
Ciphertext:  0  0  0  1  0 >1< ?  ?

Plaintext:   0  1  0  1  1  0 >0< 0
Key:         0  1  0  0  1  1 >0< 1
Ciphertext:  0  0  0  1  0  1 >0< ?

Plaintext:   0  1  0  1  1  0  0 >0<
Key:         0  1  0  0  1  1  0 >1<
Ciphertext:  0  0  0  1  0  1  0 >1<

We got 0 0 0 1 0 1 0 1 as our ciphertext!

How do we perform decryption?

Ciphertext:  0  0  0  1  0  1  0  1
Key:         0  1  0  0  1  1  0  1
Plaintext:   ?  ?  ?  ?  ?  ?  ?  ?

Ciphertext: >0< 0  0  1  0  1  0  1
Key:        >0< 1  0  0  1  1  0  1
Plaintext:  >0< ?  ?  ?  ?  ?  ?  ?

Ciphertext:  0 >0< 0  1  0  1  0  1
Key:         0 >1< 0  0  1  1  0  1
Plaintext:   0 >1< ?  ?  ?  ?  ?  ?

Ciphertext:  0  0 >0< 1  0  1  0  1
Key:         0  1 >0< 0  1  1  0  1
Plaintext:   0  1 >0< ?  ?  ?  ?  ?

Not that hard, right?

A side effect of using XOR this way is
that we can recover (parts of) the key
if we know (parts of) the plaintext.

Exploiting this fact is called a
known-plaintext attack.

Modern encryption ciphers put a lot
of effort on trying to prevent
it and other similar issues.

Plaintext:   0 >1< 0  1  1  0  0  0
Ciphertext:  0 >0< 0  1  0  1  0  1
Key:         0 >1< ?  ?  ?  ?  ?  ?

Not that hard, right?

A side effect of using XOR this way is
that we can recover (parts of) the key
if we know (parts of) the plaintext.

Exploiting this fact is called a
known-plaintext attack.

Modern encryption ciphers put a lot
of effort on trying to prevent
it and other similar issues.

Let's move on, shall we?

Most symmetric ciphers are categorized as
block ciphers or stream ciphers.

Block ciphers split plaintext data into
parts of a fixed size (128 bits, for example)
and encrypts each part ("block") separately.

Most commonly used for "at rest" encryption.

Stream ciphers performs encryption of
each bit "independently" in a stream
of plaintext data.

Commonly used for "in transit" encryption.

Which approach is the best?

What are the advantages and disadvantages?

Hard to answer is a general/honest way.

Historically, many have considered
block ciphers harder to break and
stream ciphers more efficient.

(not necessarily true,
depends on algorithms compared)

Meet the algos

(3)DES

Data Encryption Standard.

Block cipher algorithm defined in 1977
by the US government as a part of the
Federal Information Processing Standard.

Key size was deemed inadequate as
computer performance increased rapidly,
replaced by "Triple DES" in mid 90s.

If you see it used, assume it's broken*.

AES

Advanced Encryption Standard,
also known as "Rijndael".

Block cipher standardized in 2001
by the US National Institute of
Standards and Technology
after a public competition.

Supports different key sizes and "modes"
(more about that later).

Resource hungry, but accelerated in
hardware by most processors ("AES-NI").

(A)RC4

Rivest Cipher 4
(or perhaps "Ron's Code 4").

Proprietary stream cipher developed
by Ron Rivest in 1987, later leaked
and reversed engineered.

Historically used in network protocols
like WEP/WPA, SSL/TLS and RDP.

Highly efficient, but considered
insecure by modern standards.

ChaCha20

Successor to the "Salsa20" stream cipher,
developed by Daniel J. Bernstein.

Used in several network protocols,
like TLS, standardized by the
Internet Engineering Task Force.

Relatively simple to
implement correctly ("securely").

Fast/efficient even without
hardware acceleration.

Woah, that's a lot of acronyms!

Let's look at how we can utilize
"at rest" encryption to protect
our precious information.

Data encryption can be implemented at...

• File level
• File system layer
• Block layer
• Hardware layer

File level

Cherry-pick files and encrypt em'!

Built-in support in several file formats,
like PDF, DOCX and XLSX.

Encrypted ZIP archives are a popular option
(often using broken ciphers like 3DES).

Useful for transferring sensitive data
over untrusted networks or easily lost
storage mediums, like USB drives.

File system layer

Modern file systems like
EXT4, BTRFS, ZFS and APFS natively support
encrypting selective parts file system tree,
like specific directories.

Used to provide per-user data encryption
on Android and MacOS.

Efficient and seamless, but may leak
metadata about encrypted files and
leave traces in unencrypted parts
of the file system.

Block layer

Application/OS provides a
virtual block device (storage disk)
that transparently encrypts data
before storage on physical disk.

Popular option for
Full Disk Encryption-solutions
like BitLocker, VeraCrypt and LUKS.

All data is encrypted, regardless of
sensitivity (for good and bad).

Hardware layer

Encryption is handled in the
storage drive without assistance
from the host's operating system.

"Opal" is a common standard for
Self-Encrypting Drives developed by
the Trusted Computing Group.

~No performance overhead, but require
trust in a proprietary black box.

Some final notes

Throughout the course, we'll dig deeper into
tools for symmetric data encryption
at the file and block layer.

Passphrase is not the same as encryption key,
typically used to derive/unlock it.

The devices used to encrypt and decrypt
data must still be trusted.

Symmetric file encryption lab

Lab description

Non-graded exercise to implement symmetric file encryption in a simple backup script.

For detailed instructions, see:
"resources/labs/sym_crypt/README.md".

No screenshots of text, please - they make the polar bear very sad!

Group exercise

Exercise: Let's warm up!

Participants are split into two or more groups.

Group members should discuss:

• What cryptographic tools/technologies/software they are already familiar with
• What areas/use-cases they are most interested in learning about
• What has been good/bad with the previous course and what would they like to change

After presentation, send notes to
courses+crypto_010501@0x00.lt

Cryptography basics recap

Cryptography helps us ensure
confidentiality, authenticity and integrity
of sensitive information.

Steganography is a related practice in which information is hidden/obscured.

These have historically been used in unison.

Caesar cipher

Plain-alphabet:
a b c d e f g h i j k l m →
n o p q r s t u v w x y z

Cipher-alphabet:
X Y Z A B C D E F G H I J →
K L M N O P Q R S T U V W

Plaintext:  i  w i l l  b a k e  a  c a k e
Ciphertext: F  T F I I  Y X H B  X  Z X H B

Plaintext:  m a k e  i t  s o o n  p l e a s e
Ciphertext: J X H B  F Q  P L L K  M I B X P B

Let's encrypt "cafe"
with the keyword "bad"
using the Vigenère cipher.

Plaintext:   c  a  f  e
Keyword:     B  A  D  B
Ciphertext:  ?  ?  ?  ?

Plaintext:  >c< a  f  e
Keyword:    >B< A  D  B
Ciphertext: >D< ?  ?  ?

Plaintext:   c >a< f  e
Keyword:     B >A< D  B
Ciphertext:  D >A< ?  ?

Plaintext:   c  a >f< e
Keyword:     B  A >D< B
Ciphertext:  D  A >C< ?

Plaintext:   c  a  f >e<
Keyword:     B  A  D >B<
Ciphertext:  D  A  C >F<

DACF!

How about decryption?

Plaintext:   ?  ?  ?  ?
Keyword:     B  A  D  B
Ciphertext:  D  A  C  F

Plaintext:  >c< ?  ?  ?
Keyword:    >B< A  D  B
Ciphertext: >D< A  C  F

Plaintext:   c >a< ?  ?
Keyword:     B >A< D  B
Ciphertext:  D >A< C  F

Plaintext:   c  a >f< ?
Keyword:     B  A >D< B
Ciphertext:  D  A >C< F

Plaintext:   c  a  f >e<
Keyword:     B  A  D >B<
Ciphertext:  D  A  C >F<

Kerckhoffs' principle

The security of a cipher
must be based on the chosen key,
not keeping the algorithm secret
(AKA "security through obscurity")

Symmetric cryptography

Same key is used for encryption and decryption.

Asymmetric cryptography

Different keys are used for
encryption and decryption.
Can also be used for "digital signatures".

Cryptographic hash functions

The same plaintext always result in
the same ciphertext, but the ciphertext
should not be reversable to plaintext
(AKA "One-way encryption").

Symmetric cryptography

Used primarily for protecting confidentiality
of information at rest and in transit.

Modern ciphers operators on bits,
not letters (typically using XOR operator).

Most symmetric ciphers are categorized
as block ciphers or stream ciphers.

Block ciphers split plaintext data into
parts of a fixed size and encrypts
each part/block separately.

Most commonly used for
"at rest" encryption.

DES is bad example and
AES is a good one.

Stream ciphers performs encryption of
each bit in a stream of plaintext.

Most commonly used for
"in transit" encryption.

RC4 is bad example and
ChaCha20 is a good one.

The US government entity
National Institute of
Standards and Technology
are heavily involved standardization
of cryptography.

They are responsible for
Federal Information
Processing Standards,
such as FIPS 46-3 (DES) and FIPS 197 (AES).

Modern cryptographic algorithms
are commonly audited/chosen through
international competitions.

Let's move forward!

Symmetric encryption tools

Let there be demos!

Simple file encryption

$ cat my_secrets.txt 
I didn't shoot the sheriff...

$ ccrypt --encrypt --key "hunter2" my_secrets.txt 
$ file my_secrets.txt.cpt 
my_secrets.txt.cpt: data

$ ccrypt --decrypt --key "hunter2" my_secrets.txt.cpt
$ cat my_secrets.txt 
I didn't shoot the sheriff...

LUKS

• Standard for encryption at the block layer
• "Full Disk Encryption" on Linux
• Supports multiple "keyslots"
• Typically used via the "cryptsetup" CLI utility

BitLocker

• Introduced in Windows Vista (2007)
• Not available in "Home" editions*
• Supports encryption of boot and data drives

VeraCrypt

• Fork of "TrueCrypt"
• FOSS and publicly audited
• Cross-platform/Multi OS support
• Supports encryption of boot*, data drives and "virtual devices"

XKCD: 538

KeePassXC

• Offline password/secrets manager
• FOSS and cross-platform
• Compatible with other KeePass variants*

Up1

• Web-based file hosting service
• FOSS!
• Try it at "Riseup Share"
• Performs cryptography tasks in the browser ("client-side")

share.riseup.net/#6nV4VONZwLr7nhBkd5gML

Bonus tip! ("fulhack")

Symmetric security

Good, bad and the ugly

We want our encryption to be...

• Fast to use, slow to break
• Safe against "known-plaintext" attacks
• Immune to frequency analysis

Keys are key

Symmetric ciphers depend on a key for
encryption and decryption.

Fixed size(s) in bits,
defined per algorithm.

Key != Password.

Typically created using a
Random Number Generator or
Key Derivation Function
(more about these later).

Example key sizes

• DES: 56 bits
• 3DES: 168 bits
• AES: 128, 192 or 256 bits
• ChaCha20: 128 or 256 bits

What do these numbers mean?!

A two bit key can be either
"00", "01", "10" or "11" (4 possibilities).

A four bit key can be either
"0000", "0001", "0011", "0111", "1111",
"1000", "1100", "1110", "1111", "1001"...
(16 possibilities).

A fifty-six bit key can be arranged in
72 057 594 037 927 936 possible ways!

Seventy-two quadrillion,
fifty-seven trillion,
five hundred and ninety-four billion,
thirty-seven million, nine hundred and
twenty-seven thousand and nine hundred
and thirty-six.

With one guess per second,
it would take 2283368000 years.

The difficulty of key size
doesn't scale linearly.

Sorry, humans -
that's waaay out of your league!

Is this a big number for computers?

Cracking DES

Got a gaming rig at home?
An Nvidia 4090 GPU can try
~six billion keys per second.

The ten-year old "crack.sh-system".
can try ~seven-and-a-half trillion
keys per second.

That's the whole key-space in
twenty-six hours! \o/

26 hours < 2283368000 years.

Size doesn't matter (that much)

Larger keys are nice,
but with diminishing returns
and performance penalties.

How much more secure is AES 256
compared to AES 128?

Design issues in algorithms and
faulty implementations are the
primary ways modern cryptography
is broken.

3DES keys are 168 bits, but in
practice only provides 112 bits.

But AES is fine right?
Isn't it MILITARY GRADE ENCRYPTION?

Let me introduce you to block cipher modes.

AES cipher modes

• ECB
• CBC
• PCBC
• CFB
• CCM
• GCM
• XTS

....

CBC

Oldie but goldie typically okay!

XTS

Most commonly used for
Full Disk Encryption.

GCM

Fast and integrity protected,
but tricky to implement from scratch.

Many block cipher modes exist.

Most are in practice okay - avoid ECB!

Typically require a randomly generated
Initialization Vector that
should not be lost or reused
(AKA "nonce").

Except for lab purposes,
don't roll your own crypto!

Reflections exercise

What we learned so far?

Answer the following questions

• What are your most important take-aways?
• Did you have any "Ahaaa!"-moments?
• Was anything unclear or were there specifics you didn't understand?

courses+crypto_010901@0x00.lt

Bonus task

Already finished all other labs/tasks?

Attach an additional (virtual) disk to
your lab system and utilize cryptsetup
to setup Full Disk Encryption
with keyslots for a password and a "key file".

Format volume as EXT4 and send lab notes to
courses+crypto_010902@0x00.lt

Cryptographic hashing

AKA "one-way encryption"

Before we dig into cryptographic hashing,
let's talk about check digits and checksums.

Check digits provide input error detection.

Used for credit card numbers, Bitcoin addresses, patient identifiers, social security numbers...

The Luhn algorithm is a common solution.

Checksums allows data integrity verification.

Detect if information/files have been corrupted during network transfer or disk storage.

The same input data should always result in the same output checksum.

CRCs are commonly utilized.

$ cksum /etc/passwd
1530034959 1930 /etc/passwd

$ echo "Polar bears are cool" | cksum
3234477472 21

$ echo "Polar bears are cool" | cksum
3234477472 21

$ echo "Polar beers are cool" | cksum
3688108819 21

The downsides

Different input values may produce the same output checksum.

Not likely a problem, unless someone actively tries to find collisions.

Used to attack data authenticity controls.

Cryptographic hashing to the rescue!

Cryptographic hash functions are like checksums,
but designed to never collide in practice.

Produces a digest as output,
more commonly called "hash".

Output shouldn't be predictable,
unless fully computed.

Output shouldn't help you guess
contents of input data.

The output digest will be the same size
regardless if input data is 1kB or 10TB.

$ echo "Polar bears are cool" | sha256sum
09c123f289f05677dbfa38dad697ae86ab2f3ef25c8935cfc8cd68a59f2f4d0a

$ echo "Polar beers are cool" | sha256sum
f170488bc43c691d3b9055567952d05d1cd43fbebd54c2098a0d5d7685d2eaa1

$ head --bytes 5G /dev/zero | sha256sum
7f06c62352aebd8125b2a1841e2b9e1ffcbed602f381c3dcb3200200e383d1d5

Use-cases for hashing

• Data integrity checking
• Password storage/validation
• Authentication
• Fingerprinting
• Pseudo-random number generators
• Append-only databases/ledgers
• Proof of Knowledge
• Proof of Work

....

Notable families

• MD: Historically common, now broken
• SHA: Standards specified by NIST
• BLAKE: Commonly used in KDFs

Like other cryptography methods, hashing algorithms have a best-before date.

Check out "SHAttered":

$ shasum shattered-1.pdf 
38762cf7f55934b34d179ae6a4c80cadccbb7f0a

$ shasum shattered-2.pdf 
38762cf7f55934b34d179ae6a4c80cadccbb7f0a

If you wanna learn more about collision techniques and play with them, have a look at:
github.com/corkami/collisions.

TL;DR

Avoid MD4, MD5 and SHA-1.

SHA-2 (AKA SHA256), SHA-3 (AKA Keccak)
and BLAKE* are fine!

Hashing for integrity validation

Running "shasum" to get file hashes - is that it?

Let's take a look at some example use-cases.

FIM

Background services continuously checking hashes of executables, configuration files, etc.

Commonly used as a detection mechanism for malicious/unapproved systems changes.

Wanna give it a try? Take a look at:

• Samhain
• osquery
• IMA

Runtime allow-listing

Let's take it one step further - block execution of binaries that doesn't match permitted hashes.

Enables enforcement of computer usage policies and several forms of malware.

Checkout Airlock Digital and
fapolicyd.

Software download mirrors

Lots of FOSS projects rely on third-party mirror sites for downloads as bandwidth is not free.

Mirrors may be compromised or run by a malicious actor that modifies executables.

Hashes can be published on a project's official website to mitigate the problem.

Supply-chain security

Most systems/code bases rely on software published by a vendor or FOSS project.

Remote modification of dependencies could lead malicious code being baked into the application.

Pinning using hashes is common solution:

$ docker pull hashicorp/vault:1.12.4@sha256:03d1[...]5cda

A small sample of how cryptographic hashing
can be utilized to protect data integrity.

Questions? :-)

Symmetric encryption exercise

Can you crack the cipher?

Vigenère cipher

Manually decrypt ciphertext "DACFDBBDEFEC"
using the key "BAD"

courses+crypto_011201@0x00.lt

Hashing for password storage

What happens when we login to a website?

1. Client submit their username and password
2. Server checks if the submitted password matches the one stored for the user

Okay, so the server must store all passwords.

Can't we just symmetrically encrypt them?

Server needs plaintext passwords
to enable comparison.

Encrypted data must be "unlocked",
which means that the key is typically
stored on disk or in memory.

Sounds scary.

Storing passwords using hashing

The same hash function input data should always result in the same output, right?

Wasn't a nick-name for hashing
"one-way encryption"?

Pseudo-code for password hashing

if (
sha256($submitted_password) ==
$stored_password_hash) {

	accept_login()

} else {
	deny_login()
}

Boom! Let's call it day, shall we?

Not quite.

Problems with basic password hashing

Users using the same password will have the generated same hash.

Hashes can be pre-calculated ("rainbow tables").

Problems with basic password hashing

Users using the same password will have the same hash.

Hashes can be pre-calculated ("rainbow tables").

Let me introduce you to salting!

Random data mixed into the password hashing.

Pseudo-code for password hashing

if (
sha256($stored_salt + $submitted_password) ==
$stored_password_hash) {

	accept_login()

} else {
	deny_login()
}

Salt should be...

• Quite random
• Unique per user
• Accessible to application in plaintext

Operating systems use it too

$ sudo head --lines 1 /etc/shadow

root:$y$j9T$P.lVRC/J.KNiBHMob7uli[...]

$ man shadow

Choosing the right hash function

Guessing the password that matches a hash
("hash cracking") should require lots of compute.

The same hash function can be used multiple times
("rounds") to increase cost.

Consider using a purpose built solution,
like Argon2 or
yescrypt.

Doesn't fully mitigate the risks of password theft.

An attacker with system access may be able to modify the application to log password input.

Client-side hashing

Effectively turns generated hash into a password.

Allows server to never gain access to plaintext password, minimizing consequences of breach.

Beware that the client-side code can be modified by a compromised server in web apps.

Password hashing lab

Lab description

Graded exercise to implement hashing of passwords in simple web application.

For detailed instructions, see:
"resources/labs/pwd_hash/README.md".

Remember the deadline and
lab report requirements.

Proof of Knowledge

An introduction of hashing for PoK

Why do we sometimes see
people tweet or toot out a hash?

$ echo "${SALT} Looptroop killed Palme" | shasum

f2f095c3b414335fdf98ed96f128e37705dca7ce

Why not just use symmetric encryption
and publish the key when time arrives?

Most cryptographically secure hashes
are fixed-length.

Knowledge of terabytes can be proven with
a short string that fits inside a toot/tweet/SMS.

Uses for authentication

Remote authentication without
sending password over network.

One-time/rolling passwords.

Pseudo-code for hash authentication

$challenge = get_auth_challenge($username)
$response = sha256($challenge + $password)

login($challenge, $response)

Rolling password (counter-based)

$counter = $counter + 1
$one_time_code = sha256($counter + $password)

login($username, $one_time_code)

Rolling password (time-based)

$time = get_current_minute()
$one_time_code = sha256($time + $password)

login($username, $one_time_code)

(somewhat similar to the
"Time-based One-time Password" standard,
used by applications like Google Authenticator)

Many other use-cases exist -
this is just an appetizer.

If you wanna play around
and got the time, check out
"resources/labs/extras/otp_auth/README.md".

Proof of Work

An introduction of hashing for PoW

What enables email spam,
and how could we solve it?

Anyone can send anyone a message
at (almost) zero cost.

Couldn't we just charge a tiny fee per message?

How would you even implement that?

Any other ways we could introduce cost?

Computations require processing.

Processing requires hardware and electricity.

Hardware and electricity ain't free!

Calculating a hash requires
quite many CPU cycles.

How can we prove that the user has
wasted processing power on hashing?

Let's steal a few tricks from
hash-based authentication!

Sender:
I got some email for you!

Receiver:
Stop right there! Before I accept your email,
I want you to provide a hash of some data
prefixed with "fiskburk" that ends with "ff".

Sender:
Okay - hold on a second... *crunching*...
If I hash "fiskburk24077-29047-32326"
I get a hash ending with "ff"!

Receiver:
I get the same result -
handover that email, will you?

Costly to find proof,
but cheap to very!*

resources/misc/pow.sh

#!/usr/bin/env bash

# Validate that at least two command line arguments are provided
if [[ -z "${2}" ]]; then
	echo "Usage: ${0} <PREFIX_SEED> <EXPECTED_SUFFIX>"
	exit 1
fi

PREFIX_SEED="${1}"
EXPECTED_SUFFIX="${2}"

# Loop until solution for PoW is found
time while true; do
	# Grab some random data to include in hash calculation
	INPUT_DATA="${RANDOM}-${RANDOM}-${RANDOM}"

	# Hash specified seed together with random input data, only include hash from output
	HASH="$(echo -n ${PREFIX_SEED} ${INPUT_DATA} | sha256sum | cut -d ' ' -f 1)"

	# If the suffix of the generated hash matches the specified suffix, challenge is solved
	if [[ "${HASH}" == *${EXPECTED_SUFFIX} ]]; then
		echo "${EXPECTED_SUFFIX}: sha256(${PREFIX_SEED} + ${INPUT_DATA}) == ${HASH}"
		# Stop loop once finished
		break
	fi
done

$ resources/misc/pow.sh
Usage: resources/misc/pow.sh <PREFIX_SEED> <EXPECTED_SUFFIX>

$ resources/misc/pow.sh "asdasdasdasd" "ff"

ff: sha256(asdasdasdasd + 16083-12281-837) == d60ee[...]3b13e1ff
real	0m0.138s

$ resources/misc/pow.sh "asdasdasdasd" "fff"

fff: sha256(asdasdasdasd + 22132-31048-7135) == 3be[...]37371fff
real	0m22.333s

$ resources/misc/pow.sh "asdasdasdasd" "ffff"

ffff: sha256(asdasdasdasd + 19378-5998-4075) == fb8[...]370ffff
real	1m23.770s

Other use-cases

• Online rate-limiting
• Alternative to captcha
• Anti-scraping
• "Mining" in cryptocurrencies

Whatever you can imagine!

Done with your other tasks
and wanna try implementing PoW?

Modify the client and server
from "pwd_hash" lab to utilize
PoW instead of/in addition to
password-based authentication.

courses+crypto_011601@0x00.lt

Reflections exercise

What we learned so far?

Answer the following questions

• What are your most important take-aways?
• Did you have any "Ahaaa!"-moments?
• Was anything unclear or were there specifics you didn't understand?

courses+crypto_011701@0x00.lt

Course recap

Basics, symmetric crypto and hashing

Cryptography helps us ensure
confidentiality, authenticity and integrity
of information.

Steganography is a related practice in which information is hidden/obscured.

These have historically been used in unison.

Symmetric ciphers

AES and ChaCha20 are good options.

Stay away from (3)DES and RC4.

Key Derivation Functions are
used to generate fixed-size keys from passwords.

AES and other block-ciphers
supports several different
"cipher modes".

The "ECB" mode is generally considered insecure.

In addition to a key and plain-/cipher-text, most
modes require an "initialization vector"
for secure operations.

Cryptographic hash functions are like checksums,
but designed to never collide in practice
(different inputs shouldn't produce same output).

A digest (AKA "hash") shouldn't help an
attacker guess the input/"plain text" data.

The output hash will be the same size regardless
if input data is 1kB or 10TB.

The "Secure Hash Algorithm"-family
of hash functions are standardized by NIST.

SHA-2 (AKA "SHA256") is still widely used.
SHA-3 (AKA "Keccak") is recommended
for new sensitive applications.

Avoid SHA-1 and especially MD* algorithms
as they suffer from known security flaws.

Hashes are commonly used for
ensuring the integrity of data
(detect manipulation).

Some examples are
File Integrity Monitoring systems
and "software allow-listing" applications.

Password hashing is used to avoid
storing passwords in plaintext.

Users using the same password will
have the generated same hash.

Hashes can be pre-calculated
("rainbow tables").

To mitigate these issues, passwords are salted
(mixed with other data) before being hashed.

In order to avoid handling users "real passwords",
"client-side hashing" may be utilized in unison.

Hashes can be used for
Proof of Knowledge.

Provide proof that you know
something without disclosing it.

Commonly used in authentication protocols,
similar to "Time-based One-time Password".

Hashes can be used for
Proof of Work.

Perform computationally-expensive
hashing to find a digest containing
some peer-specified data/pattern.

Costly to produce, cheap to verify.

Enables things like bot/spam protection,
rate-limiting and cryptocurrencies.

Challenge

Find some input data with the prefix
"quite_r4ndom" that produces a
hex digest ending with "4e".

Attempts

hash(quite_r4ndom-abc123) == 3e64[...]ca
hash(quite_r4ndom-abc124) == 910c[...]1c
[...]
hash(quite_r4ndom-abc982) == aad6[...]4e

Result

859 rounds of hashing to solve challenge,
1 round to verify it.

Cryptography tools won't hold
their promises forever.

There are always "best-before" dates.

Asymmetric cryptography

A somewhat gentle introduction

Also known as "public-key cryptography".

Spooks and researches have been
using it since the late 70s.

Requires usage of electronic computers
(sorry, humans!).

This is not a math course.

We won't cover how the
algorithms actually work
under the hood.

Neither do we need to,
thankfully!

A key pair consists of a
private key and a public key.

Holder of the private key
can decrypt and sign/authenticate data.

The corresponding public key
can be used to encrypt data and
verify authenticity of signed data.

The ability to sign/decrypt data
can be used for authentication
(prove "ownership" of private key).

RSA is a commonly
used asymmetric algorithm.

Created by Rivest, Shamir and Adleman.

Not to be confused with
the company "RSA Security".

Patented in 1983,
freely usable since 2000.

Algorithm/Implementation guidance described
in Public-Key Cryptography Standards #1.

Typically key size is between 512 bit (weak)
and 8192 bit (overkill).

Wait a second, those are much
larger than the keys used
for symmetric algorithms!

Unlike when used by symmetric ciphers,
not all combinations of bits are
possible to use as keys.

To get a better idea, we can check out
NIST's table of "security levels".

TL;DR: 2048 bits OK-ish, >=3072 recommended.

Digital Signature Algorithm.

Standardized by NIST in 1994,
usable without license trouble.

Focused on signatures/authentication,
not encryption.

Several design flaws and
insufficient key size - avoid it!

Solutions based on
Elliptic-Curve Cryptography
are steadily replacing RSA.

ECDSA, for example.

It's faster, requires smaller keys and
is generally considered easier
to correctly/safely implement.

RSA still has better
software/hardware support.

$ time ssh-keygen -q -N '' \
  -t rsa -f /tmp/key_rsa

real	0m1.022s

$ time ssh-keygen -q -N '' \
  -t ed25519 -f /tmp/key_ed

real	0m0.008s

$ cat /tmp/key_rsa.pub | cut -d ' ' -f 2 
AAAAB3NzaC1yc2EAAAADAQABAAABgQC0KDu1jlpyMbqGNAU5NEPmN8LXNeybJHRHiLHg
aMRVTsmOsQzBlQhC8GAxHCvrQDpfqDVRtp0eepJtYTHuu7RZPOvHEMH7U35/xP/jRUMM
Z81k1DAQ6LoezQKj7bKJuvJo3P/JTdrWwMVejwNAXL4IIDce3G/TQx6HQlF3YmW8hCFZ
j30frRqVPF/KT9Zgh4IyeEdWnlAP0bLA9x/lvsZuTDIGy3D89aPW41z0jQbcVVFips1v
QGWrSQZYGgBeX8TUqTcg0Zuu9K19MZx6Jdnu+Qdxukk+omkDmSODvRQ6U/LGY3Cx8NEY
fZZfeXo+TVmKHUQwNntuvpW074UqVedOfrrN8lsJmnjjPivXG2MHVF6fDAYe0WubPUEv
ZZIzyTZFEOpt9tPeOg6s38mhF/cgr17p8lapMHx4HFn0ljlgejgKNzm5rI4AqNWjgj1+
HvcX3BkhU91xDiTV5sAIqAPddk3ePsiFZiBpvzrlQagiY+VNf/VJq8x4vN98aTtGMqc=

$ cat /tmp/key_ed.pub | cut -d ' ' -f 2 
AAAAC3NzaC1lZDI1NTE5AAAAIFmgY7uVLZqx/tOLPJ22JBi7TAJwmmClu66+mb2sOfUA

Several different "curves" can be utilized.
(~think different algorithms).

Common examples are
NIST P-256/P-384 and
Curve25519.

For some (biased) guidance,
checkout the "SafeCurves" project.

Asymmetric cryptography
is relatively slow.

Most often combined with
hashing (digital signatures) and
symmetric cryptography (key exchange).

Curious about how these type of
algorithms actually work?
Check out "KidRSA".

Certificates and trust models

Asymmetric cryptography enables us to
share secrets and sign/validate data
without a shared secret key.

But how do we get hold of the
public key of our peer?

(both other humans and network services)

$ ssh 141.95.102.166

The authenticity of host '141.95.102.166 (141.95.102.166)' can't be established.
ED25519 key fingerprint is SHA256:wzzjNa+3VIhoxAEc1W9KfWzW8APaB3O6OSBFki66jEU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

$ for KEY in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -l -f "${KEY}"; done

1024 SHA256:IrBaPa6k+uPe1SMeshWaX8SMomgCxWthfjxtR0jjBfY root@w2 (DSA)
256 SHA256:VBBjYJyshoJU1x63APDVjTyzZu8TG4XUGGu1HxMEXSM root@w2 (ECDSA)
256 SHA256:wzzjNa+3VIhoxAEc1W9KfWzW8APaB3O6OSBFki66jEU root@w2 (ED25519)
3072 SHA256:4CiF9f8vMP2a8cGG5OjW0lmH1xWMXwgwjx9oUvPzYbI root@w2 (RSA

What does the "known_hosts" file
created by our SSH client contain?

Hostnames/IP addresses ("server identities")
and "key fingerprints" (hash of public key).

(the "server identities" are often hashed
to minimize information disclosure if
file is stolen/leaked)

We can't go around and ask everyone/everything
on the Internet what their public key is.

Mayhaps your bank could write it on a sign
in their lobby, but what about
a random web shop?

There must be a better way...

Common "trust models"

• None ("YOLO!")
• Trust On First Use (TOFU)
• Certificates and Certificate Authorities (CA)
• Web of Trust (WoT)

TOFU

$ ssh -o StrictHostKeyChecking=accept-new 141.95.102.166

Common "trust models"

• None ("YOLO!")
• Trust On First Use (TOFU)
• Certificates and Certificate Authorities (CA)
• Web of Trust (WoT)

What are "certificates"?

sign(public key + metadata)

Only requires us to know the
signer's public key in advance.

Examples of metadata:

• Identity (hostname, email, etc)
• Portrait photo
• Expiry date

Common standards

• X.509
• SSH certificates
• OpenPGP

Certificate Authorities

Trust store contains public keys which are
blessed to sign other certificates.

Web of Trust

Any key can sign others certificates,
users can choose how to "weight" keys
and how much risk they are willing to take.

We'll re-visit this topic and
take a deeper look at how X.509
utilize certificate authorities
to establish trust.

Asymmetric cryptography

A somewhat quick recap

Symmetric

Same key is used for encryption and decryption.

Asymmetric

Different keys are used for encryption and decryption.

An asymmetric key pair consists of a
public key and a private key.

The private key can be used by
the key holder to decrypt and
digitally sign data.

The public key can be used by
anyone to encrypt and
verify signed data.

The most common solutions are RSA and
those based on Elliptic-Curve Cryptography.

RSA keys bigger than 2048 bits are
usually considered acceptable,
but NIST recommends 3072.

ECC is more resource efficient and
easier to correctly/safely implement
than RSA - thereby replacing it.

Several different curves are available for ECC.

Common examples are
NIST P-256/P-384 and Curve25519.

For guidance, checkout the "SafeCurves" project.

A certificate (typically) contains
a public key and metadata.

Examples of metadata are expiry time
and "identities" tied to the key,
such as an email address or a DNS hostname.

They are cryptographically signed
by one or more third-parties,
depending on trust model.

Any questions? :-)

Tool demonstration: age

Lean and mean file encryption

What is "age"?

• FOSS tool (and format) for symmetric and asymmetric file encryption
• Fast and modern (~secure)
• Compatible with (some) SSH keys
• Support for key storage on hardware token

Generate key pair

$ age-keygen | tee my_private.key

AGE-SECRET-KEY-1MQ5U9HTKKAP[...]Y92RTHKH7ASQ5LVL2Q

$ age-keygen -y my_private.key | tee my_public.key

age14z423we7r3ze5rkjy4[...]uwfy9pxxvmnxy2yrq6rr74p

Let's encrypt some data

$ cat secret.txt

I shot the sheriff :-/

$ cat secret.txt | \
	age --encrypt --recipients-file my_public.key \
	> secret.txt.age

...and decrypt it

$ cat secret.txt.age | \
	age --decrypt --identity my_private.key \
	> secret.txt

$ cat secret.txt

I shot the sheriff :-/

Encrypt to multiple keys

$ cat alice.key.pub bob.key.pub | tee friends.keys

age1uw4mjkc9ma5tvs5[...]2ywm69kru2rspacst0jdnczqacx2s5
age1eut64dvujqfmw6e[...]uuddd7hdxsrw3csu3dzh6amswhyr3v

$ cat secret.txt | \
	age --encrypt --recipients-file friends.keys \
	> secret.txt.age

Generate / store key on YubiKey

$ age-plugin-yubikey \
	--generate \
	--pin-policy never \
	--touch-policy always \
	> my_yubikey.plugin

[...]

! Please touch the YubiKey
Recipient: age1yubikey1q0[...]q6

Encrypt and decrypt data using YubiKey

$ age-plugin-yubikey \
	--identity --slot $SLOT > my_yubikey.pub

$ cat secret.txt | \
	age --encrypt --recipients-file my_yubikey.pub \
	> secret.txt.age

$ cat secret.txt.age | \
	age --decrypt --identity my_yubikey.plugin \
	> secret.txt
	
! Please touch the YubiKey

Wanna give it a spin?

Try replacing tar/7-Zip in the
"sym_crypt" lab backup script with age!

Take it a step further and use your
YubiKey for storing the private key.

courses+crypto_012201@0x00.lt

OpenPGP basics

Pretty Good Privacy since 1991

What is PGP?

Tool suite for asymmetric cryptography
developed by Phil Zimmermann
in the early 90s.

"OpenPGP" acts as the umbrella for
attempts to formally standardize PGP.

Common use-cases for PGP

Securing message-based communication
methods, such as E2E for email.

File encryption.

Software authenticity validation on Linux.

Used for package metadata signing

$ cat /etc/apt/sources.list.d/github-cli.list 

deb [signed-by=/etc/keys/github.pub] https://cli.github.com/packages stable main

OpenPGP certificates are signed ("certified")
by the "key holder" and potentially others.

Pioneered the "Web of Trust model for
identity/certificate validation.

Implementations

• GnuPG: Swiss army knife, AKA "GPG"
• Sequoia: Modern CLI tools and Rust libraries
• GopenPGP: PGP in your Go applications
• OpenPGP.js: Client- and server-side library

'Nuff talk, more demos.

Let me introduce you to "sq"!

$ sq --help

sq 0.25.0 (sequoia-openpgp 1.7.0)
A command-line frontend for Sequoia,
an implementation of OpenPGP
[...]

Key / certificate generation

$ sq key generate \
	--userid 'Test Labsson <test@example.com>' \
	--export test.private \
	--expires-in 5y 

$ sq key extract-cert test.private --output test.cert 

Basic file encryption

$ cat todo.md 

## My TODO list
- [X]: Learn about PGP
- [ ]: Conquer the world

$ cat todo.md | sq encrypt \
	--recipient-cert test.cert \
	> todo.md.pgp

Basic file decryption

$ cat todo.md.pgp | \
	sq decrypt \
	--recipient-key test.private 

Encrypted using AES with 256-bit key
Compressed using ZIP

## My TODO list
- [X]: Learn about PGP
- [ ]: Conquer the world

Digitally signing a message

$ cat proclamation.txt

I hereby promise to never put
meatballs in my nose again!

$ cat proclamation.txt | \
	sq sign \
	--cleartext-signature \
	--signer-key test.private \
	> proclamation.txt.pgp

Digitally signed message

$ cat proclamation.txt.pgp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I hereby promise to never put
meatballs in my nose again!

-----BEGIN PGP SIGNATURE-----

wr0EARYKAG8FgmQX9m0JELNUBDJO1RxQAA
LnNlcXVvaWEtcGdwLm9yZzku8htwo/JCHZ
FiEEo62bZCb5bbX3wxfDs1QEOm7UAAHJnA
EY3QZRMCQZ8S5CwDUgEAqtSrWEvEa[...]
-----END PGP SIGNATURE-----

Verifying signed message

$ cat proclamation.txt.pgp | \
	sq verify \
	--signer-cert test.cert 

Good signature from B354043A692893B5
1 good signature.

I hereby promise to never put
meatballs in my nose again!

Let's create some more test keys

$ for NAME in alice bob charlie; do 
	sq key generate \
		--userid "${NAME} <${NAME}@example.com>" \
		--expires-in 5y --export "${NAME}.private"

	sq key extract-cert \
		"${NAME}.private" \
		--output "${NAME}.cert"
done

Multi-signing a message

$ cat the_truth.txt

Oceania was at war with Eastasia

$ cat the_truth.txt | \
	sq sign \
	--signer-key alice.private \
	> the_truth.txt.pgp

$ cat the_truth.txt.pgp | \
	sq sign \
	--signer-key bob.private \
	--append | \
	sponge the_truth.txt.pgp

Verify multi-signed message

$ cat the_truth.txt.pgp | \
	sq verify \
	--signer-cert alice.cert \
	--signer-cert bob.cert \
	--signer-cert charlie.cert

Good signature from F89E9C4294F51777
Good signature from 5CF0C96FD9C6DC05
2 good signatures.

Oceania was at war with Eastasia

Verify multi-signed message

$ cat the_truth.txt.pgp | \
	sq verify \
	--signer-cert alice.cert \
	--signer-cert bob.cert \
	--signer-cert charlie.cert \
	--signatures 3

Good signature from F89E9C4294F51777
Good signature from 5CF0C96FD9C6DC05
2 good signatures.
Error: Verification failed

Certify third-party key

$ sq certify \
	alice.private \
	charlie.cert \
	'charlie <charlie@example.com>' | \
	sponge charlie.cert

$ sq certify \
	bob.private \
	charlie.cert \
	'charlie <charlie@example.com>' \
	--amount 60 | \
	sponge charlie.cert

Peaking at the certificate

$ sq inspect --certifications charlie.cert 

charlie.cert: OpenPGP Certificate.

Fingerprint: 63887435C2B865DBBA537AA0BC80AE1A45B83D65
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
[...]
UserID: charlie <charlie@example.com>
Alleged certifier: D36E658BA221819AD35F80484047E2EF12270FAD
Alleged certifier: 06FE1C00440DD227E7EAE81B1B2D8E573AD890CF
[...]

Create a keyring

$ sq keyring join --output alice.keyring *.cert

$ sq keyring list alice.keyring

0. 06FE1C0[...]573AD890CF alice@example.com
1. D36E658[...]EF12270FAD bob@example.com
2. 6388743[...]1A45B83D65 charlie@example.com

But wait a minute, how do I know
that a key for test@example.com
belongs to the real Test Labsson?

Strategies for key verification

• Praying / hoping for the best
• Key signing parties
• Web of Trust
• DOIP / Keyoxide

Just for cool cats/terminal dwellers?

Let me introduce you to Gpg4win.

Gpg4win

• GnuPG: Where the magic happens
• Kleopatra: GUI for management/encryption
• GpgOL: Integration for Outlook and Office
• GpgEX: Add-on for file explorer

FOSS with professional support available.

Hope this piqued your interest.

All tools (except the original PGP) described
are freely available for you to play with.

Grab a few classmates and
try creating a "Web of Trust".

X.509 basics

A somewhat gentle introduction

What is "X.509"?

Standard for cryptographic certificates.

When people talk about "PKI",
they typically talk about X.509.

Used for encrypted/signed email ("S/MIME"),
securing key exchange in network protocols,
validating software authenticity and similar.

CSR

Certificate Signing Request, contains public key
and metadata to be included in certificate signing.

CA

Certificate Authority, key pair used to sign
other certificates after some validation.

Truststore

File containing public keys for trusted CAs,
typically shipped with OS/applications.

Root CA

Included in truststores, typically only used
for signing intermediate CAs. Very sensitive.

Intermediate CA

CA whose certificate is signed by another CA,
commonly used to sign client/server CSRs.

CRL

Certificate Revocation List, signed file listing
certificates which should no longer be trusted.

OCSP

Online Certificate Status Protocol,
like CRL but provided as a network service.

FOSS tools

• OpenSSL CLI: Toolbox for all-things X.509
• Easy-RSA: Handy wrapper for OpenSSL CA
• CFSSL: Server/CLI tools for setting up a CA

We'll use CFSSL CLI tools
in the following demos.

Try to keep things simple,
only rely on a root CA
(no intermediate CA).

Generate base configuration file

$ mkdir my_ca && cd my_ca
$ cfssl print-defaults config > config.json

[...]
"profiles": {
  "server": {
    "expiry": "2160h",
    "usages": [
      "signing",
      "key encipherment",
      "server auth"
    ]
  }
}
[...]

ca-csr.json

{
  "CN": "My Lab Certificate Authority",
  "key": {"algo": "ecdsa", "size": 256},
  "ca": {"expiry": "26298h"},
  "names": [
    {
      "C": "SE",
      "L": "Stockholm",
      "O": "Department Of Labs"
    }
  ]
}

Generate CA certificate / key

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca

2023/03/03 13:37:42 [INFO] generating a new CA key and certificate from CSR
2023/03/03 13:37:42 [INFO] generate received request
2023/03/03 13:37:42 [INFO] received CSR
2023/03/03 13:37:42 [INFO] generating key: ecdsa-256
2023/03/03 13:37:42 [INFO] encoded CSR
2023/03/03 13:37:42 [INFO] signed certificate with serial number 23[...]301

$ ls *.csr *.pem

ca.csr ca.pem ca-key.pem

my_server-csr.json

{
  "CN": "my-server.example.test",
  "hosts": [
    "my-server.example.test",
    "localhost"],
  "names": [
    {
      "C": "SE",
      "L": "Stockholm",
      "O": "Department Of Labs",
      "OU": "Server Management Team"
    }
  ]
}

Generate server certificate / key

$ cfssl gencert \
	-config config.json -profile server \
	-ca ca.pem -ca-key ca-key.pem \
	my_server-csr.json | cfssljson -bare my_server

[...]
2023/03/03 13:38:42 [INFO] signed certificate
with serial number 23[...]302

$ ls *.csr *.pem

my_server.csr my_server.pem my_server-key.pem

Quite neat! But now what?

Let's take the certificate for a
spin using the Caddy web server.

Configure and restart web server

$ ls /etc/caddy/
Caddyfile  my_server-key.pem  my_server.pem

$ cat /etc/caddy/Caddyfile 

https://localhost {
  tls /etc/caddy/my_server.pem /etc/caddy/my_server-key.pem
  respond "Here comes all the juicy secrets!"
}

$ sudo systemctl restart caddy.service

Let's do it programmatically!

#!/usr/bin/env python3
import requests

response = requests.get(
    'https://localhost',
    verify='ca.pem'
)

print(response.text)

$ ./app.py

Here comes all the juicy secrets!

X.509 for software signing

Digging into certificates

$ openssl x509 -in my_server.pem -text

Version: 3 (0x2)
Serial Number:
  63:f2:19:d6:bd:[...]:d7:01:fe:c6
Signature Algorithm: ecdsa-with-SHA256
Issuer:
  C = SE, L = Stockholm,
  O = Department Of Labs,
  CN = My Lab Certificate Authority
Validity
    Not Before: Mar 19 17:02:00 2023 GMT
    Not After : Jun 17 17:02:00 2023 GMT
[...]
X509v3 extensions:
    X509v3 Key Usage: critical
        Digital Signature, Key Encipherment
    X509v3 Basic Constraints: critical
        CA:FALSE
    X509v3 Subject Alternative Name: 
        DNS:my-server.example.test, DNS:localhost
[...]

Transport Layer Security

An introduction to SSL / TLS

Network traffic may be intercepted.

Malicious actors can manipulate and
spy on sensitive communication.

How can we protect it?

Secure Sockets Layer was
introduced by Netscape in the late 90s
to enable e-commerce/"exciting things".

Wraps existing clear text TCP protocols,
like HTTP and SMTP, with a layer of encryption.

Replaced by Transport Layer Security,
properly standardized by the IETF.

Protects confidentiality and integrity
of network communication at the
OSI model's "presentation layer"
("application layer" in TCP/IP).

TLS typically use...

• X.509 for "identity validation"
• Asymmetric cryptography for key exchange
• Symmetric encryption for confidentiality
• Hashing for integrity protection

Different combinations algorithms
are known as "cipher suites".

TLS 1.2 supports 37 different ones,
TLS 1.3 merely 5.

Example cipher suites

TLS_RSA_EXPORT_WITH_RC4_40_MD5

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

TLS_GOSTR341112_256_WITH_NULL_GOSTR3411

Configuring a web server

$ cat /etc/caddy/Caddyfile 

https://localhost {
  tls /etc/caddy/my_server.pem /etc/caddy/my_server-key.pem
  respond "Let me tell you a secret, friend!"
}

Configuring a client

#!/usr/bin/env python3
import requests

response = requests.get('https://localhost', verify='ca.pem')

print(response.text)

What is "mTLS"?

In TLS, both connection peers
(client and server) may
present certificates.

We call this "mutual TLS", AKA
"client-certificate authentication".

Can be used as replacement
for username + password login,
application can grab user identifier
from the certificate's common name.

(similar to "key authentication" in SSH)

my_ca/config.json

[...]
"profiles": {
  "server": {
    "expiry": "2160h",
    "usages": [
      "signing",
      "key encipherment",
      "server auth"
    ]
  },
  "client": {
    "expiry": "8760h",
    "usages": [
      "signing",
      "key encipherment",
      "client auth"
    ]
  }
}
[...]

Reconfigure Caddy for mTLS

$ cat /etc/caddy/Caddyfile 

https://localhost {
  tls /etc/caddy/my_server.pem /etc/caddy/my_server-key.pem {
    client_auth {
      mode require_and_verify
      trusted_ca_cert_file /etc/caddy/ca.pem
    }
  }
  respond "Let me tell you a secret, {tls_client_subject}!"
}

Access denied!

#!/usr/bin/env python3
import requests

response = requests.get(
    'https://localhost',
    verify='ca.pem'
)

print(response.text)

$ ./app.py

[...]
SSL: SSLV3_ALERT_BAD_CERTIFICATE

Configure client certificate

#!/usr/bin/env python3
import requests

response = requests.get(
    'https://localhost',
    verify='ca.pem',
    cert=(
        'my_client.pem',
        'my_client-key.pem'
    )
)

print(response.text)

Access granted!

$ ./app.py

Let me tell you a secret,
CN=my_client,OU=User Support Team,
O=Department Of Labs,L=Stockholm,C=SE!

Unfortunately, browsers typically don't
support directly importing PEM files
with the client certificate/key.

We need to package them into a
PKCS #12 archive first.

$ openssl pkcs12 \
	-in my_client.pem \
	-inkey my_client-key.pem \
	-export -out my_client.p12

Wrapping up

TLS provides a relatively simple method
for wrapping clear text protocols
in a "layer of encryption" and
enables mutual authentication.

Supports different combinations of
algorithms using "cipher suites".

Several different versions exist,
avoid SSL and TLS version <1.2.

Designed for TCP, use DTLS for UDP.

X.509 / TLS lab

Lab description

Graded exercise to setup a X.509 CA
and protect a web server using mTLS.

For detailed instructions, see:
"resources/labs/x509_tls/README.md".

X.509 / TLS recap

X.509 is a standard for
cryptographic certificates ("PKI").

These certificates contain a public key
and metadata, such as expiry time
and "identity information" like a
hostname or email address.

Relies on certificate authorities
to sign/certify certificates.

Certificates for root CAs are typically included
in OS/application trust stores.

Used for encrypted/signed email ("S/MIME"),
securing key exchange in network protocols,
validating software authenticity and similar.

TLS is used to secure
network communication
between client and server
applications.

Replaces the outdated SSL protocol,
an acronym that has become a synonym.

Commonly used to wrap/tunnel
cleartext protocols like
HTTP(S) and SMTP(S).

Mutual TLS ("mTLS") is used to
authenticate both peers in
a session (client and server).

TLS typically use...

• X.509 for "identity validation"
• Asymmetric encryption for key exchange
• Symmetric encryption for confidentiality
• Hashing for integrity protection

Different combinations of these
(symmetric, asymmetric and hashing algorithms)
are known as "cipher suites".

Network encryption tools

Working one to seven

Network traffic can be intercepted
anywhere between your phone in a café
and TikTok's fancy data center in Shenzhen.

Cryptography is used to protect confidentiality and integrity of communication.

We've talked about TLS, let's have a look at the other network layers.

OSI model recap

1. Physical layer
2. Data link layer
3. Network layer
4. Transport layer
5. Session layer
6. Presentation layer
7. Application layer

Common vocabulary, not reality.

Alternative: "TCP/IP model"

1. Application layer
2. Transport layer
3. Internet layer
4. Data link layer
5. Physical layer

OCI model still acts as Interlingua.

"L1": Signal level encryption

Used to protect high-bandwidth/legacy links.

"Transparent encryption" provided by pricey HW.

Easy to implement, suitable for legacy networks and compliance checkboxes.

"L2": MACsec / IEEE 802.1AE

Open standard extending Ethernet with encryption.

Supported in fancy switches at line-rate.

Uses AES-GCM for confidentiality and integrity.

"L3": IPsec

Family of open standards to provide a
secure version of IP.

Supported by most OSes and network appliances.

Act in "host-to-host" or "routed" mode.

Quiet a mess with gazillion different options for
encryption, integrity checking and authentication.

"L4-L6": QUIC

Performant alternative to TCP initially developed by Google.

Uses UDP and a subset of TLS version 1.3.

~Used by HTTP version 3.