Interview 2 - Cybersecurity Teacher

Thank you for having me. I am especially passionate about Artificial Intelligence, data, and cybersecurity, and I am happy to share my background and my teaching experience with you today.

1. Yourself

What I say to the jury

My name is Haythem Rehouma.

I live in Montreal, Canada.

I am originally from Tunisia, and I am also a Canadian citizen.

I have been living in Canada for 13 years.

2. Your Experience

What I say to the jury

My main fields are AI, programming, cybersecurity, and cloud computing.

I have more than 15 years of experience in teaching and engineering.

Today I teach in several colleges in Montreal — cybersecurity at Collège de Maisonneuve, and AI at Collège Bois-de-Boulogne.

I also teach at university, at ÉTS — a top engineering school — where I teach computer vision and Java.

So I have a multidisciplinary profile, and a strong base in data, artificial intelligence, and security.

AI Ecosystem Reinforcement Learning Unsupervised Learning Computer Vision Protocols & Services in Security Applied Cybersecurity Java Programming

Detailed notes (full explanation)2.1My main fields are artificial intelligence, programming, cybersecurity, cloud computing, and data engineering.
2I have over 15 years of experience in both teaching and engineering.
3Currently, I am teaching in several CEGEPs in Montreal — a CEGEP is a Quebec college, between high school and university. For example, I teach cybersecurity at Collège de Maisonneuve and artificial intelligence at Collège Bois-de-Boulogne.
4I am also teaching at university — at ÉTS (École de technologie supérieure), one of the most famous engineering schools in Quebec, where I teach computer vision and Java.
7In Applied Cybersecurity, students do hands-on practice — so I can say that I have a multidisciplinary profile.
8My background as a Telecommunications Engineer and a Master in Communication Systems gives me a strong base in networks and security.

7. Cybersecurity — My Main Strength

What I say to the jury

I teach cybersecurity at Collège de Maisonneuve — both defensive and offensive security.

In defensive security, I teach how to protect systems, secure Windows servers, and control access.

In offensive security, I teach how attacks work — so students learn to think like an attacker to defend better.

So I combine real engineering practice with strong teaching — exactly what this position needs.

Concrete topics I teach:

Authentication: Kerberos & NTLM Encryption: EFS & BitLocker Windows Advanced Firewall Access Control & FSRM Failover Clustering Load Balancing (NLB, Keepalived / LVS) High Availability

5. Artificial Intelligence

What I teach (Bois-de-Boulogne)

I also teach Artificial Intelligence at Collège Bois-de-Boulogne.

I teach Reinforcement Learning.

The agent learns from rewards.

We use the Bellman equation to find the best actions.

I teach Supervised and Unsupervised Learning.

In supervised, we have labels — like KNN, SVM, decision trees, and random forests.

In unsupervised, there are no labels. The model finds patterns alone — like clustering (K-means, DBSCAN, hierarchical) and PCA.

I also teach data cleaning and EDA (exploratory data analysis).

I am on the program renewal committee at Bois-de-Boulogne.

It is a leader CEGEP in AI. I help update the AI program.

My recent research

My recent research is on Multimodal AI.

I work on fall detection for elderly people at night.

I use two sensors: a camera and a motion sensor (IMU).

IMU = Inertial Measurement Unit. It has two sensors:

• accelerometer — measures linear acceleration on 3 axes (x, y, z), in g.

• gyroscope — measures rotation (angular velocity) on 3 axes, in degrees per second.

Together that is 6-axis motion data — perfect to detect a fall.

For the camera, I use a Transformer to analyse the body pose.

For the motion, I use an unsupervised LSTM autoencoder.

LSTM = Long Short-Term Memory — a neural network that learns from sequences over time.

Then I combine the two with late fusion: I merge the two decisions at the end.

Late fusion is cheaper than early fusion, and more robust.

The results are strong: a 97% F1-score, and only 3.6% false alarms.

It runs in real time on a normal CPU, even in the dark.

This work is published in Sensors (MDPI), 2025.

And I have a new paper coming soon, with my colleague Dr. Mounir Boukadoum. We will submit it in the next days to IEEE ICM 2026.

In this new paper, we study a simple question: does the place of the camera and the sensor change the quality of the fall detection?

And the answer is yes. Where you put the camera, and where the person wears the sensor, can make the system much more, or less, accurate.

Topics I teach & research:

Reinforcement Learning Bellman equation Rewards & policy Supervised Learning Unsupervised Learning Clustering Data cleaning EDA Multimodal AI Late fusion Fall detection

More details (if asked)

1In Reinforcement Learning, the agent acts, gets a reward, and learns a policy. The Bellman equation links the value of a state to the next states.

2In Unsupervised Learning, there are no labels — the model groups the data by itself (clustering, structure discovery).

3On the program renewal committee, I help modernise the AI courses and keep the program up to date.

4In my multimodal fall-detection work, late fusion combines the decisions of each modality at the end. It is lighter and less expensive than early fusion, which mixes all the raw signals from the start.

Fall-detection paper — architecture & results (if asked)

Rehouma & Boukadoum, “Fall Detection by Deep Learning-Based Bimodal Movement and Pose Sensing with Late Fusion”, Sensors 2025, 25(19), 6035 (MDPI).

Bimodal IMU-RGB fall detection pipeline with decision-level late fusion

1Vision stream: RGB video (30 fps) → BlazePose (33 2D landmarks) → Transformer → fall probability, after a 1-second vote.

2IMU stream: motion signal (50 Hz) → LSTM autoencoder (unsupervised) → abnormality score (reconstruction error vs a threshold τ).

3Decision-level fusion: FALL only if both scores pass the threshold (α = 0.70); if only one passes → LOW-CONFIDENCE; else NORMAL.

4Results: F1 = 97.3%, false-positive rate = 3.6% (vs 11.3% IMU-only and 8.9% vision-only). AUC = 0.989.

5Works at night (under 5 lux), in real time (~20 fps) on a CPU only — no GPU. Plus few-shot personalization for new users.

3. Education & Diplomas

What I say to the jury

I hold degrees from three countries.

From Tunisia, I have a telecommunications engineering degree and a Master's degree.

From Canada, I earned a second Master's in Artificial Intelligence and a PhD.

I also hold a certificate in Artificial Intelligence from San Diego, in the United States.

And I am industry-certified in cloud and DevOps — AWS and Kubernetes.

I hold:

2 diplomas from Tunisia — Telecommunications engineering diploma + a Master's degree.
2 diplomas from Canada — another Master's degree in AI + a Ph.D.
1 diploma from the United States — a certificate in Artificial Intelligence from San Diego.

I am also industry-certified in cloud and DevOps:

AWS Certified DevOps Engineer — cloud automation, CI/CD, and deployment.
CKA — Certified Kubernetes Administrator — container orchestration and infrastructure.

More background — click to open if asked:

▸ My 2011 Master's thesis in Tunisia (if asked)

Université de Tunis El Manar — ENIT (National Engineering School of Tunis) · Master in Telecommunications · defended July 2011.
Title: “Study of a figure-eight microstructured-fiber laser.”

1My 2011 Master's was in telecommunications, on fiber lasers — a special design called a figure-eight laser.

2I used a new type of optical fiber: a microstructured (photonic-crystal) fiber.

3My goal was to maximize the laser output power with clean, well-shaped pulses.

4I simulated the full system in OptiSystem and optimized the parameters — my best result was about 807 mW of output power.

Deeper technical detail (only if they really push)aStudied nonlinear effects in fibers: Kerr (SPM, XPM, four-wave mixing), and Raman / Brillouin scattering.
bPulsed-laser methods: Q-switching and mode-locking.
cThe figure-eight laser uses NOLM / NALM loop mirrors plus an Erbium-doped fiber amplifier.
dI tuned: pump power, Erbium fiber length & ion density, microstructured-fiber length, β2, β3, effective area, DGD, and polarization controllers.
eBest configuration: pump 2 W, Er fiber 7.5 m @ 750 ppm, microstructured fiber 0.08 km, β2 = −8 ps²/km, β3 = 6 ps³/km, Aeff = 5 µm² → 806.7 mW.

▸ My optical-fiber research (if asked)

Rehouma, Bahloul, Mothé, Di Bin, Attia — “Influence of air-hole collapse on splice losses between microstructured optical fibers.” Collaboration: EPT (Tunisia) & XLIM, University of Limoges (France).

1I worked on a special fiber that has many tiny holes inside (a “microstructured” fiber).

2I studied how to join two of these fibers together with very little loss.

3To join them, you melt the ends with heat — but the heat can close the tiny holes.

4When the holes close, light escapes — so you lose signal at the joint.

5I used a computer simulation (FD-VBPM) to find the best way to join them.

6Result: if the closed part is short and the holes stay open enough, the loss is almost zero.

Deeper technical detail (only if they really push)

aModelled a 5-ring air-silica microstructured fiber (Λ = 4 µm, d = 3 µm) with air holes collapsing along the propagation axis.

bLoss grows with the collapse length: negligible at 250 µm, but up to ~1.8 dB at 1 mm.

cWorst case = holes nearly closed (reduction coefficient near 0) over a long zone; best case = reduction coefficient > 0.4 and length < 250 µm.

dTake-away: to get a low-loss splice, limit both the hole-diameter reduction and the length of the collapse zone.

4. PhD & Projects

What I say to the jury

I completed my PhD at ÉTS — a school known for applied engineering.

I did my research in the pediatric ICU at Sainte-Justine hospital, with real doctors and real critically-ill children.

My work brought together computer vision, artificial intelligence, and biomedical engineering — for non-contact respiration monitoring.

I built an AI decision-support system that watches a child’s breathing with simple 3D cameras — no sensors on the body.

The AI reconstructs the body surface in 3D and turns breathing into real, measurable numbers.

After my PhD, I did a one-year postdoctoral fellowship at ÉTS, in Medical AI and clinical systems.

I led a project on an AI system to monitor respiratory distress in children, in intensive care.

My PhD was about three things:

Computer vision — in the Electrical Engineering department (ÉTS is known for applied engineering)
Biomedical engineering
Respiration monitoring without contact

More detail — click to open if asked:

▸ Academic & research experience — full details (if asked)

Postdoctoral Fellow — Medical AI & Clinical Systems Engineering
ÉTS, Department of Electrical Engineering

1Led a research project on a Respiratory Distress Monitoring System (RDMS) using AI in pediatric ICU settings.

2Goal: a proof-of-concept autonomous surveillance system for respiratory distress in critically ill children.

3Built computer vision and ML components to detect severe situations from chest-wall deformities captured with a depth camera in the PICU.

4Worked with clinical stakeholders and engineering teams; supported experimental validation and troubleshooting.

Ph.D. Researcher — Computer Vision, 3D Sensing & Clinical AI
ÉTS & CHU Sainte-Justine ICU (partnership)

1Designed a Computerized Clinical Decision Support System (CCDSS) for respiratory-distress detection.

2Goal: detect respiratory failure in critically ill children using non-contact imaging and machine intelligence.

3Built a 3D surface reconstruction pipeline with two Microsoft Kinect sensors to estimate respiratory rate, tidal volume, and minute ventilation.

4Used 3D motion reconstruction to characterise thoraco-abdominal asynchrony (TAA) and derive clinical indicators.

5Delivered validated prototypes; produced peer-reviewed publications and contributed to a U.S. patent application.

▸ How the AI breathing system works (if asked)

LATIS Lab, ÉTS & CHU Sainte-Justine ICU · featured by ÉTS as “Saving children through Xbox cameras” · Rehouma et al., Computerized Medical Imaging and Graphics, 70 (2018), 17–28.

1The problem: in babies, doctors judge breathing by eye — this is subjective and hard when the volume is small.

2My goal was to develop a computerised clinical decision-support system (CCDSS) that measures breathing objectively, with no contact.

3I used two Microsoft Kinect (Xbox) cameras at the corners of the bed to cover the whole chest and sides.

4The two views are aligned into one 3D scene, then I reconstruct the chest-abdomen surface from the point cloud.

5I compute lung volume with an octree (recursive 3D cubes) — the signal gives respiratory rate, tidal volume, and minute ventilation.

6A second method reconstructs 3D motion to measure thoraco-abdominal asynchrony (TAA) — when chest and abdomen do not move together (a sign of distress).

7Validated against a mechanical ventilator (gold standard), on a newborn manikin and on a real patient — good accuracy and precision.

▸ The octree volume method (if asked)

“An octree is just a smart way to measure a 3D shape by filling it with cubes.”

aI start with one big cube around the chest surface (the root).

bI split each cube into 8 smaller cubes (an “octant”), again and again — that is why it is called an oct-tree.

cI stop splitting when I reach a maximum depth, or when a cube is empty (outside the body).

dThe volume = number of filled cubes × the size of one cube.

eI do this on every frame (30 per second), so the volume changes over time — that curve is the breathing signal: its rhythm = respiratory rate, its amplitude = inhaled volume.

8. Steganography — Data Security Research

As a research assistant at the Faculty of Engineering, University of Moncton, I worked on data security using LSB & DCT based steganography.

What I say to the jury

As a research assistant, I also worked in data security, on steganography.

Steganography means hiding secret data inside a file — like an image. The message is not just scrambled, it is invisible.

I combined two techniques, LSB and DCT, to hide more data and resist detection.

More technical details (if asked)

1I combined the LSB (Least Significant Bit) and the DCT (Discrete Cosine Transform).

2Instead of hiding the image itself, I hid its DCT spectrum — this gives a much higher hiding capacity.

3In a second approach, I also encrypted the data before hiding it — so even if an attacker finds it, they cannot read it.

4I used the second least significant bit instead of the last one, to be more resistant to steganalysis (detection attacks).

Steganography LSB DCT Data hiding Encryption Steganalysis resistance

Respiration Monitoring (without contact)

What I say to the jury

My PhD mixed computer vision, AI, and biomedical engineering.

I worked on non-contact breathing monitoring — watching breathing without any sensor on the patient.

The idea was to use cameras to get useful breathing data in intensive care.

This makes patients more comfortable, with no wires.

In short, I turned a visual observation into real, measurable data.

▸ More technical detail (if asked)1I used two Microsoft Kinect depth cameras placed at the corners of the bed, to see the whole chest and abdomen.
2The two views are merged into one 3D point cloud, then I reconstruct the body surface.
3I compute lung volume over time with an octree method — the curve gives respiratory rate, tidal volume, and minute ventilation.
4Validated against a mechanical ventilator (the clinical gold standard) on a newborn manikin and a real patient — good accuracy.
5Published in Computerized Medical Imaging and Graphics (2018), IEEE TIM (2020), and Sensors (2020).

Chest Motion (quantifying)

What I say to the jury

I also studied how the chest and abdomen move during breathing.

I wanted to see if the two parts move together or not.

When they do not move together, it can be a sign of breathing difficulty.

I used 3D vision to make this pattern visible and measurable.

So I turned a clinical observation into clear, objective data.

▸ More technical detail (if asked)1The clinical name is thoraco-abdominal asynchrony (TAA) — the chest and abdomen do not move in phase.
2I split the body surface into a chest compartment and an abdomen compartment from the 3D motion point clouds.
3I track each compartment’s volume over time and measure the phase difference between the two signals.
4A large phase difference is a sign of respiratory distress — the body works harder to breathe.
5Published as a pilot study in IEEE Access (2019).

Fall Detection

What I say to the jury

I also built an AI system to detect falls, using movement sensors and cameras.

It combined motion data and posture analysis — two sources — for a more reliable decision.

I used deep learning to find abnormal movements and risky postures.

The goal was to reduce false alarms in real life.

This shows I can build a complete AI system, from the data to the final product.

▸ More technical detail (if asked)1It is a bimodal system: an RGB camera for body pose, and an IMU (motion sensor) for movement.
2For the camera, I use a Transformer on the body-pose sequence. For the motion, I use an LSTM autoencoder — that part is unsupervised.
3I join the two with late fusion — I fuse the two decisions at the end. It is cheaper than early fusion, and more robust if one sensor is weak.
4Results: 97% F1-score and only 3.6% false alarms. It runs in real time on a normal CPU, even in the dark.
5Published in Sensors (MDPI), 2025 — with a new follow-up paper coming to IEEE ICM 2026.

6. Publications

What I say to the jury

I have 9 peer-reviewed publications — 6 journals and 3 conferences.

I also have a US patent, my PhD thesis, and a science-magazine article.

My work has been cited more than 140 times, in journals like Sensors and IEEE Access.

9 peer-reviewed publications (6 journals + 3 conferences), plus 1 US patent, 1 PhD thesis, and 1 science-magazine article — cited 140+ times.

Published in: Sensors, IEEE Access, IEEE Transactions on Instrumentation and Measurement, Computerized Medical Imaging and Graphics, Virtual Reality, IEEE ICECS, IPTA, and Photonics North.

Journal Conference Other (patent, thesis, magazine)

2025 Fall Detection by Bimodal Sensing with Late Fusion. IEEE Int. Conf. on Electronics, Circuits and Systems (ICECS).
2025 Fall Detection by Deep Learning-Based Bimodal Movement and Pose Sensing with Late Fusion. Sensors 25(19), 6035. cited by 6
2022 Methods and systems for assessing severity of respiratory distress of a patient. US Patent App. 17/763,319. cited by 1
2020 Advancements in methods and camera-based sensors for the quantification of respiration. Sensors 20(24), 7252. cited by 38
2020 Quantitative assessment of spontaneous breathing in children: evaluation of a depth camera system. IEEE Trans. on Instrumentation and Measurement 69(7), 4955-4967. cited by 26
2019 Visualizing and quantifying thoraco-abdominal asynchrony in children from motion point clouds: A pilot study. IEEE Access 7, 163341-163357. cited by 11
2019 Quantification de la respiration en unité de soins intensifs pédiatrique à partir de séquences d'images et de vidéo. PhD thesis, École de technologie supérieure (ÉTS).
2019 Saving Children through Xbox Cameras / Sauver des enfants grâce à des caméras Xbox. Substance ÉTS (science magazine).
2018 3D imaging system for respiratory monitoring in pediatric intensive care environment. Computerized Medical Imaging and Graphics 70, 17-28. cited by 47
2017 A computer vision method for respiratory monitoring in intensive care environment using RGB-D cameras. IEEE Int. Conf. on Image Processing Theory, Tools and Applications (IPTA). cited by 15
2017 Towards a mobile serious game environment for children self-learning. Virtual Reality. cited by 2
2015 Excitation of vector modes in few-mode fiber using wire-based mechanical long period fiber grating. Photonics North. cited by 8

9. My Strengths & Weaknesses

If they ask about my strengths (+)

I am a fast learner, and I adapt quickly to new tools and technologies.

I am very hands-on — I like to build real, working solutions, not just theory.

And I collaborate easily with people from different fields — engineers, doctors, and students.

If they ask about my weaknesses (−)

Sometimes I pay too much attention to small details.

I am working on it: I now focus on the big picture first, and prioritise what matters most.

1 / 1

The Big Picture — From DES to Today's Encryption

Why encryption algorithms evolved, and which one we use where

How I open the presentation

Before the details, let me give you the big picture in one slide.

DES was the first encryption standard. It worked well — but its 56-bit key became too weak for modern computers.

So encryption had to evolve: from DES, to Triple DES, to AES today.

But one strong cipher is not enough. Each real application needs the right method — and that is exactly what this chapter is about.

DES (1977, 56-bit) → too weak → Triple DES (112/168-bit) → AES (modern standard)

One idea to remember

We don't just pick an algorithm — we match the right method to the right problem: disks, streaming, or special data formats.

Application	What we use	Why
Hard disk / SSD encryption	XTS-AES	Built for fixed sectors — identical data in two sectors looks different.
Streaming / network / real-time	CTR, GCM	Fast and parallel — encrypts data on the fly.
Keeping the data format (cards, IDs)	FPE — FF1 / FF3	Encrypts but keeps the same length and format.
General messages (many blocks)	Modes: CBC, CFB, OFB, CTR	Hide patterns when encrypting long data.

T318 - Applied Network Security

Chapter 5 — Block Cipher Operation

1Good afternoon everyone. Today, I will talk about block cipher operation.

2A block cipher is a method used to protect data by encrypting it in fixed-size blocks.

3In this short presentation, I will explain how it works, why we use it, and how it helps secure information.

Objective of today's session

By the end of this session, you will understand how we use a block cipher in a secure way — from multiple encryption and Triple DES, to the modes of operation, XTS-AES, and format-preserving encryption.

Many of these methods are the foundation of the data security we use today — for example, encrypting data stored on SSDs and hard disks, or securing streaming and real-time data.

Double Encryption

Figure 5.1 — Encrypt twice with two different keys

Show original slide

How I explain it

Encryption transforms readable information (called plaintext) into unreadable information (called ciphertext), to protect it from unauthorized access.

Double encryption means we encrypt the message two times, with two different keys.

First, we encrypt the message P with the first key, and we get a middle result X.

Then we encrypt X again with the second key, and we get the final ciphertext C.

It is like locking a box with two different locks. To open it, we remove both locks in reverse order.

Detailed notes (full explanation)

1This slide explains double encryption.

2The main idea is to encrypt the plaintext twice, using two different keys.

3First, the plaintext P is encrypted with key K1, producing an intermediate result X.

4Then, X is encrypted again with key K2, producing the final ciphertext C.

P → E(K1) → X → E(K2) → C

5For decryption, we reverse the process — the keys must be used in the reverse order:

C → D(K2) → X → D(K1) → P

6In simple terms, it is like locking a box with two different locks. To open it, we remove both locks in the correct reverse order.

Meet-in-the-Middle Attack

Why Double DES is weaker than it looks

Show original slide

Original slide 3 - Meet-in-the-Middle Attack

How I explain it

Double encryption looks twice as strong, but it is not.

Instead of trying all the keys, the attacker works from both sides at the same time.

From the message side, he tries the first key. From the ciphertext side, he tries the second key.

When the two sides meet in the middle, he finds both keys. That is why Double DES is not strong enough.

Detailed notes (full explanation)1This slide introduces the meet-in-the-middle attack.
2The main idea: double encryption does not always give the security we expect.
3Instead of trying all key pairs directly, the attacker works from both sides.
4From the plaintext side: encrypt P with possible K1 values and store the middle results X.
5From the ciphertext side: decrypt C with possible K2 values and look for a match in the middle.
P → E(K1) → X   =?=   X ← D(K2) ← C
6In simple terms, it is like two people entering a tunnel from opposite sides and meeting in the middle.
7This makes the attack much faster than a full brute-force on both keys.
8Important: this is not the same as Man-in-the-Middle. It is a mathematical attack on the encryption, not intercepting a communication.
9This is why Double DES is not considered secure enough in practice, even with two steps.

Triple-DES with Two Keys

A stronger answer to the meet-in-the-middle attack

Show original slide

Original slide 4 - Triple-DES with Two Keys

How I explain it

To fix this weakness, we add a third step instead of two.

This is Triple-DES, and the meet-in-the-middle attack becomes much too expensive.

To keep it simple, we can use only two keys: encrypt with the first key, decrypt with the second key, then encrypt again with the first key.

It is like adding a third lock, but with only two keys.

Detailed notes (full explanation)

1This slide explains Triple-DES with two keys. It solves the weakness of Double DES.

2Instead of two encryption stages, Triple-DES uses three stages.

DES → DES → DES

3Three stages make the meet-in-the-middle attack much more expensive — cost rises to about 2¹¹², beyond what is practical.

4Using three different keys is strong, but needs 56 × 3 = 168 bits, which can be harder to manage.

5As a practical alternative, Tuchman proposed two-key Triple-DES: three operations, but only two keys.

Encrypt(K1) → Decrypt(K2) → Encrypt(K1)

6This is called EDE mode (Encrypt – Decrypt – Encrypt). Even with a decrypt in the middle, the final result is still encryption.

7EDE keeps some compatibility with old DES and makes the attack much harder than Double DES.

8In simple terms, it is like adding a third lock, but using only two keys — more protection without too much complexity.

93DES with two keys is popular and adopted in the standards ANSI X9.17 and ISO 8732.

Triple Encryption (EDE)

Figure 5.2 — Two-key Triple-DES: Encrypt – Decrypt – Encrypt

Show original slide

How I explain it

Here is the two-key Triple-DES, step by step. We call it E-D-E: Encrypt, Decrypt, Encrypt.

We encrypt P with the first key, then decrypt with the second key, then encrypt again with the first key.

Even with a decrypt in the middle, the final result is still encryption.

Why E-D-E? So that if both keys are equal, it works exactly like the old simple DES.

Detailed notes (full explanation)

1This slide shows the two-key Triple-DES process. It uses three operations, so we call it the EDE structure.

2Even though there is a D in the middle, the whole process is still encryption.

3Encryption: P is encrypted with K1 → A; then A is decrypted with K2 → B; then B is encrypted with K1 → C.

P → E(K1) → A → D(K2) → B → E(K1) → C

4Decryption: we reverse it — start from C, decrypt with K1, encrypt with K2, decrypt with K1 → back to P.

C → D(K1) → B → E(K2) → A → D(K1) → P

5Why E-D-E and not E-E-E? For compatibility with old DES: if K1 = K2, the system behaves like simple DES.

6In simple terms, it is like locking, unlocking with another key, and locking again.

7This makes the system stronger than Double DES and much harder to attack with meet-in-the-middle.

8Key point: even with a decrypt step in the middle, the overall process is still encryption, because the final output is ciphertext.

Known-Plaintext Attack on Triple DES

Figure 5.3 — A theoretical attack on two-key 3DES

Show original slide

Original slide 6 - Known-Plaintext Attack on Triple DES

How I explain it

Here, the attacker already knows a few messages and their encrypted version.

With these known pairs, he builds two tables and looks for a match in the middle — same idea as before.

So he can find the keys faster than testing everything.

But this is only theoretical. Two-key 3DES is still much safer than Double DES.

Detailed notes (full explanation)

1This slide shows a known-plaintext attack on two-key Triple-DES.

2Known-plaintext means the attacker already knows some plaintext–ciphertext pairs (P, C).

3The structure is still EDE, with candidate keys i (for K1) and j (for K2):

Pi → E(i) → a → D(j) → Bj → E(i) → Ci

4Table (b): the attacker collects n known (P, C) pairs, sorted on P.

5Table (c): for each guessed key, the attacker computes the middle value Bj and stores it with the candidate key i.

6When the values match in the middle, the attacker finds a candidate key pair (i, j).

7In simple terms, the attacker uses known pairs and tables to find a match in the middle, reducing the work to recover the keys.

8Key point: two-key 3DES has a theoretical weakness if enough known plaintext exists — but it is still far stronger than Double DES.

Triple DES with Three Keys

The preferred and strongest 3DES option

Show original slide

Original slide 7 - Triple DES with Three Keys

How I explain it

If two keys still leave a small risk, we use three keys.

Three keys means three independent locks — this is the strongest version of 3DES.

It gives a 168-bit key, and big tools like PGP and S/MIME use it.

Detailed notes (full explanation)

1Many researchers now feel that three-key 3DES is the preferred alternative.

2It uses three different keys (K1, K2, K3), giving an effective key length of 168 bits.

3The encryption is defined as:

C = E(K3, D(K2, E(K1, P)))

4It is still EDE (Encrypt – Decrypt – Encrypt), but now each step uses its own key.

5Backward compatibility with DES is possible by setting K3 = K2 or K1 = K2.

6In simple terms: three keys means three independent locks — the strongest version of 3DES.

7Many Internet applications adopted three-key 3DES, including PGP and S/MIME.

Modes of Operation

How a block cipher is applied in real applications

Show original slide

How I explain it

A block cipher only encrypts one small block at a time.

But real messages are long. A mode of operation tells us how to handle many blocks together.

NIST (National Institute of Standards and Technology) defined five modes for this. They work with both AES and 3DES.

Detailed notes (full explanation)1A mode of operation is a technique to enhance a cryptographic algorithm or adapt it for an application.
2To use a block cipher in many applications, NIST (National Institute of Standards and Technology) defined five modes of operation.
3The five modes cover a wide variety of encryption applications where a block cipher could be used.
4They work with any symmetric block cipher, including Triple DES and AES.
5In simple terms: the cipher encrypts one block; the mode decides how to handle many blocks together.

Block Cipher Modes of Operation

Table 5.1 — The five NIST (National Institute of Standards and Technology) modes

Show original slide

Original slide 9 - Block Cipher Modes of Operation

How I explain it

Here are the five modes in one table.

ECB is the simplest, CBC chains the blocks, CFB and OFB act like a stream, and CTR uses a counter.

Each one fits a different need — I will explain them one by one.

Mode	Description (simple)	Typical use
ECB Electronic Codebook	Each block is encrypted independently with the same key.	Secure transmission of a single value (e.g. a key)
CBC Cipher Block Chaining	Each block is XORed with the previous ciphertext before encryption (blocks are chained).	General block transmission, authentication
CFB Cipher Feedback	Processes data s bits at a time; previous ciphertext feeds the cipher to make a keystream.	General stream transmission, authentication
OFB Output Feedback	Like CFB, but the encryption output is fed back (full blocks). Good against bit errors.	Stream over a noisy channel (e.g. satellite)
CTR Counter	Each block is XORed with an encrypted counter; the counter increases each block.	General transmission, useful for high speed

Electronic Codebook (ECB) Mode

Figure 5.4 — The simplest mode

Show original slide

Original slide 10 - Electronic Codebook (ECB) Mode

How I explain it

ECB is the easiest one: each block is encrypted alone, with the same key.

The problem: the same block always gives the same result.

So patterns stay visible. We only use it for very short data, like one key.

Detailed notes (full explanation)

1ECB is the simplest mode. Each block of plaintext is encrypted independently.

2The same key is used for every block.

P1 → E(K) → C1 | P2 → E(K) → C2 | ... | PN → E(K) → CN

3Decryption is the same idea in reverse: each C is decrypted with K to get back P.

4Big weakness: identical plaintext blocks always give identical ciphertext blocks.

5So patterns in the data can still be visible — it does not hide repetition.

6In simple terms: ECB is like translating each word with the same dictionary — same word, same code every time.

7Because of this, ECB is only safe for short, single values (like sending one key), not long messages.

Evaluation of Modes of Operation

How we judge a mode that is better than ECB

Show original slide

Original slide 11 - Evaluation of Modes of Operation

How I explain it

Before the other modes, here is how we judge a good mode.

We look at speed, how it handles errors, and how secure it is.

A good mode should be fast, robust to errors, and secure.

Detailed notes (full explanation)1These are the criteria we use to evaluate and build modes that are better than ECB.
2Overhead — how much extra cost the mode adds (speed, memory, processing).
3Error recovery — can the system keep working after an error in one block?
4Error propagation — if one bit is wrong, how many blocks are affected?
5Diffusion — one small change in the input should spread widely in the output.
6Security — how well the mode protects the data against attacks.
7In simple terms: a good mode should be fast, robust to errors, and secure.

Cipher Block Chaining (CBC) Mode

Figure 5.5 — Blocks are chained together

Show original slide

Original slide 12 - Cipher Block Chaining (CBC) Mode

How I explain it

CBC fixes the ECB problem by chaining the blocks.

Each block is mixed (XOR) with the previous encrypted block before encryption.

So the same text gives different results — patterns are hidden. The first block uses an IV.

Detailed notes (full explanation)

1CBC fixes the main weakness of ECB by chaining the blocks together.

2Before encryption, each plaintext block is XORed with the previous ciphertext block.

C1 = E(K, P1 ⊕ IV) | C2 = E(K, P2 ⊕ C1) | ...

3The first block uses an IV (Initialization Vector) because there is no previous ciphertext yet.

4Decryption reverses it: decrypt the block, then XOR with the previous ciphertext to recover P.

P1 = D(K, C1) ⊕ IV | P2 = D(K, C2) ⊕ C1 | ...

5Big advantage: identical plaintext blocks now give different ciphertext — patterns are hidden.

6In simple terms: each block depends on the one before it, like links in a chain.

7Good for general-purpose transmission and authentication.

Cipher Feedback Mode

Turning a block cipher into a stream cipher

Show original slide

Original slide 13 - Cipher Feedback Mode

How I explain it

A block cipher works on a full block — 64 bits for DES, 128 for AES.

But sometimes we want to encrypt small pieces, like a stream.

Three modes do that: CFB, OFB, and CTR.

Detailed notes (full explanation)

1For AES, DES, or any block cipher, encryption works on a block of b bits.

2In DES, the block size is b = 64 bits.

3In AES, the block size is b = 128 bits.

4Sometimes we want a stream cipher instead, to encrypt data bit by bit or byte by byte.

5Three modes can convert a block cipher into a stream cipher:

Cipher Feedback (CFB) mode
Output Feedback (OFB) mode
Counter (CTR) mode

6In simple terms: these modes let us encrypt small pieces of data without waiting for a full block.

s-bit Cipher Feedback (CFB) Mode

Figure 5.6 — The cipher makes a keystream

Show original slide

Original slide 14 - s-bit Cipher Feedback (CFB) Mode

How I explain it

In CFB, the cipher makes a keystream; we XOR it with the data.

Then we feed the ciphertext back for the next piece — that is the feedback.

It works a few bits at a time, like a stream cipher.

Detailed notes (full explanation)

1In CFB, the block cipher is used to generate a keystream, not to encrypt the plaintext directly.

2A shift register holds the input. The cipher encrypts it, and we select s bits of the output (discard the rest).

3We XOR these s bits with the plaintext to make the ciphertext.

C1 = P1 ⊕ (s bits of E(K, IV))

4The ciphertext is then fed back into the shift register for the next step (that is the "feedback").

5For decryption, we use the same Encrypt operation (not Decrypt), then XOR with the ciphertext to get P back.

6In simple terms: CFB turns the block cipher into a stream cipher, working s bits at a time.

7Good for stream-oriented transmission and authentication.

Output Feedback (OFB) Mode

Figure 5.7 — Like CFB, but feed back the encryption output

Show original slide

Original slide 15 - Output Feedback (OFB) Mode

How I explain it

OFB is like CFB, but we feed back the cipher's own output, not the ciphertext.

So the keystream does not depend on the data.

Big advantage: one error stays local. Good for noisy channels like satellite.

Detailed notes (full explanation)

1OFB is very similar to CFB, but here we feed back the encryption output, not the ciphertext.

2The cipher starts from a Nonce and keeps encrypting its own output to build a keystream.

O1 = E(K, Nonce) → O2 = E(K, O1) → O3 = E(K, O2) ...

3Each plaintext block is then XORed with this keystream to make the ciphertext.

C1 = P1 ⊕ O1 | C2 = P2 ⊕ O2 | ...

4Key advantage : the keystream does not depend on the data, so a bit error in one block does not spread to other blocks.

5This makes OFB good for noisy channels, like satellite communication.

6In simple terms: OFB builds a key stream in advance and just XORs it with the data — errors stay local.

Counter (CTR) Mode

Figure 5.8 — Encrypt a counter, then XOR

Show original slide

How I explain it

CTR is very simple: we just encrypt a counter — 1, 2, 3 — to make the keystream.

Then we XOR it with the data.

Blocks are independent, so it is fast and parallel. Just never reuse a counter with the same key.

Detailed notes (full explanation)

1In CTR mode, we encrypt a counter value to build the keystream.

2The counter increases by 1 for each block (Counter 1, Counter 2, ...).

3Each plaintext block is XORed with the encrypted counter:

C1 = P1 ⊕ E(K, Counter1) | C2 = P2 ⊕ E(K, Counter2) | ...

4Big advantage: blocks are independent, so they can be processed in parallel — very fast.

5We can also jump directly to any block (random access), without decrypting the others.

6Decryption uses the same Encrypt operation on the counter, then XOR with the ciphertext.

7In simple terms: CTR is like a numbered keystream generator — simple, fast, and good for high speed.

8Important: each counter value must be used only once with the same key.

Advantages of CTR

Why Counter mode is so popular

Show original slide

How I explain it

CTR has many advantages: it is parallel, fast, and simple.

We can prepare the keystream in advance and jump to any block.

It only needs the Encrypt function. That is why it is used everywhere today.

Detailed notes (full explanation)1Hardware efficiency — blocks are independent, so they can be encrypted in parallel.
2Software efficiency — it uses simple operations and runs fast on normal CPUs.
3Pre-processing — the keystream can be computed in advance, before the data arrives.
4Random access — we can jump directly to any block without doing the others first.
5Provable security — CTR has strong, proven security guarantees.
6Simplicity — it only needs the Encrypt operation (no Decrypt), so it is easy to implement.
7In simple terms: CTR is fast, flexible, simple, and secure — that is why it is widely used today.

Feedback Characteristic of Modes

Figure 5.9 — What each mode feeds back

Show original slide

Original slide 18 - Feedback Characteristic of Modes

How I explain it

This slide compares what each mode feeds back.

CBC and CFB feed back the ciphertext, so errors spread.

OFB and CTR do not depend on the data, so errors stay local.

Detailed notes (full explanation)1This slide compares what each mode feeds back into the next step.
2CBC — feedback is the ciphertext block (XORed with the next plaintext before encryption).
3CFB — feedback is also the ciphertext, but used through the input register to make a keystream.
4OFB — feedback is the encryption output (not the ciphertext), so it does not depend on the data.
5CTR — there is no feedback: each block uses an independent counter.
6Key difference: CBC and CFB depend on the ciphertext (errors spread); OFB and CTR do not (errors stay local).
7In simple terms: the feedback choice decides speed, error behaviour, and whether blocks are independent.

XTS-AES Mode for Storage Devices

A special mode for stored data (disks)

Show original slide

Original slide 19 - XTS-AES Mode for Storage Devices

How I explain it

Now we move from messages to stored data — disks and SSDs.

XTS-AES is the special mode for that, approved by NIST (National Institute of Standards and Technology) in 2010.

It protects data at rest, even if someone steals the physical disk.

Detailed notes (full explanation)1XTS-AES is an additional block cipher mode, approved by NIST (National Institute of Standards and Technology) in 2010.
2It is also an IEEE standard: IEEE Std 1619-2007.
3It describes how to encrypt data stored in sector-based devices (like hard drives and SSDs).
4Its threat model assumes the attacker may physically access the stored data (a lost or stolen disk).
5It has received widespread industry support and is the standard for disk encryption.
6In simple terms: XTS-AES is the mode designed to protect data at rest on storage devices.

Tweakable Block Ciphers

The idea behind XTS-AES

Show original slide

Original slide 20 - Tweakable Block Ciphers

How I explain it

XTS uses a tweakable cipher: it adds a third input called the tweak.

The tweak does not need to be secret. It just changes the output.

On a disk, the tweak is the sector number — so the same data in two places looks different.

Detailed notes (full explanation)

1XTS-AES is based on the concept of a tweakable block cipher.

2A normal cipher has 2 inputs; a tweakable cipher has three inputs:

P (plaintext) + K (secret key) + T (tweak) → C (ciphertext)

3The plaintext P is the data, the key K is the secret, and the tweak T adds variability.

4The tweak does not need to be secret — its only job is to make the output different.

5So the same plaintext + same key, but a different tweak, gives a different ciphertext.

6In storage, the tweak is usually the sector/block number, so identical data in different sectors looks different.

7In simple terms: the tweak is like a location label that changes the result without being a secret.

Tweakable Block Cipher

Figure 5.10 — How the tweak is mixed in

Show original slide

Original slide 21 - Tweakable Block Cipher

How I explain it

Here is how the tweak is mixed in.

We XOR the tweak before encryption and again after.

These two steps tie each block to its position on the disk.

Detailed notes (full explanation)

1This diagram shows how the tweak T is used in encryption and decryption.

2First, the tweak T goes through a hash function to make a value H(T).

3For encryption: XOR the plaintext with H(T), then encrypt with key K, then XOR with H(T) again.

C = E(K, P ⊕ H(T)) ⊕ H(T)

4For decryption: the same H(T) is used, with the Decrypt operation, to recover P.

P = D(K, C ⊕ H(T)) ⊕ H(T)

5The two XOR steps (before and after) are what bind the tweak to that specific block.

6In simple terms: the tweak is mixed in before and after encryption, so each block depends on its position.

Storage Encryption Requirements

The P1619 standard for data at rest

Show original slide

Original slide 22 - Storage Encryption Requirements

How I explain it

Encrypting a disk is different from encrypting a message.

The attacker can read the whole disk, and data is accessed in fixed blocks.

So encryption must be per-block, location-aware, and the same on every device.

Detailed notes (full explanation)

1Encrypting stored data ("data at rest") is a bit different from encrypting transmitted data.

2The P1619 standard was designed with these requirements:

The ciphertext is freely available to an attacker (they can read the disk).
The data layout does not change on the medium or in transit.
Data are accessed in fixed-size blocks, independently.
Encryption is done in 16-byte blocks, independently.
No extra metadata is used, except the location of each block.
Same plaintext → different ciphertext at different locations, but the same ciphertext if written to the same location again.
Any standard-conformant device can decrypt data encrypted by another conformant device.

3In simple terms: disk encryption must be block-independent, location-aware, and interoperable.

XTS-AES Operation on Single Block

Figure 5.11 — Two keys and a tweak

Show original slide

Original slide 23 - XTS-AES Operation on Single Block

How I explain it

XTS uses two keys: one for the data, one for the tweak.

The tweak comes from the sector number and the block position.

We XOR with the tweak, encrypt, then XOR again. Same data in a different place → different result.

Detailed notes (full explanation)

1XTS-AES uses two keys: Key1 for the data, and Key2 for the tweak.

2The tweak is built from the sector number i: encrypt i with Key2, then multiply by α^j (the block position).

T = E(Key2, i) ⊗ α^j

3Encryption: XOR P with T → PP; encrypt PP with Key1 → CC; then XOR CC with T → C.

C = E(Key1, P ⊕ T) ⊕ T

4Decryption is the mirror: XOR with T, decrypt with Key1, XOR with T → back to P.

5The tweak T makes each block depend on its sector and its position on the disk.

6In simple terms: same data in a different place → different ciphertext, thanks to the tweak.

XTS-AES Mode

Figure 5.12 — The full sector, block by block

Show original slide

How I explain it

Here XTS is applied to a whole sector, block by block.

Each block uses its own position, so blocks are independent and parallel.

The last partial block uses a small trick called ciphertext stealing, so any length works.

Detailed notes (full explanation)

1This shows XTS-AES applied to a whole sector, one block at a time.

2Each block uses the same key but a different tweak — the pair (i, j): sector i, block position j.

P0 → (i,0) → C0 | P1 → (i,1) → C1 | ... | Pm → (i,m) → Cm

3Blocks are independent, so they can be encrypted/decrypted in parallel and accessed randomly.

4The last block (if the data does not fill a full block) uses ciphertext stealing — it borrows bits from the previous block (the CP / XX / YY crossover).

5Ciphertext stealing lets XTS handle any data length, without padding that would change the size.

6In simple terms: each disk block is encrypted on its own, with its position, and the last partial block is handled with a small trick.

Format-Preserving Encryption (FPE)

Same format in, same format out

Show original slide

Original slide 25 - Format-Preserving Encryption (FPE)

Key terms

FPE = Format-Preserving Encryption — the encrypted data keeps its original shape: same characters, same length, same structure. En français : chiffrement préservant le format. On chiffre la donnée, mais on garde sa forme d'origine.

1234-5678-9012-3456 → FPE → 8472-1905-6631-0284

NIST = National Institute of Standards and Technology — the US agency that publishes security and encryption standards (algorithms, passwords, recommendations). En français : Institut national des normes et de la technologie (USA). « NIST and other FPE algorithms » = les algorithmes FPE recommandés ou standardisés par le NIST.

How I explain it

FPE means: I encrypt the data but keep the same shape.

A credit card stays 16 digits, just different digits.

This way, old systems and databases still accept it without any change.

Detailed notes (full explanation)

1FPE is any encryption that takes a plaintext in a given format and produces a ciphertext in the same format.

2Example: a credit card is 16 decimal digits. FPE produces a ciphertext that is also 16 decimal digits.

4179 5000 0574 6453 → FPE → 2831 9047 1265 8890

3The ciphertext is not a valid card number, but it keeps the same shape (16 digits).

4This means it can be stored in the same database fields as the original, with no changes to the system.

5Very useful for legacy systems that expect a fixed format (cards, phone numbers, IDs).

6In simple terms: FPE encrypts the data without changing its shape, so old systems still accept it.

FPE vs AES

Table 5.2 — Same data, different output shape

Show original slide

	Credit Card	Tax ID	Bank Account
Plaintext	8123 4512 3456 6780	219-09-9999	800N2982K-22
FPE	8123 4521 7292 6780	078-05-1120	709G9242H-35
AES (hex)	af411326466add24 c86abd8aa525db7a	7b9af4f3f218ab25 07c7376869313afa	9720ec7f793096ff d37141242e1c51bd

How I explain it

This table compares FPE and normal AES on the same data.

FPE keeps the format; AES gives a long hexadecimal string.

AES is stronger and standard, but FPE is needed when the format must stay the same.

Detailed notes (full explanation)

1FPE keeps the same format as the original (same length, same type of characters).

2AES output is a long hexadecimal string — a totally different shape.

3In simple terms: AES is stronger and standard, but FPE is needed when the format must stay the same.

Motivation for FPE

Why FPE is useful in the real world

Show original slide

How I explain it

Why do we need FPE? For old, legacy systems.

Normal encryption would break the data fields and the database.

FPE adds security without rebuilding the whole system.

Detailed notes (full explanation)1FPE helps add encryption to legacy applications, where a normal mode would break the data fields.
2It is a useful tool for financial security, data sanitization, and protecting fields in old databases.
3Main benefit: it protects specific data elements while keeping the existing workflows working.
4No database schema changes are needed, and application changes are minimal.
5Only the apps that really need to see the plaintext must be modified.
6Good examples: COBOL data-processing, database applications, and compressing FPE characters for efficient transmission.
7In simple terms: FPE lets you add security to old systems without rebuilding them.

Difficulties in Designing an FPE

Requirements a good FPE must meet

Show original slide

Original slide 28 - Difficulties in Designing an FPE

How I explain it

Designing a good FPE is hard.

It must keep the format, work on many lengths, and be as strong as AES.

The hardest part is staying secure even for very short data.

Detailed notes (full explanation)1A general-purpose, standardized FPE must satisfy several requirements at the same time.
2The ciphertext must keep the same length and format as the plaintext.
3It must adapt to many character and number types (digits, letters, mixed).
4It must work with variable plaintext length, not just one fixed size.
5Its security strength should be comparable to AES.
6Security must stay strong even for very small plaintext lengths — this is the hard part.
7In simple terms: FPE must be flexible in format but still as strong as AES, which is difficult to achieve.

Feistel Structure for FPE

Figure 5.13 — How FPE is built inside

Show original slide

Original slide 29 - Feistel Structure for FPE

How I explain it

Inside, FPE often uses a Feistel structure, like the old DES.

We split the data in two halves, mix one into the other, then swap — and repeat.

After several rounds, we get a result in the same format.

Detailed notes (full explanation)

1Many FPE designs use a Feistel structure, the same idea used in classic ciphers like DES.

2The data is split into two halves: A (u characters) and B (v characters).

3In each round, one half goes through a function F_K and is combined with the other half; then the halves swap.

B(i+1) = A(i) | A(i+1) = B(i) + F_K(A(i))

4The function F_K also takes the tweak T and the round number, so each round is different.

5After several rounds, we get the ciphertext in the same format as the input.

6Decryption runs the same rounds in reverse order to recover the plaintext.

7In simple terms: FPE reuses the proven Feistel idea (split, mix, swap, repeat) but keeps the format.

Character Strings

Basic vocabulary used by FPE

Show original slide

How I explain it

Quick vocabulary used by FPE.

An alphabet is the allowed symbols; the radix is how many; a string is the actual data.

FPE works on these character strings, in a chosen base.

Detailed notes (full explanation)1NIST (National Institute of Standards and Technology) and other FPE algorithms work on plaintext made of a string of elements called characters.
2An alphabet is a finite set of two or more symbols (for example: 0-9, or A-Z).
3The characters are the individual elements of that alphabet.
4A character string is a finite sequence of characters from an alphabet.
5Characters may repeat in the string (e.g. "1221").
6The number of different characters in an alphabet is the base (also called the radix).
7In simple terms: alphabet = the allowed symbols, base/radix = how many symbols, string = the actual data.

Notation Used in FPE Algorithms

Table 5.3 — The symbols, in plain words

Show original slide

Original slide 31 - Notation Used in FPE Algorithms

Notation	Meaning (simple)
[x]^s	Convert an integer x into a byte string of s bytes.
LEN(X)	The length (number of characters) of string X.
NUM_radix(X)	Convert a string into a number, reading it in the given base.
PRF_K(X)	A pseudorandom function: gives a 128-bit output from X, using key K.
STR^m_radix(x)	Convert a number into a string of m characters in the given base.
[i .. j]	The set of integers from i to j (including both).
X[i .. j]	A substring of X, from position i to position j.
REV(X)	Reverse the order of the bits of X.

How I explain it

This is just the notation used in the algorithms.

The two important ones: NUM turns a string into a number, STR turns it back.

That is exactly how FPE keeps the format.

Detailed notes (full explanation)

1Key idea: NUM turns a string into a number, and STR turns a number back into a string — that is how FPE keeps the format.

Parameters Used in FPE Algorithms

Table 5.3 (b) — The settings of an FPE

Show original slide

Original slide 32 - Parameters Used in FPE Algorithms

Parameter	Meaning (simple)
radix	The base = number of characters in the plaintext alphabet.
tweak	An input to encrypt/decrypt whose confidentiality is not protected (it can be public).
tweakradix	The base for the tweak strings.
minlen	Minimum message length, in characters.
maxlen	Maximum message length, in characters.
maxTlen	Maximum tweak length.

How I explain it

These are the settings of an FPE.

They define the alphabet, the tweak, and the allowed lengths.

Remember: the tweak is an input, but it does not need to be secret.

Detailed notes (full explanation)

1In simple terms: these parameters define the alphabet, the tweak, and the allowed lengths for the data.

2Remember: the tweak is an input, but it does not need to be secret — it only adds variability.

Algorithm PRF(X)

Figure 5.14 — The pseudorandom function (it is just CBC-MAC)

Show original slide

How I explain it

PRF is a helper function used inside FPE.

It takes the data in 128-bit blocks, chains them with XOR and encryption.

This is the classic CBC-MAC idea; it returns one final block.

Detailed notes (full explanation)

1PRF(X) is a pseudorandom function used inside FPE. It takes a bit string X and returns a 128-bit block Y.

2Prerequisites: an approved 128-bit block cipher (CIPH) and a key K.

3Input: X must have a length that is a multiple of 128 bits.

4Step 1-2: split X into m blocks of 128 bits: X1, X2, ..., Xm.

5Step 3: start with Y0 = all zeros.

6Step 4: for each block, XOR with the previous result, then encrypt:

Yj = CIPH_K(Y(j-1) ⊕ Xj)

7Return the last block Ym.

8In simple terms: this is the CBC-MAC idea — chain the blocks with XOR + encrypt, and keep the final block as the result.

Algorithm FF1 (FFX[Radix])

Figure 5.15 — A real, NIST (National Institute of Standards and Technology)-approved FPE method

Show original slide

Original slide 34 - Algorithm FF1 (FFX[Radix])

How I explain it

FF1 is the first NIST (National Institute of Standards and Technology)-approved FPE method, and the most flexible.

It uses a Feistel structure with 10 rounds, calling the PRF each round.

The output has the same length as the input.

Detailed notes (full explanation)1FF1 is one of the NIST (National Institute of Standards and Technology)-approved FPE methods. It is the most flexible one.
2Prerequisites: a 128-bit block cipher, a key K, a radix (alphabet base), and length limits (minlen .. maxlen).
3Input: a character string X (length n) and a tweak T. Output: a string Y of the same length n.
4It uses a Feistel structure: split X into two halves A and B.
5It runs 10 rounds (i from 0 to 9). Each round uses the PRF from the previous slide to make a pseudorandom value.
6In each round: build a value from the tweak and one half, run it through PRF + the cipher, then add it (mod radix) to the other half, and swap.
7After 10 rounds, return Y = A || B — same format as the input.
8In simple terms: FF1 = Feistel + PRF, repeated 10 times, designed to be strong while keeping the format.

Algorithm FF2 (VAES3)

Figure 5.16 — Another FPE method, similar to FF1

Show original slide

Original slide 35 - Algorithm FF2 (VAES3)

How I explain it

FF2 is very similar to FF1, also Feistel with 10 rounds.

The difference: it precomputes a round key J once, instead of calling PRF every round.

So it is a bit more efficient.

Detailed notes (full explanation)1FF2 (also called VAES3) is another FPE method, very similar to FF1.
2It also uses a Feistel structure with 10 rounds and the same idea of split A and B.
3Main difference: the tweak has its own base, tweakradix, and is processed as a numeral string.
4It first builds a value J from the parameters and the tweak, using the cipher: J = CIPHK(P).
5Then in each round it encrypts with J as the key (CIPHJ), instead of calling PRF each time.
6After 10 rounds, return Y = A || B, same length as the input.
7In simple terms: FF2 is a variant of FF1 — same Feistel idea, but it precomputes a round key J to be a bit more efficient.

Algorithm FF3 (BPS-BC)

Figure 5.17 — The third FPE method

Show original slide

Original slide 36 - Algorithm FF3 (BPS-BC)

How I explain it

FF3 is the third method, also Feistel, but with 8 rounds.

It uses a fixed 64-bit tweak and some reverse operations.

Same idea: keep the format, stay strong.

Detailed notes (full explanation)1FF3 (also called BPS-BC) is the third FPE method, again based on a Feistel structure.
2The radix can be from 2 up to 216, so it supports large alphabets.
3The tweak T has a fixed length of 64 bits, split into two halves TL and TR.
4It runs 8 rounds (i from 0 to 7) — fewer than FF1/FF2.
5Each round uses one half of the tweak, encrypts with the cipher, and combines the result with the other half (mod radix), then swaps.
6A special detail: FF3 uses REV() (reverse) on the strings in several steps.
7After 8 rounds, return A || B, same length as the input.
8In simple terms: FF3 is another Feistel-based FPE — 8 rounds, a 64-bit tweak, and some reverse operations.

Summary

Chapter 5 — Block Cipher Operation

Show original slide

How I explain it

To summarize: we saw multiple encryption and Triple DES.

Then the five modes of operation, and XTS-AES for disks.

And finally format-preserving encryption with FF1, FF2, FF3. Thank you — I am happy to take questions.

Detailed notes (full explanation)

1Multiple encryption & Triple DES: Double DES (weak to meet-in-the-middle), Triple DES with two keys, and with three keys.

2Modes of operation — how a block cipher is applied to real data:

ECB — simplest, but reveals patterns.
CBC — chained blocks, hides patterns.
CFB — stream mode, ciphertext feedback.
OFB — stream mode, output feedback, errors stay local.
CTR — counter, fast and parallel.

3XTS-AES — for stored data (disks): tweakable cipher, storage requirements, single block and full sector.

4Format-Preserving Encryption (FPE) — motivation, difficulties, Feistel structure, and the NIST (National Institute of Standards and Technology) methods (FF1, FF2, FF3).

5In simple terms: this chapter showed how to use a block cipher safely — from stronger keys (3DES), to modes for messages, disks, and special formats.

6Thank you very much for your attention. I am happy to answer any questions.

Quick Reference — Abbreviations & Algorithms

Cheat-sheet: every acronym from this chapter in one place

How I explain it

Before we finish, here is a one-page summary of every abbreviation.

The block ciphers are DES, 3DES and AES. The modes are ECB, CBC, CFB, OFB, CTR.

For disks we use XTS-AES, and to keep the data format we use FPE with FF1, FF2, FF3.

Abbreviation	Full name	In simple words
DES	Data Encryption Standard	Old block cipher, 56-bit key — too weak alone today.
3DES	Triple DES	DES applied three times (E-D-E) with 2 or 3 keys — much stronger.
AES	Advanced Encryption Standard	The modern standard block cipher (128-bit blocks).
MITM	Meet-in-the-Middle attack	Attacks double encryption from both sides at once.
ECB	Electronic Codebook	Simplest mode — but reveals patterns (avoid).
CBC	Cipher Block Chaining	Each block is chained with the previous one.
CFB	Cipher Feedback	Stream mode using ciphertext feedback.
OFB	Output Feedback	Stream mode using output feedback; errors stay local.
CTR	Counter	Uses a counter — fast and parallel.
XTS-AES	XEX Tweakable block cipher with ciphertext Stealing (AES)	AES mode for disks / SSD: uses the sector position.
FPE	Format-Preserving Encryption	Encrypts but keeps the original format (e.g. a card number stays a card number).
FF1 / FF2 / FF3	FFX modes (Feistel-based FPE)	The NIST-approved FPE algorithms. FF1 = most flexible, FF3 = simpler / fixed.
PRF	Pseudo-Random Function	The building block inside FPE that produces random-looking output.
NIST	National Institute of Standards and Technology	US agency that publishes the security standards.

Where	Monthly (local)	Approx. USD / yr
Oman — private universities	OMR 2,500–3,500	~USD 78k–109k
Oman — public (e.g. SQU, start)	~OMR 1,636	~USD 51k
UAE	AED 18k–30k	~USD 59k–98k
Saudi Arabia	varies + allowances	~USD 50k–90k

Technology	Hands-on?	Note
Python	Yes	Main language, daily
PyTorch	Yes	Research models (Transformers, LSTM)
Hugging Face	Yes	Models, fine-tuning, embeddings
FastAPI	Yes	Serving models as APIs
Docker	Yes	AWS DevOps background
Kubernetes	Yes	CKA certified
AWS	Yes	AWS DevOps certified
Microsoft Azure	Yes	Comfortable
Google Cloud	Yes	Comfortable
FAISS	Yes	Vector search for RAG
Pinecone	Concept	Managed vector DB — can ramp up fast
Milvus	Concept	Open-source vector DB
Weaviate	Concept	Open-source vector DB
Azure AI Search	Concept	Managed retrieval — can ramp up fast

Acces protege

1. Yourself

2. Your Experience

7. Cybersecurity — My Main Strength

5. Artificial Intelligence

3. Education & Diplomas

4. PhD & Projects

8. Steganography — Data Security Research

Respiration Monitoring (without contact)

Chest Motion (quantifying)

Fall Detection

6. Publications

9. My Strengths & Weaknesses

The Big Picture — From DES to Today's Encryption

T318 - Applied Network Security

Double Encryption

Meet-in-the-Middle Attack

Triple-DES with Two Keys

Triple Encryption (EDE)

Known-Plaintext Attack on Triple DES

Triple DES with Three Keys

Modes of Operation

Block Cipher Modes of Operation

Electronic Codebook (ECB) Mode

Evaluation of Modes of Operation

Cipher Block Chaining (CBC) Mode

Cipher Feedback Mode

s-bit Cipher Feedback (CFB) Mode

Output Feedback (OFB) Mode

Counter (CTR) Mode

Advantages of CTR

Feedback Characteristic of Modes

XTS-AES Mode for Storage Devices

Tweakable Block Ciphers

Tweakable Block Cipher

Storage Encryption Requirements

XTS-AES Operation on Single Block

XTS-AES Mode

Format-Preserving Encryption (FPE)

FPE vs AES

Motivation for FPE

Difficulties in Designing an FPE

Feistel Structure for FPE

Character Strings

Notation Used in FPE Algorithms

Parameters Used in FPE Algorithms

Algorithm PRF(X)

Algorithm FF1 (FFX[Radix])

Algorithm FF2 (VAES3)

Algorithm FF3 (BPS-BC)

Summary

Quick Reference — Abbreviations & Algorithms

My real strength is teaching

Research and teaching — I bring both

Why I fit your mission

Topics I want to work on 2026 – 2027

If they ask: what is an adversarial attack?

Why this fits me

1. Teaching

2. Research & publications

3. Curriculum development & supervision

4. Quality assurance & accreditation

5. Industry & community engagement

6. Research grants & funding

Why I want this role

Why I want to make this move

If they ask: do you already have a position?

If they ask about salary

Salary — market data (for me only)

Questions I can ask them

My experience with Generative AI, LLMs, and RAG

An AI solution I designed and led

Hands-on: LLMs, Prompt Engineering, Fine-tuning, RAG

Conversational AI, Agentic AI, and AI Agents

Voice AI — Speech-to-Text and Text-to-Speech

Hands-on technologies — Yes / No

Leading AI architecture and mentoring teams

LLMs and the Transformer

How these models learn

Prompt Engineering