ICT 0417 – Safety and Security: Encryption
Safety and Security – Encryption
What is Encryption?
Encryption is the process of converting readable data (plaintext) into an unreadable form (ciphertext) using an algorithm and a key. Only someone who possesses the correct key can reverse the process (decrypt) and recover the original information.
Why Encrypt Data?
Confidentiality – prevents unauthorised persons from reading the data.
Integrity – when combined with hashing, ensures data has not been altered.
Authentication – verifies the identity of the sender/receiver.
Compliance – meets legal and organisational data‑protection requirements.
Common Encryption Types
Type Key Length (typical) Use Cases
Symmetric (e.g., AES) 128, 192, 256 bits File encryption, full‑disk encryption, cloud storage
Asymmetric (e.g., RSA, ECC) 2048–4096 bits (RSA) / 256–521 bits (ECC) Email signing/encryption, HTTPS TLS handshake
Hash functions (e.g., SHA‑256) 256 bits (output) Password storage, data integrity checks
Encryption in Different ICT Contexts
Hard‑Disk (Full‑Disk Encryption)
Full‑disk encryption (FDE) encrypts every sector of a storage device. The key is usually derived from a user password or a hardware TPM module.
Data is encrypted when written to the disk.
When the system boots, the correct key must be supplied before the OS can read the data.
Protects data if the device is lost or stolen.
Email Encryption
Email can be protected using:
PGP / OpenPGP – combines symmetric encryption for the message body with asymmetric encryption for the session key.
S/MIME – uses X.509 certificates to encrypt and digitally sign messages.
Typical workflow:
Sender generates a random session key.
Message is encrypted with the session key (symmetric).
Session key is encrypted with the recipient’s public key (asymmetric).
Recipient uses their private key to recover the session key and decrypt the message.
Cloud Storage Encryption
Data stored in the cloud is usually encrypted in two stages:
At‑rest encryption – data is encrypted on the server using a symmetric key managed by the provider or the user.
In‑transit encryption – data is protected while travelling between the client and the server using TLS/HTTPS.
Best practice: use client‑side encryption so that only the user holds the decryption key.
HTTPS Websites (TLS/SSL)
HTTPS secures web traffic using the Transport Layer Security (TLS) protocol. The process involves:
Client sends a “ClientHello” with supported cipher suites.
Server replies with “ServerHello”, selects a cipher suite, and sends its digital certificate.
Client validates the certificate (issued by a trusted CA).
Both parties perform a key‑exchange (e.g., Diffie‑Hellman or RSA) to create a shared symmetric session key.
All subsequent data is encrypted with the session key using a symmetric algorithm (often AES).
Key Management Essentials
Never store encryption keys in the same location as the encrypted data.
Use strong, random keys – avoid passwords or predictable patterns.
Rotate keys regularly and retire old keys securely.
Backup keys in a secure, offline location (e.g., hardware token, encrypted USB).
Summary Checklist for Students
Define encryption, plaintext, ciphertext, and key.
Explain why encryption is needed for confidentiality, integrity, authentication, and compliance.
Identify the main types of encryption (symmetric, asymmetric, hash) and give an example of each.
Describe how encryption protects data on hard discs, email, cloud services, and HTTPS websites.
List at least three best practices for key management.
Suggested diagram: Flow of encryption and decryption for email using PGP (session key, public key, private key).
Suggested diagram: TLS handshake sequence showing client hello, server hello, certificate exchange, key exchange, and encrypted application data.